Virtualized Service Sample Policy

Overview

The Virtualized Service sample policy is more advanced and combines the following features:

  • Content filtering, XML complexity, and message size filters to block unwanted SOAP messages.

  • Content filtering to block unwanted REST requests.

  • Fault handling.

  • Content-based routing.

This topic describes the policies displayed in the Sample Policies > Web Services > Virtualized StockQuote Service policy container in the Policy Studio, and explains how to run this sample.

Virtualized Service policies

The Virtualized StockQuote Service sample policy container includes the following policies:

  • Virtualized service main policy

  • Threat protection policy

  • Content-based routing policies

  • Response transformation policy

Virtualized Service Main Policy

The Main Policy is as follows:

Virtualized Service Main Policy

The Main Policy uses policy shortcuts to perform the following tasks:

  1. The main fault handler relies on some variables to be initialized, which is performed as soon as the policy is entered.

  2. The Threat Detection policy is applied to the incoming SOAP message and HTTP headers.

  3. The symbol value is extracted from the incoming message, and used to decide whether the request should be sent to one server instance or another.

  4. The name of the instance that served the request is added to the response.

  5. In case of errors, a global fault handler is invoked. This is used to return a custom error message to the user.

Threat Protection Policy

The Threat Protection policy is as follows:

Threat Protection policy

The Threat Protection policy performs the following tasks:

  1. The incoming request size (including attachments) is checked to be less than 1500 KB.

  2. The complexity of the XML is checked in terms of number of nodes, attributes per node, or number of child nodes per node.

  3. XML and eventually HTTP headers are checked for threatening content such as SQL injection or XML processing instructions.

  4. If any of these filters return an error, the corresponding error handler is called. The error handler is implemented as a policy that sets the value of the error code and message for this error, and then re-throws the exception so that the global fault handler catches it.

Content-based Routing Policies

The Route Based on Symbol Value policy extracts the contents of the symbol XML node and checks whether the first letter’s value is between A-L or K-Z. Depending on the result, it routes the request to the first or second instance of the StockQuote server. These servers are simulated by the following relative path URIs defined in the API Gateway:

  • /stockquote/instance1

  • /stockquote/instance2

The Route Based on Symbol Value policy is as follows:

Route Based on Symbol Value

The Route Based on Symbol Node policy performs the following tasks:

  1. The value of the symbol node is extracted from the request using XPath. The result is placed in a message attribute named message.symbol.value.

  2. A Switch on attribute value filter is used to check the value of the message attribute (using a regular expression), and a different policy is called to send the request to instance1 or instance2.

The Route to Instance1 policy is as follows:

Route to Instance1 Policy

The Route to Instance1 policy (called from the Switch filter) performs the following tasks:

  1. Connects to the instance1 URI .

  2. If successful, the instance name (instance1) is placed in a message attribute (stockquote.instance.name). This is used later on to insert the instance name into the response.

The Route to Instance2 policy performs the same tasks but using the instance2 URI instead.

Response Transformation Policy

When the response is obtained from the back-end server, the Add Instance Name to Response policy changes it to insert the instance name into a new XML node (instanceName). The Add Instance Name to Response policy is as follows:

Add Instance Name to Response Policy

This policy adds the instance name (the value of the stockquote.message.name message attribute) to the response, using an Add XML node filter, as part of the SOAPbody. XPath is used to define where the new node must be added.

Running the Virtualized Service Sample

You can call the sample service using the Send Request (sr) command or the API Gateway Explorer GUI:

SR Command

Enter the following command:

sr -f INSTALL_DIR/samples/SamplePolicies/VirtualizedService/Request.xml 
http://HOSTNAME:8081/main/stockquote

For more details, see the topic on Stress Testing with Send Request (SR).

API Gateway Explorer

Perform the following steps:

  1. Specify the following URL in the Request Settings:

    http://HOSTNAME:8081/main/stockquote

  2. Select POST as the verb.

  3. Click the Close button.

  4. Select File > Load, and browse to the following file as input for the request:

    INSTALL_DIR/samples/SamplePolicies/VirtualizedService/Request.xml

  5. Click the Send Request button.

For more details, see the topic on Sending a Request with API Gateway Explorer.