1.

DataPower Web Service Proxy

Introduction
It is not very meaningful sending SOAP faults in form of an internal server error back to the client. Especially when the
root cause of the error is the request of the client it would be more beneficial when a more detailed fault message is
returned. Giving back the validation error instead of an internal server error would give the client information about
what is wrong with its request. How to set up the Web Service Proxy service in a way in which it sends the validation
error information in a SOAP fault message back to the client. This can be achieved in adding a OnError action to the
Web Service Proxy policy processing rules. You can add this OnError rule either in the default request rule or to a
specific rule on a specific level of the Order Service. When there would be more then one service subscription you
could add the OnError or any other action just to one of the services if necessary. Here we will add the OnError action
to the default request rule of the Web Service Proxy. Adding an on-error action at a specific point in a processing rule
means that the on-error action is triggered when any of the following processing steps (actions) contained in this rules
raises a fault. In order to do so click on the link MyWebServiceProxy_default_request_rule.
You will see this screen:
Figure 18. Default request rule

Stylesheet preparation
Before configuring the default request rule we have to create an XSLT stylesheet which will extract the fault
information and put it into the SOAP fault message later on. DataPower comes with some DataPower specific XSLT
extension functions. We have to use one of this extension functions to extract the fault information from one of the
build in service variables. This can be done by using the dp:variable()extension function. After extracting the fault
information the SOAP fault can be build.:
Stylesheet code
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
xmlns:dp="http://www.datapower.com/extensions" extensions-Element-prefixes="dp">
<xsl:variable name="error" select="dp:variable('var://service/error-message')"/>
<xsl:template match="/">
<soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header />

<soapenv:Body>
<soapenv:Fault>
<faultcode xmlns:p618="http://wsrr.integration/orderservice">
p618:placeOrder_orderFailurefMsg
</faultcode>
<faultstring>integration.wsrr.PlaceOrder_orderFailurefMsg</faultstring>
<detail encodingStyle="">
<p618:placeOrder_orderFailuref xmlns:p618="http://wsrr.integration/orderservice">
<xsl:value-of select="$error"/>
</p618:placeOrder_orderFailuref>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
</xsl:template>
</xsl:stylesheet>
After you have created the XSLT File either via a text editor or a development tool you have to upload the file to the
device. Go to the Web GUI again and select File Management under the Administration section of the left navigation
pane or on the Control Panel. Under theActions... menu of the local storage click on Upload Files:
Figure 19. Upload files

Rule configuration
Now the request rule and a new error rule has to be configured for having a kind of try and catch error handling.
Go to the default request rule and drag the Advanced icon behind (form left to right) the Match action. Double click on
the new yellow squared Advanced icon:

Activate the on-error radio button and click Next. Now the configuration wizard of the on-error action will appear. On
this configuration page it has to be specified which data are used for input of the on-error rule and which data is used
as output. In DataPower this data containers are called context. Since we want to build a new SOAP Fault message
we can use any input but must use the OUTPUT context for output, because the result of the on-error action
processing is written to this OUTPUT context. So specify (auto) as input of the on-error action

and OUTPUT as output. Error Mode will be abort because we don't want to correct the error and continue but discard
the request and send back an error to the client. Click Done:

On-error action configuration

After that a processing rule has to be defined. This rule determines the actions which has to be taken when the onerror rule is triggered. So click on the + sign to create a new processing rule. Name the new processing
rule MyErrorRule and choose error-rule as Rule Direction. Now add a action to this rule which executes the previously
created XSL stylesheet. Click the + sign on the lower right and name the actionMyErrorAction.
Choose xform as Action Type and use your recently uploaded stylesheet in the Transform field. Input will
be INPUT andOutput will be OUTPUT. You can now save all opened windows by pushing either Apply or Done. Here
are the settings:
Figure 22. Transform error action

Don't forget to apply the changes also to the policy on the left top of the policy configuration page, which should now
look like this:
Figure 23. Rule with error handling

