9. Chapter 1
Human Resources Web Portal
This example configuration implements a human resources web portal benefits service, allowing
employees to request services from human resources through a web interface.
Scenario A: Web Services
The service is implemented initially to support departmental application servers submitting well-
formed SOAP requests to the DataPower system. The application servers interact with the end
user browsers. The headquarters IT systems employ task-specific Web service endpoints to handle
the range of HR information needs. Here is an illustration of the architecture involved.
Web Service 1
SOAP
HTML SOAP Web Service 2
DataPower SOAP
Web Service 3
Browsers App Servers
Figure 1 - 1. HR Web Service architecture
The traffic is monitored for transaction times that exceed a configured threshold. All errors are
logged in a special log target built for this service.
1-1
10. Human Resources Web Portal
Here is an example SOAP request supported by this service:
<?xml version="1.0" encoding="UTF-8"?>
<S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<S11:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>sfelinish</wsse:Username>
<wsse:Password>99cat99</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</S11:Header>
<S11:Body>
<xycohr:request xmlns:xycohr="http://xycohr.com/hrservices">
<xycohr:First_Name>Samantha</xycohr:First_Name>
<xycohr:Last_Name>Felinish</xycohr:Last_Name>
<xycohr:Employee_ID>7636356</xycohr:Employee_ID>
<xycohr:Department>Sales</xycohr:Department>
<xycohr:Requested_Service>floatholiday</xycohr:Requested_Service>
<xycohr:Service_Date>05/01/2005</xycohr:Service_Date>
</xycohr:request>
</S11:Body>
</S11:Envelope>
This implementation employs the following configured DataPower components.
• XML Firewall
• XML Firewall Policy
• Document Processing Rules
• Document Processing Actions
• XPath Routing Map
• Duration Monitor
• Log Target
In addition, service-specific stylesheets and schema files were uploaded to the device.
1-2 Release 3.6
11. Scenario A: Web Services
XML Firewall Service
The XML Firewall Service configuration page appears as shown here.
Figure 1 - 2. Web Services Firewall Configuration
These are the field values.
Firewall Name: XycoHRServices
The name of the firewall object. This name may appear in the Via: field of the
HTTP headers returned during SOAP and XML web service transactions. It
also appears in the log files.
Firewall Type: Dynamic backend
The selection Dynamic backend indicates that the servers to which the firewall
will forward requests are determined dynamically by the firewall’s document
processing policy. In this case the determination is accomplished through a
Route action that in turn employs an XPath Routing Map.
XML Manager: Default
The default is left in place.
Firewall Policy: XycoHRServices
The custom policy built for this service, XycoHRServices, is selected. This
policy is covered in detail below.
Release 3.6 1-3
12. Human Resources Web Portal
URL Rewrite Policy: None
The default is left in place. The URLs sent by the clients are not altered in any
way.
Back End
SSL Client Crypto Profile: None
The default is left in place. Communication with the back end servers will not
employ SSL in this case.
Response Type: SOAP
The selection SOAP indicates that the back end servers will post SOAP
documents in response to requests from the firewall service. The firewall
service automatically validates the documents against the SOAP schemas
now in use (SOAP 1.1, 1.2 and variants).
Response Attachments: Strip
The default value (strip) is left in place. Any attachments sent by the back end
service will be stripped off before the message is handled by the firewall
service.
Front End
Device Address: 0.0.0.0
The default value of 0.0.0.0 is used. The service will listen at the port
indicated on all ethernet addresses configured for the current device.
Device Port: 2065
The automatically assigned value of 2075 is used. This could be altered to any
value not used by another service on the current device. All traffic bound for
this service must use port number 2075. The SOAP HTTP URL resembles
http://10.10.13.35:2075/services.
SSL Server Crypto Profile: None
The default is left in place. Communication with the front end clients will not
employ SSL in this case.
Request Type: SOAP
The selection SOAP indicates that the clients will post SOAP-formatted
documents to the firewall service. Inbound SOAP documents are
automatically validated against the published SOAP schemas. If the
messages do not comply with the schemas, an error is returned to the client.
Request Attachments : Strip
The default value (strip) is left in place. Any attachments sent by the clients
will be stripped off before the message is handled by the firewall service.
1-4 Release 3.6
13. Scenario A: Web Services
Here is the Advanced configuration page for this service:
Figure 1 - 3. Advanced configuration page
All defaults are left in place with the exception of the Message Duration Monitor. Here, the
custom configured Xycohr Duration Monitor is assigned to the service.
Release 3.6 1-5
14. Human Resources Web Portal
Firewall Policy
Here is the graphic representation of the firewall policy used for this implementation.
Figure 1 - 4. XycoHRServices Firewall Policy
Here is a brief explanation of the column headings under Configured Rules:
Priority The order in which the rules are executed by the policy.
When two rules have a matching rule that could potentially
match the inbound document, the rule with the highest
priority executes first.
Match Name This lists the name of the Matching Rule used to select
inbound traffic for execution by the processing actions
contained in the rule.
Direction This indicates the directionality of the rule. Request rules
handle inbound traffic from the front end clients, response
rules handle responses from the back end services, and Error
rules execute when an error is encountered.
Actions The iconic representation of the actions contained in the rule.
Click on any of the rules listed here to make the rule the current rule. The main display of the page
changes to that rule. The action configurations can then be modified.
1-6 Release 3.6
15. Scenario A: Web Services
Rules
Rule #1: Request Rule
Here is an examination of the components of Rule #1. Note that this is a Request rule; it will only
handle messages sent to the service by the client and will not handle messages sent by the server
back to the client.
Match Rule: Services
A Match Rule examines the inbound message and determines whether or not the rule should be run
against the message. In this case, the match rule examines the URL used by the client to determine
a match. Here is the configuration display of the match rule maps.
Figure 1 - 5. Services Match Rule Configuration
The client must use the URL */services or this rule will not be applied to the message. Note that the
expression * means “any substring of any characters.”
Implied Action 0: Validate
The firewall automatically validates the inbound message against the SOAP schemas, to insure
that no message that does not conform to the SOAP schemas will be sent to the back end web
service endpoints. This SOAP schema filtering is implied and no action needs to be created for it.
However, the presence of this valildation action can cause inbound messages to be rejected by the
firewall before any of the actions visible in the Firewall Policy have run.
Release 3.6 1-7
16. Human Resources Web Portal
Action 1: Validate
The first custom action of Rule #1 validates the contents of the SOAP Body element against a
custom schema. This insures that the payload also contains the required elements and does not
contain invalid elements. Here is the configuration of this action:
Figure 1 - 6. Validate Configuration
Input: INPUT
This is set to INPUT, the special context representing the original message
received by the service.
Schema Validation Method: Schema URL
This is set to validate the document using a schema URL. A URL must be
provided that identifies the location of the schema file to use.
Schema URL: local:///Xycohr.xsd
This is set to local:///Xycohr.xsd. The custom schema file has been uploaded to
the device and placed in the local: directory.
Output: tmpvar2
This is set to tmpvar2. The results of the validation will be placed in this
context. If the input is valid, the context will contain the validated message. If
an error occurs (the message fails to validate, for example), the context is
empty. Any subsequent actions can access the results by using tmpvar2 as the
input context.
1-8 Release 3.6
17. Scenario A: Web Services
Here is the schema file used for this action.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xycohr="http://xycohr.com/hrservices"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" target-
Namespace="http://xycohr.com/hrservices" elementFormDefault="qualified">
<xs:element name="request" type="xycohr:hrrequest"/>
<xs:complexType name="hrrequest">
<xs:sequence>
<xs:element name="UserName" type="xs:string" minOccurs="0"/>
<xs:element name="Password" type="xs:string" minOccurs="0"/>
<xs:element name="First_Name" type="xs:string"/>
<xs:element name="Last_Name" type="xs:string"/>
<xs:element name="Employee_ID" type="xs:string"/>
<xs:element name="Department" type="xs:string"/>
<xs:element name="Requested_Service" type="xs:string"/>
<xs:element name="Service_Date" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Action 2: Filter
This action filters the validated message for the presence of required values within the message. It
either accepts or rejects the message. Here is the configuration display for this action:
Figure 1 - 7. Filter Configuration
Input: tmpvar2
This is set to tmpvar2, the named context used by the preceeding action. Note
that this could have been set to INPUT since this action would not execute if
the validation before it failed. However, validation can sometimes change the
message format, thus this action uses the result of the validation.
Release 3.6 1-9
18. Human Resources Web Portal
Processing Control File: local:///Xycohr.xsl
This is set to local:///Xycohr.xsl. The custom XSLT file has been uploaded to the
device and placed in the local: directory.
Output: (blank)
This is set to be automatically generated by the policy configuration page.
Unlike a transform or a validate action, a filter action typically does not return
a nodeset. It accepts or rejects the input for further processing by the next
action in the rule.
Here is the XSLT file used for this Filter action:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" extension-element-prefixes="dp"
xmlns:dp="http://www.datapower.com/extensions" exclude-result-prefixes="dp">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<!-- the SOAP envelope must be taken into account -->
<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-
name()='request']"/>
</xsl:template>
<xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='request']">
<xsl:variable name="errtext" select="'Incomplete Input'"/>
<xsl:variable name="errtest">
<!-- don't allow blank fields; all are required -->
<xsl:for-each select="./*">
<xsl:if test="string-length() = 0">
<xsl:value-of select="local-name()"/>:
</xsl:if>
</xsl:for-each>
</xsl:variable>
<xsl:choose>
<!-- $errtest will only have content if some element is blank; if so reject the message -->
<xsl:when test="$errtest != ''">
<dp:xreject reason="$errtext"/>
<!-- put a message in the log file; $errtest contains the names of the offending ele-
ments -->
<xsl:message dp:type="xmlfirewall" dp:priority="error">
<xsl:value-of select="$errtest"/>
</xsl:message>
</xsl:when>
<xsl:otherwise>
<!-- all is well -->
<dp:accept/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
1 - 10 Release 3.6
19. Scenario A: Web Services
Action 3: Transform
This tranform action serves to connect the last context that contained the possibly altered message
to any actions that follow. The policy configuration page automatically creates this action
following a filter. Here is the configuration page display for this action.
Figure 1 - 8. Transform Configuration
Input: tmpvar2
This is set to tmpvar2, the named context used by the preceeding action. Note
that this could have been set to INPUT since this action would not execute if
the validation before it failed. However, validation can sometimes change the
message format, thus this action uses the result of the validation.
Document Processing Instructions: Specified by rule
This is set to use an XSLT file specified in this rule rather than any
instructions contained within the XML message itself.
Processing Control File: store:///identity.xsl
This is set to store:///identity.xsl. This XSLT file is supplied with the firmware.
It simply copies the input to the output context.
Output tempvar3
This is set to tempvar3. The policy configuration page automatically assigned
this context name.
Release 3.6 1 - 11
20. Human Resources Web Portal
Action 4: Route
This action dynamically routes the message to a target destination, which is, in this scenario, one
of three Web service endpoints. This action uses an XPath Routing Map object to determine the
proper destination target.
Figure 1 - 9. Route Configuration
Input: tempvar3
This is set to tempvar3, the named Output context used by the preceeding
action.
Selection Method: XPath Routing Map
This is set to use an XPath Routing Map.
XPath Routing Map: xycohr
This is set to xycohr. This is the name of a configured XPath Routing Map
object that uses XPath expressions to extract values from the message. Those
values are then used to match the message with a destination target. The
XPath Routing Map is explained below.
Output: (Blank)
This is set to blank. A Route action does not output a nodeset. Note that
because it does not, it will be necessary to include one more action in the rule
to connect the last context that contains the full message to the special
OUTPUT context, which is what is sent out on the wire to the destination
target.
XPath Routing Map: xycohr
An XPath Routing Map associates an XPath expression with a destination URL. When the XPath
expression evaluates to true, the target destination for the message is set to the corresponding
URL. These mappings for this implementation are shown in Figure X below.
An XPath Routing Map object can also use Namespace Mappings to associate namespace prefixes
in the XPath expression maps to namespace URIs. This shortens the length of the XPath
expressions while preserving namespace information. This example does not use namespace
mapping.
1 - 12 Release 3.6
21. Scenario A: Web Services
Here is the configuration display of this object.
Figure 1 - 10. XPath Routing Map Configuration
Note that the destinations are mapped according to the value of the Requested_Service node. These
are mapped to endpoint operations at the destination server ports. If no match is found by this
Route action using the above mappings, the object returns an error to the client. The next object
never executes.
Action 5: Transform
Like Action 3, this transform connects the last context containing the message to the next action,
or to the OUTPUT context. This is necessary because the Route action does not return a nodeset
when doing its work. This is the final action of the rule; if this action executes at all, then the
Route has succeeded and all is clear for delivery to the back end service.
Release 3.6 1 - 13
22. Human Resources Web Portal
Here is the configuration display for this object.
Figure 1 - 11. Transform Configuration
Input: tempvar3
This is set to tempvar3, the named output context used by the action
preceeding the Route action.
Processing Control File: store:///identity.xsl
This is set to store:///identity.xsl. This stylesheet is supplied with the firmware.
Output: OUTPUT
This is set to OUTPUT, the special context that is delivered to the wire. As this
is the last action of the rule, whatever is in this context is sent to the
destination determined by the Route action. The message goes off to the
appropriate back end Web services endpoint.
When a submitted message succeeds in transversing the firewall processing policy, the message
appears exactly as it did when it was submitted.
1 - 14 Release 3.6
23. Scenario A: Web Services
Rule #2: Response Rule
Rule #2 in this policy is a Response rule. It handles messages returned to the service from the back
end servers. Note that the Match rule is the same as the Request; the server must reflect the same
URI in its response as the client.
Implied Action 0: Validate
The firewall automatically validates the response message against the SOAP schemas, to insure
that no message that does not conform to the SOAP schemas will be sent back to the client. This
SOAP schema filtering is implied and no action needs to be created for it. However, the presence
of this valildation action can cause response messages to be rejected by the firewall before any of
the actions visible in the Firewall Policy have run.
Action 1: Transform
This action is present to transform the response from the server prior to delivering it to the
requesting client. In this case, it inserts a DataPower transaction ID into the resulting message for
tracing purposes.
Here is the configuration display for this action:
Figure 1 - 12. Response Transform Configuration
Input: INPUT
This is set to INPUT, the special input context containing the original message
from the back end server.
Processing Control File: local:///xycosvcresponse.xsl
This is set to local:///xycosvcresponse.xsl. This custom stylesheet has been
uploaded to the device.
Output: OUTPUT
This is set to OUTPUT, the special context that is delivered to the wire. As this
is the last action of the rule, whatever is in this context is sent back to the
client as the response from the service.
Release 3.6 1 - 15
24. Human Resources Web Portal
Here is the XSLT stylesheet used for this action:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/
extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-
prefixes="dp dpconfig">
<xsl:output method="xml"/>
<xsl:template match="/">
<xsl:apply-templates select="/*[local-name()='Envelope']"/>
</xsl:template>
<xsl:template match="/*[local-name()='Envelope']">
<S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/
wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']"/>
</S11:Envelope>
</xsl:template>
<!-- omit the header, leaving the uid/pwd behind -->
<xsl:template match="/*[local-name()='Header']">
<xsl:copy-of select="."/>
</xsl:template>
<xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']">
<S11:Body xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/">
<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']"/>
</S11:Body>
</xsl:template>
<xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']">
<xycohr:response xmlns:xycohr="http://xycohr.com/hrservices">
<xsl:for-each select="./*">
<xsl:copy-of select="."/>
</xsl:for-each>
<xycohr:trans-id>
<!-- get the DP transaction id and insert it into the response -->
<xsl:variable name="rmsg" select="dp:variable('var://service/transaction-id')"/>
<xsl:value-of select="$rmsg"/>
</xycohr:trans-id>
</xycohr:response>
</xsl:template>
</xsl:stylesheet>
1 - 16 Release 3.6
25. Scenario A: Web Services
Here is an example of the completed round-trip response to the original request:
<?xml version="1.0" encoding="UTF-8"?>
<S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/">
<S11:Body>
<xycohr:response xmlns:xycohr="http://xycohr.com/hrservices">
<xycohr:First_Name>Samantha</xycohr:First_Name>
<xycohr:Last_Name>Felinish</xycohr:Last_Name>
<xycohr:Employee_ID>7636356</xycohr:Employee_ID>
<xycohr:Department>Sales</xycohr:Department>
<xycohr:Requested_Service>floatholiday</xycohr:Requested_Service>
<xycohr:Service_Date>05/01/2005</xycohr:Service_Date>
<xycohr:result>
<xycohr:ticket>47846787498</xycohr:ticket>
<xycohr:message>Your request has been received. You will receive email confir-
mation regarding the floating holiday you requested within 24 hours. Have a great day.
</xycohr:message>
</xycohr:result>
<xycohr:trans-id>132357</xycohr:trans-id>
</xycohr:response>
</S11:Body>
</S11:Envelope>
Release 3.6 1 - 17
26. Human Resources Web Portal
Rule #3: Error Rule
Rule #3 in this policy is an Error rule. It handles any errors encountered during the processing of
either the request or the response rule. Note that a Matching Rule is also used for an Error rule. It
is possible to match on particular error codes. In this case, however, the Match is the same for all
other rules. The URL must match the expression */services.
Action 1: Transform
This action is present to transform the error message generated by the DataPower processing
system into something else that includes a traceable transaction number. This is often done to
provide an error message that will be more acceptable to the end user community, or to provide
more or different information.
Here is the configuration display for this action:
Figure 1 - 13. Error Transform Configuration
Input: INPUT
This is set to INPUT, the special input context containing the original message
from the back end server.
Processing Control File: local:///xyerrormsg.xsl
This is set to local:///xyerrormsg.xsl. This custom stylesheet has been uploaded
to the device.
Output: OUTPUT
This is set to OUTPUT, the special context that is delivered to the wire. As this
is the last action of the rule, whatever is in this context is sent back to the
client as the response from the service.
1 - 18 Release 3.6
27. Scenario A: Web Services
Here is the XSLT used for this action:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/
extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-
prefixes="dp dpconfig">
<xsl:output method="xml"/>
<xsl:template match="/">
<!-- This is not <xsl:copy-of select="."/> which would forward the service-generated message.
Instead, this file creates a customized error message -->
<env:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-
1.0.xsd" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body>
<env:Fault>
<!-- get the DP transaction ID and include it for troubleshooting -->
<xsl:variable name="err" select="dp:variable('var://service/transaction-id')"/>
<env:faultcode>
<xsl:value-of select="$err"/>
</env:faultcode>
<env:faultstring>Invalid submission. Please submit a valid request or notify youradministrator of this error
and reference the faultcode number.</env:faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
</xsl:template>
</xsl:stylesheet>
Release 3.6 1 - 19
28. Human Resources Web Portal
Duration Monitor
This firewall service employs a Duration Monitor, which watches all traffic passing through the
system. When the processing of a message, from the moment the request enters the DataPower
system to the moment the response leaves the DataPower system, takes more time than allowed by
the monitor, the monitor posts a warning notice into the log message stream. Monitors can be
configured to do more than simply post messages; monitors can throttle back traffic, allowing
some component (usually the back end service) to recover from an overload of requests. In this
example, a message is posted to the logs.
A Duration Monitor object relies on three other objects. The relationship of these objects is shown
here.
Duration Monitor Message Type Message Match
Message Filter Action
Figure 1 - 14. Monitor Object Relationship
Message Match
At the lowest, or first level, the monitor will only watch messages that match some criteria. This is
determined by the Message Match object. Here is the Message Match object configuration used
by Xyco:
Figure 1 - 15. Message Match Configuration
This monitor will only watch messages that are sent to the service via an HTTP Post. Since all
other fields are blank, no other restrictions are placed on the messages monitored. Note that the
Request URL field could have been set to “*/services”, thus restricting the monitor to only those
requests that would meet the processing rule matching criteria. In this case, it is left open, thus
1 - 20 Release 3.6
29. Scenario A: Web Services
setting up a monitor that will also watch for invalid requests that take more than a set amount of
time to reject.
Messages can also be matched by HTTP Header Values or by messages that don’t contain certain
HTTP Header values. For example, a match could be constructed to match only HTTP Header
values that indicate the message is SOAP. Neither of those constraints are used in this example.
Message Type
The Message Type object is a collection of Message Matching objects. Message Type objects
make it possible to combine various Message Matching objects into one type. Each Message Type
can use a different combination of Message Matching objects. Here is the configuration for this
example:
Figure 1 - 16. Message Type Configuration
Only the one Message Match object is used. All HTTP Post messages are thus included in this
Type.
Release 3.6 1 - 21
30. Human Resources Web Portal
Message Filter Action
A Message Filter Action object determines what action to take when the Filter is invoked. Here is
the Message Filter Action object used by this monitor:
Figure 1 - 17. Message Filter Action Configuration
Type: notify
A log message will be posted (notification will be sent). The next field
determines the severity level of the message. This field can also be set to
“reject”, in which case the monitor will reject messages once the monitor’s
threshold is reached. An unseen “Block Interval” field determines for how
long messages will be rejected. This configuration does not take this drastic
measure. However, if enough messages are posted by the monitor, this setting
may be changed here.
Log Priority: warning
Log messages (notification) posted by this monitor will have the severity
level of “warning”. Any log targets set to capture messages at or below the
level of warning will capture posted notification messages.
1 - 22 Release 3.6
31. Scenario A: Web Services
Duration Monitor Object
The top level Duration Monitor object ties together the other three objects to create a single
capability. Here is the configuration display for this example:
Figure 1 - 18. Duration Monitor Main Configuration
Message Type: xycohr
All messages of the type “xycohr” will be monitored. As shown above, this in
effect means all HTTP Post messages.
Measure: messages
The duration monitored is that of each message - the amount of time it takes
between initial receipt of the message from the client to the dispatch of the
response. A monitor could be set to measure only requests (the time it takes
to process the request), response (the time it takes to process the response),
server (the time between dispatch of the message to the back end service to
the receipt of the answer) and finally messages.
Release 3.6 1 - 23
32. Human Resources Web Portal
Thresholds for this monitor are set on the Filter tab. The Filter tab configuration appears as
follows:
Figure 1 - 19. Duration Monitor Filter Configuration
Name: xycohr
This is the name of the threshold.
Type: average
This threshold is measuring the average duration of message processing time.
This is the only available selection.
Value: 5000
The number of milliseconds at which the threshold is reached.
Action: xycohrsvc
This is the Message Filter Action configured above. When the monitor
discovers that the average processing time, end to end, of a message hits 5000
milliseconds, it will post a message to the logging system.
1 - 24 Release 3.6
33. Scenario A: Web Services
Logging
This example employs a custom log target, which captures messages generated by the services
handling the XyCo HR web services traffic. Here is the configuration display of the custom Log
Target object Main page:
Figure 1 - 20. Log Target Main Configuration
Type: File
This log target captures messages into a file on the flash.
Format: XML
The log messages are stored in the file in XML format. Because this is true, it
is possible to view the logs using the WebGUI interface.
Timestamp: syslog
All timestamps in the messages are formatted in the standard syslog format.
This is what is commonly supported by off-device logging monitors.
Release 3.6 1 - 25
34. Human Resources Web Portal
Log Size (in kb): 500
The file will grow only to 500 kilobytes. As the entire flash filesystem is
limited in size, this file should not be large.
Filename: logtemp:///xycohr.log
The log entries are captured in this file.
Archive Mode: Rotate
Once the log file reaches the limit in size, it is rotated. A copy of the current
file is placed on the flash and a new file opened.
Rotations: 3
When the archive method for a file is Rotate, this determines how many
copies of the file are created before the last one is overwritten.
Note that when a device is rebooted (as opposed to the firmware reloaded), all temporary files are
erased. For this reason, log files are often moved off the device for storage. Here is an example
configuration using FTP to move the log file off the device when it is time to begin a new file.
Figure 1 - 21. Upload Log File Configuration
Object Filters
Log targets capture messages by Object Filters and Event Subscriptions. Object filters determine
what messages will be captured according to source object.
1 - 26 Release 3.6
35. Scenario A: Web Services
Figure 1 - 22. Log Target Object Filter Configuration
Only messages generated by the objects of the classes shown with the names shown are eligible for
capture.
Event Subscriptions
Event Subscrptions determine at what level of priority messages are captured. Here is the
configuration display for this example:
Figure 1 - 23. Log Target Event Subscription Configuration
This indicates that all messages of severity notice or higher will be captured. Above notice are
warning, error, critical, alert and emergency.
Release 3.6 1 - 27
36. Human Resources Web Portal
Scenario B: An HTML Forms Service
After the DataPower connection between the departmental application servers and the back end
web services endpoints was successfully deployed and run for some while, the CIO looked at the
architecture and asked if were possible for the DataPower system to connect directly to end user
browsers, which would submit a standard HTML Form to request service, thus eliminating the
application server layer from the architecture. This would reduce costs and increase simplicity.
Here is the resulting architecture:
Web Service 1
SOAP
Many Browsers HTML Web Service 2
DataPower SOAP
Web Service 3
Figure 1 - 24. Browser-to-Service Architecture
It is entirely possible to implement this architecture using a DataPower system he was told. Show
me, he said. Here is the HTML form supported by this service:
Figure 1 - 25. End User HTML Form
1 - 28 Release 3.6
37. Scenario B: An HTML Forms Service
XML Firewall Service
The XML Firewall Service configuration page appears as shown here.
Figure 1 - 26. Web Services Firewall Configuration
These are the field values.
Firewall Name: HTTPForms
The name of the firewall object. This name may appear in the Via: field of the
HTTP headers returned during SOAP and XML web service transactions. It
also appears in the log files.
Firewall Type: Dynamic backend
The selection Dynamic backend indicates that the servers to which the firewall
will forward requests are determined dynamically by the firewall’s document
processing policy. In this case the determination is accomplished through a
Route action that in turn employs an XPath Routing Map.
XML Manager: Default
The default is left in place.
Firewall Policy: XycoHRForms
The custom policy built for this service, XycoHRServices, is selected. This
policy is covered in detail below.
Release 3.6 1 - 29
38. Human Resources Web Portal
URL Rewrite Policy: None
The default is left in place. The URLs sent by the clients are not altered in any
way.
Back End
SSL Client Crypto Profile: None
The default is left in place. Communication with the back end servers will not
employ SSL in this case.
Response Type: SOAP
The selection SOAP indicates that the back end servers will post SOAP
documents in response to requests from the firewall service. The firewall
service automatically validates the documents against the SOAP schemas
now in use (SOAP 1.1, 1.2 and variants).
Response Attachments: Strip
The default value (strip) is left in place. Any attachments sent by the back end
service will be stripped off before the message is handled by the firewall
service.
Front End
Device Address: 0.0.0.0
The default value of 0.0.0.0 is used. The service will listen at the port
indicated on all ethernet addresses configured for the current device.
Device Port: 2075
The automatically assigned value of 2075 is used. This could be altered to any
value not used by another service on the current device. All traffic bound for
this service must use port number 2075. The SOAP HTTP URL resembles
http://10.10.13.35:2075/services.
SSL Server Crypto Profile: XycoHRWeb
Communication with the front end clients will employ SSL in this case. The
cryptographic profile XycoHRWeb will be used, which in turn identifies the
cryptographic certificate and private keys used for SSL communications.
Request Type: XML
The selection XML indicates that the clients will not post SOAP-formatted
documents to the firewall service. The service will initially expect XML-
formatted documents.
Request Attachments: Strip
The default value (strip) is left in place. Any attachments sent by the clients
will be stripped off before the message is handled by the firewall service.
1 - 30 Release 3.6
39. Scenario B: An HTML Forms Service
Here is the Advanced configuration page for this service:
Figure 1 - 27. Advanced configuration page
All defaults are left in place with the exception of the Message Duration Monitor. Here, the
custom configured Xycohr Duration Monitor is assigned to the service. Note that this reuses the
same Monitor as used for the Web Services implementation.
Release 3.6 1 - 31
40. Human Resources Web Portal
Firewall Policy
Here is the graphic representation of the firewall policy used for this implementation.
Figure 1 - 28. XycoHRForms Firewall Policy
Note that this policy resembles that of the Web Services policy beginning with the Validate action.
1 - 32 Release 3.6
41. Scenario B: An HTML Forms Service
Rules
Rule #1: Request Rule
Here is an examination of the components of Rule #1. Note that this is a Request rule; it will only
handle messages sent to the service by the client and will not handle messages sent by the server
back to the client.
Match Rule: Forms
A Match Rule examines the inbound message and determines whether or not the rule should be run
against the message. In this case, the match rule examines the URL used by the client to determine
a match. Here is the configuration display of the match rule maps.
Figure 1 - 29. Forms Match Rule Configuration
The client must use the URL */forms or this rule will not be applied to the message. Note that the
expression * means “any substring of any characters.”
Release 3.6 1 - 33
42. Human Resources Web Portal
Action 1: Convert-http
The first action of this policy converts the data posted by an HTTP Form into an XML document.
The presence of this action in this rule and policy alerts the service to accept inbound submissions
that are not necessarily XML documents. Here is the configuration display of this action.
Figure 1 - 30. Convert-http Action Configuration
This is a very simple configuration. If a custom conversion of HTTP Input characters were needed
or desired, that could be accomplished by configuring an Input Conversion object. Note that the
Output context is tmpvar1, which was entered by hand.
Action 2: Transform
This tranform action serves to convert the XML created by the Convert-http action into something
more usable. Here is an example of the result of the Convert-http action:
<?xml version="1.0" encoding="UTF-8" ?>
<request>
<url>/forms</url>
<base-url>/forms</base-url>
<args src="url" />
<args src="body">
<arg name="UserName">JBrown</arg>
<arg name="Password">lad;fj</arg>
<arg name="First_Name">Jack</arg>
<arg name="Last_Name">Brown</arg>
<arg name="Employee_ID">03498</arg>
<arg name="Department">Engineering</arg>
<arg name="Requested_Service">floatholiday</arg>
<arg name="Service_Date">05/10/05</arg>
</args>
</request>
1 - 34 Release 3.6
43. Scenario B: An HTML Forms Service
Here is the configuration page display for this action.
Figure 1 - 31. Transform Configuration
Input: tmpvar1
This is set to tmpvar1, the named context used by the preceeding action.
Document Processing Instructions: Specified by rule
This is set to use an XSLT file specified in this rule rather than any
instructions contained within the XML message itself.
Processing Control File: local:///ConvertForm.xsl
This is set to local:///ConvertForm.xsl. This XSLT file was uploaded to the
device and stored in the local: directory..
Output: tmpvar2
This is set to tempvr2. This value was entered during configuration.
Release 3.6 1 - 35
44. Human Resources Web Portal
Here is the stylesheet used for this transform action:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<xsl:apply-templates select="/request/args"/>
</xsl:template>
<xsl:template match="request">
<xsl:copy-of select="."/>
</xsl:template>
<xsl:template match="args">
<xsl:if test="@src = 'body'">
<xsl:element name="xycohr:request" namespace="http://xycohr.com/hrservices">
<xsl:for-each select="arg">
<xsl:element name="xycohr:{@name}" namespace="http://xycohr.com/hrservices">
<xsl:value-of select="."/>
</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:if>
</xsl:template>
</xsl:stylesheet>
Here is the result of the transform:
<?xml version="1.0" encoding="UTF-8"?>
<xycohr:request xmlns:xycohr="http://xycohr.com/hrservices">
<xycohr:UserName>JBrown</xycohr:UserName>
<xycohr:Password>lad;fj</xycohr:Password>
<xycohr:First_Name>Joe</xycohr:First_Name>
<xycohr:Last_Name>Brown</xycohr:Last_Name>
<xycohr:Employee_ID>03498</xycohr:Employee_ID>
<xycohr:Department>Engineering</xycohr:Department>
<xycohr:Requested_Service>floatholiday</xycohr:Requested_Service>
<xycohr:Service_Date>05/10/05</xycohr:Service_Date>
</xycohr:request>
1 - 36 Release 3.6
45. Scenario B: An HTML Forms Service
Action 3: Validate
This action validates the transformed contents of the message against a custom schema. This
insures that the payload also contains the required elements and does not contain invalid elements.
Here is the configuration of this action:
Figure 1 - 32. Validate Configuration
Input: tmpvar2
This is set to tmpvar2, the context containing the result of the transform.
Schema Validation Method: Schema URL
This is set to validate the document using a schema URL. A URL must be
provided that identifies the location of the schema file to use.
Schema URL: local:///Xycohr.xsd
This is set to local:///Xycohr.xsd. The custom schema file has been uploaded to
the device and placed in the local: directory.
Output: tmpvar3
This is set to tmpvar2. The results of the validation will be placed in this
context. If the input is valid, the context will contain the validated message. If
an error occurs (the message fails to validate, for example), the context is
empty. Any subsequent actions can access the results by using tmpvar3 as the
input context.
Release 3.6 1 - 37
46. Human Resources Web Portal
Here is the schema file used for this action.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xycohr="http://xycohr.com/hrservices"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" target-
Namespace="http://xycohr.com/hrservices" elementFormDefault="qualified">
<xs:element name="request" type="xycohr:hrrequest"/>
<xs:complexType name="hrrequest">
<xs:sequence>
<xs:element name="UserName" type="xs:string" minOccurs="0"/>
<xs:element name="Password" type="xs:string" minOccurs="0"/>
<xs:element name="First_Name" type="xs:string"/>
<xs:element name="Last_Name" type="xs:string"/>
<xs:element name="Employee_ID" type="xs:string"/>
<xs:element name="Department" type="xs:string"/>
<xs:element name="Requested_Service" type="xs:string"/>
<xs:element name="Service_Date" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Action 4: Filter
This action filters the validated message for the presence of required values within the message. It
either accepts or rejects the message. Here is the configuration display for this action:
Figure 1 - 33. Filter Configuration
Input: tmpvar3
This is set to tmpvar3, the named context used by the preceeding action.
Processing Control File: local:///XycohrForms.xsl
This is set to local:///XycohrForms.xsl. The custom XSLT file has been uploaded
to the device and placed in the local: directory.
Output: (blank)
This is set to be automatically generated by the policy configuration page.
Unlike a transform or a validate action, a filter action typically does not return
1 - 38 Release 3.6
47. Scenario B: An HTML Forms Service
a nodeset. It accepts or rejects the input for further processing by the next
action in the rule.
Here is the XSLT file used for this Filter action:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" extension-element-prefixes="dp"
xmlns:dp="http://www.datapower.com/extensions" exclude-result-prefixes="dp">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<!--no SOAP envelope -->
<xsl:apply-templates select="/*[local-name()='request']"/>
</xsl:template>
<xsl:template match="/*[local-name()='request']">
<xsl:variable name="errtext" select="'Incomplete Input'"/>
<xsl:variable name="errtest">
<!-- don't allow blank fields; all are required -->
<xsl:for-each select="./*">
<xsl:if test="string-length() = 0">
<xsl:value-of select="local-name()"/>:
</xsl:if>
</xsl:for-each>
</xsl:variable>
<xsl:choose>
<!-- $errtest will only have content if some element is blank; if so reject the message -->
<xsl:when test="$errtest != ''">
<dp:xreject reason="$errtext"/>
<!-- put a message in the log file; $errtest contains the names of the offending elements -->
<xsl:message dp:type="xmlfirewall" dp:priority="error">
<xsl:value-of select="$errtest"/>
</xsl:message>
</xsl:when>
<xsl:otherwise>
<!-- all is well -->
<dp:accept/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
Release 3.6 1 - 39
48. Human Resources Web Portal
Action 5: Transform
This action serves to transform the now validated and filtered payload into a fully compliant SOAP
message, and to connect the last context that contained the possibly altered message to any actions
that follow. Here is the configuration page display for this action.
Figure 1 - 34. Transform Configuration
Input: tmpvar3
This is set to tmpvar3, the named context used by the preceeding action.
Document Processing Instructions: Specified by rule
This is set to use an XSLT file specified in this rule rather than any
instructions contained within the XML message itself.
Processing Control File: local:///InsertWSSHeaders.xsl
This is set to local:///InsertWSSHeaders.xsl. This custom XSLT file converts the
payload into a SOAP-compliant message with WS-Security headers.
Output: tmpvar4
This is set to tmpvar4. This was entered during configuration.
1 - 40 Release 3.6
49. Scenario B: An HTML Forms Service
Here is the XSLT file used for this action:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-
1.0.xsd" xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/">
<S11:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>
<xsl:value-of select="/*[local-name()='request']/*[local-name()='UserName']"/>
</wsse:Username>
<wsse:Password>
<xsl:value-of select="/*[local-name()='request']/*[local-name()='Password']"/>
</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</S11:Header>
<S11:Body>
<xsl:element name="xycohr:request" namespace="http://xycohr.com/hrservices">
<xsl:for-each select="/*[local-name()='request']/*">
<xsl:if test="local-name() != 'UserName' and local-name() != 'Password'">
<xsl:copy-of select="."/>
</xsl:if>
</xsl:for-each>
</xsl:element>
</S11:Body>
</S11:Envelope>
</xsl:template>
</xsl:stylesheet>
Here is the message after this transform completes successfully:
<?xml version="1.0" encoding="UTF-8"?>
<S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<S11:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>JBrown</wsse:Username>
<wsse:Password>lad;fj</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</S11:Header>
<S11:Body>
<xycohr:request xmlns:xycohr="http://xycohr.com/hrservices">
<xycohr:First_Name>Joe</xycohr:First_Name>
<xycohr:Last_Name>Brown</xycohr:Last_Name>
<xycohr:Employee_ID>377389</xycohr:Employee_ID>
<xycohr:Department>Engineering</xycohr:Department>
<xycohr:Requested_Service>floatholiday</xycohr:Requested_Service>
<xycohr:Service_Date>05/10/2005</xycohr:Service_Date>
</xycohr:request>
</S11:Body>
</S11:Envelope>
Release 3.6 1 - 41
50. Human Resources Web Portal
Action 6: Route
This action dynamically routes the message to a target destination, which is, in this scenario, one
of three Web service endpoints. This action uses an XPath Routing Map object to determine the
proper destination target.
Figure 1 - 35. Route Configuration
Input: tmpvar4
This is set to tmpvar4, the named context used by the preceeding action.
Selection Method: Path Routing Map
This is set to use an XPath Routing Map.
XPath Routing Map: xycohr
This is set to xycohr. This is the name of a configured XPath Routing Map
object that uses XPath expressions to extract values from the message. Those
values are then used to match the message with a destination target. The
XPath Routing Map is explained below.
Output: (Blank)
This is set to blank. A Route action does not output a nodeset. Note that
because it does not, it will be necessary to include one more action in the rule
to connect the last context that contains the full message to the special
OUTPUT context, which is what is sent out on the wire to the destination
target.
XPath Routing Map: xycohr
An XPath Routing Map associates an XPath expression with a destination URL. When the XPath
expression evaluates to true, the target destination for the message is set to the corresponding
URL. These mappings for this implementation are shown in Figure X below.
An XPath Routing Map object can also use Namespace Mappings to associate namespace prefixes
in the XPath expression maps to namespace URIs. This shortens the length of the XPath
expressions while preserving namespace information. This example does not use namespace
mapping.
1 - 42 Release 3.6
51. Scenario B: An HTML Forms Service
Here is the configuration display of this object.
Figure 1 - 36. XPath Routing Map Configuration
Note that the destinations are mapped according to the value of the Requested_Service node. These
are mapped to endpoint operations at the destination server ports. If no match is found by this
Route action using the above mappings, the object returns an error to the client. The next object
never executes.
Release 3.6 1 - 43
52. Human Resources Web Portal
Action 7: Transform
This transform connects the last context containing the message to the next action, or to the
OUTPUT context. This is necessary because the Route action does not return a nodeset when
doing its work. This is the final action of the rule; if this action executes at all, then the Route has
succeeded and all is clear for delivery to the back end service. Here is the configuration display
for this object.
Figure 1 - 37. Transform Configuration
Input: tmpvar4
This is set to tmpvar4, the named output context used by the action preceeding
the Route action.
Processing Control File: store:///identity.xsl
This is set to store:///identity.xsl. This stylesheet is supplied with the firmware.
Output: OUTPUT
This is set to OUTPUT, the special context that is delivered to the wire. As this
is the last action of the rule, whatever is in this context is sent to the
destination determined by the Route action. The message goes off to the
appropriate back end Web services endpoint.
When a submitted message succeeds in transversing the firewall processing policy, the message
appears exactly as it did after the last transform completed. This message is identical in form to
those submitted by the Web Services implementation of this service.
1 - 44 Release 3.6
53. Scenario B: An HTML Forms Service
Rule #2: Response Rule
Rule #2 in this policy is a Response rule. It handles messages returned to the service from the back
end servers. Note that the Match rule is the same as the Request; the server must reflect the same
URI in its response as the client.
Implied Action 0: Validate
The firewall automatically validates the response message against the SOAP schemas, to insure
that no message that does not conform to the SOAP schemas will be sent back to the client. This
SOAP schema filtering is implied and no action needs to be created for it. However, the presence
of this valildation action can cause response messages to be rejected by the firewall before any of
the actions visible in the Firewall Policy have run.
Action 1: Transform
This action is present to transform the response from the server prior to delivering it to the
requesting client. Because the requesting client is a browser, this rule must transform the SOAP
response from the back end server into HTML. Note that because the service Response Type is set
to SOAP that the service itself validates the server’s response against the SOAP schemas.
Here is the configuration display for this action:
Figure 1 - 38. Response Transform Configuration
Input: INPUT
This is set to INPUT, the special input context containing the original message
from the back end server.
Processing Control File: local:///xycoformresponse.xsl
This is set to local:///xycoformresponse.xsl. This custom stylesheet has been
uploaded to the device.
Release 3.6 1 - 45
54. Human Resources Web Portal
Output: OUTPUT
This is set to OUTPUT, the special context that is delivered to the wire. As this
is the last action of the rule, whatever is in this context is sent back to the
client as the response from the service.
Here is the XSLT stylesheet used for this action:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/
extensions" xmlns:dpconfig="http://www.datapower.com/param/config" extension-element-prefixes="dp" exclude-result-
prefixes="dp dpconfig">
<xsl:output method="html" version="1.0"/>
<xsl:template match="/">
<html>
<head>
<title>As Requested</title>
</head>
<body>
<h2>XyCo HR Instant Benefits</h2>
<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']"/>
<!-- <xsl:value-of select="date:date-time()"/> -->
<p>
<font size="2">Transaction ID:<xsl:value-of select="dp:variable('var://service/transaction-id')"/>
</font>
</p>
</body>
</html>
</xsl:template>
<xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']">
<table cellspacing="3">
<xsl:for-each select="./*">
<xsl:choose>
<xsl:when test="local-name() != 'result'">
<tr>
<td align="right">
<b>
<xsl:value-of select="local-name()"/>:
</b>
</td>
<td align="left">
<xsl:value-of select="."/>
</td>
</tr>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-
name()='response']/*[local-name()='result']"/>
</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
</table>
</xsl:template>
<xsl:template match="/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='response']/*[local-
name()='result']">
<xsl:for-each select="./*">
<tr>
<td align="right" valign="top">
<b><xsl:value-of select="local-name()"/>:</b>
</td>
1 - 46 Release 3.6
55. Scenario B: An HTML Forms Service
<td align="left">
<xsl:value-of select="."/>
</td>
</tr>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
Here is an example of the completed round-trip response to the original request:
Figure 1 - 39. Response in Browser
Release 3.6 1 - 47
56. Human Resources Web Portal
Rule #3: Error Rule
Rule #3 in this policy is an Error rule. It handles any errors encountered during the processing of
either the request or the response rule. Note that a Matching Rule is also used for an Error rule. It
is possible to match on particular error codes. In this case, however, the Match is the same for all
other rules. The URL must match the expression */services.
Action 1: Transform
This action is present to transform the error message generated by the DataPower processing
system into an HTML file that includes a traceable transaction number. Because the client is a
browser, this transform is required.
Here is the configuration display for this action:
Figure 1 - 40. Error Transform Configuration
Input: NULL
This is set to NULL, a special input context containing nothing. This error
response will not include any device-generated message fragment.
Processing Control File: local:///xycoformerror.xsl
This is set to local:///xycoformerror.xsl. This custom stylesheet has been
uploaded to the device.
Output: OUTPUT
This is set to OUTPUT, the special context that is delivered to the wire. As this
is the last action of the rule, whatever is in this context is sent back to the
client as the response from the service.
Here is the XSLT used for this action:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:dpconfig="http://www.datapower.com/param/config"
extension-element-prefixes="dp"
1 - 48 Release 3.6
