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 linkMyWebServiceProxy_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 thedp:variable()extension function. After extracting the fault information the SOAP fault can be build.:

Stylesheet code

p618:placeOrder_orderFailurefMsg

integration.wsrr.PlaceOrder_orderFailurefMsg

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 selectFile Managementunder theAdministrationsection of the left navigation pane or on theControl Panel. Under theActions...menu of the local storage click onUpload 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 theAdvancedicon behind (form left to right) theMatchaction. Double click on the new yellow squaredAdvancedicon:

Activate theon-errorradio button and clickNext. 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 calledcontext. Since we want to build a new SOAP Fault message we can use any input but must use theOUTPUTcontext for output, because the result of theon-erroraction processing is written to thisOUTPUTcontext. So specify(auto)asinputof the on-error action andOUTPUTasoutput.Error Modewill beabortbecause we don't want to correct the error and continue but discard the request and send back an error to the client. ClickDone:

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 on-error rule is triggered. So click on the+sign to create a new processing rule. Name the new processing ruleMyErrorRuleand chooseerror-ruleasRule 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. ChoosexformasAction Typeand use your recently uploaded stylesheet in theTransformfield.Inputwill beINPUTandOutputwill beOUTPUT. You can now save all opened windows by pushing eitherApplyorDone. 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 shouldsaveyour 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 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 usingAdd Policyin thePolicies > Operational Policiessection.

Step 2: Modify Policy

When youModifythe WS-Schema Validation Policy on thePolicy Detailspage 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 theusage scenariosfor 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.