Now you should save your configuration and test your changes by sending the invalid SOAP request.

The SOAP Fault message should not be the "Internal Server Error" anymore but detailed information about the
validation error.

2. Using the WS-Schema Validation Policy

Introduction
A common integration problem in an SOA occurs when consumers send messages to services that dont conform to
the services message schemas. Typically this is caused by the versioning of a services schema and a consumer
sending message defined in the prior schema version. However it can also be a consumers malicious attempt to
cause a denial of service by sending invalid messages to a service. A Manageability Container can aid by validating
the messages exchanged between the consumers and services against the services published schema.
Configuring the SOA Container to perform schema validation of messages is performed by the definition of schema
validation policies. The policies will indicate which messages to validate and possibly additional schemas to validate
against that may not be defined in the services WSDL document. Additional schemas are typically required when
validating expected headers in a bound (SOAP) message.

WS-Schema Validation Policy Assertion

The syntax of the WS-Schema Validation Policy assertion is as follows:

Syntax

wsvp:WSSchemaValidation
WS-Schema Validation policy assertion element.
wsvp:WSSchemaValidation/wsp:Policy
This element defines additional requirements for the WSSchemaValidation assertion.
wsvp:WSSchemaValidation/wsp:Policy/wsvp:ValidateHeaders
This optional element is an assertion that specifies that (SOAP) headers must be validated.
wsvp:WSSchemaValidation/wsp:Policy/wsvp:ValidateHeaders/{any}
This is an extensibility mechanism to allow additional elements to be specified.
wsvp:WSSchemaValidation/wsvp:AdditionalSchema

This optional element defines a schema (by referencing its URI) in addition to the message schema defined
in the services WSDL document that will be used when validating the message.
wsvp: WSSchemaValidation/wsvp:AdditionalSchema /@{any}
Additional attributes MAY be specified but MUST NOT contradict the semantics of the [owner element]; if an
attribute is not recognized, it SHOULD be ignored.
wsvp: WSSchemaValidation /@{any}
wsvp: WSSchemaValidation /@{any}
Additional attributes MAY be specified but MUST NOT contradict the semantics of the [owner element]; if an
attribute is not recognized, it SHOULD be ignored.
wsvp: WSSchemaValidation /{any}
This is an extensibility mechanism to allow additional elements to be specified.

An example of a WS-Schema Validation Policy is illustrated below.

Configuration Options

The policy includes the following configuration options:

Option

Description

Select
Schemas

Displays a list of schemas that are available in the file

system that can be selected and added to the policy.

Validation
Mode

Select Lax or Strict XML validation mode.

Lax - Validates only the XML elements that have a
namespace which matches a namespace of an
associated schema. Elements with no namespace or
those that do not have a namespace that matches a
schema namespace are skipped and not validated.
Lax validation is less stringent than strict validation and
is the default validation type.
Strict - Validates all XML elements against the applied
schemas. Each XML element must have a namespace
that matches a namespace of an associated schema,
otherwise the validation fails. Validates all XML

Option

Description
elements against the applied schemas. Each XML
element must have a namespace that matches a
namespace of an associated schema, otherwise the
validation fails.

Configuration
Let's take a quick walkthrough of the WS-Schema Validation Policy Policy configuration process to get your started.

Step 1: Add Policy / Use System Policy

You can create a WS-Schema Validation policy instance using Add Policy in the Policies > Operational
Policies section.
Step 2: Modify Policy

When you Modify the WS-Schema Validation Policy on the Policy Details page the initial policy will look like this:

Step 3: Configure

Configuring the WS-Schema Validation Policy is one step in a larger process. To configure the WS-Schema Validation
Policy:

Select the schemas you would like to add to the policy in the left column, and use >> to copy
them to the right column.

Select the validation mode (Lax or Strict)

Review the usage scenarios for each validation mode for the complete process.

Step 4: Attach Policy

After you have saved your policy you can attach it to a web service or you can attach the policy at the Organization
level and the policy will be active for all services defined within the orgnization.