14 Working with Pipeline Actions in Oracle Service Bus Console
This chapter describes how to add different types of actions to pipelines, using the Oracle Service Bus Console, such as route, publish, service callout, transport headers, conditional actions, error actions, and message transformation actions.
Actions are the elements of pipeline stages, error handler stages, route nodes, and branch nodes that determine how messages are to be defined as they flow through a pipeline.
This chapter includes the following sections:
14.1 Adding and Editing Pipeline Actions in the Console
Actions are the elements of pipeline stages, error handler stages, route nodes, and branch nodes that determine how messages are to be defined as they flow through a proxy service.
These instructions assume that you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
They also assume that you have already added a pipeline stage, a route node, and/or an error handler stage. See:
To add an action to a pipeline:
- Depending on whether actions have already been added to the stage or to the route node, do one of the following:
-
If no actions have yet been added, the Edit Stage Configuration page displays only the Add an Action icon. Click that icon, then select an action type.
-
If one or more actions have already been added, the Edit Stage Configuration page displays one or more icons representing those actions, for example, a Publish icon or a Routing icon. Click the appropriate icon, click Add an Action, then select an action type.
-
Some actions, such as request and response actions in publish actions, include an Add an Action link where an action is appropriate. Click that icon, then select an action type.
There are no restrictions on what actions can be chained together in a pipeline.
Table 14-1 through Table 14-4 list the actions you can configure for pipelines.
Table 14-1 Pipeline - Communication Actions
Action Description More Information 
Dynamic Publish
Publish a message to a service identified by an XQuery expression
Publish
Publish a message to a statically specified service.
Publish Table
Publish a message to zero or more statically specified services. Switch-style condition logic is used to determine at runtime which services will be used for the publish.
Routing Options
Modify any or all of the following properties in the outbound request: URI, Quality of Service, Mode, Retry parameters, Message Priority.
Service Callout
Configure a synchronous (blocking) callout to a Service Bus-registered proxy or business service.
Transport Headers
Set the transport header values in messages
Dynamic Routing
Assign a route for a message based on routing information available in an XQuery resource.
Routing
Identify a target service for the message and configure how the message is routed to that service:
Routing Table
Assign a set of routes wrapped in a switch-style condition table.Different routes are selected based on the results of a single XQuery expression.
Table 14-2 Pipeline - Flow Control Actions
Action Description More Information 
For each
Iterate over a sequence of values and execute a block of actions
If...then...
Perform an action or set of actions conditionally, based on the Boolean result of an XQuery expression.
Raise error
Raise an exception with a specified error code (a string) and description.
Reply
Specify that an immediate reply is sent to the invoker.
Resume
Resume pipeline after an error handler has handled an error.
Skip
Specify that at runtime, the execution of the current stage is skipped and the processing proceeds to the next stage in the pipeline.
Table 14-3 Pipeline - Message Processing Actions
Action Description More Information 
Assign
Assign the result of an XQuery expression to a context variable.
Delete
Delete a context variable or a set of nodes specified by an XPath expression.
Insert
Insert the result of an XQuery expression at an identified place relative to nodes selected by an XPath expression.
Java callout
Invoke a Java method from the pipeline.
JavaScript
Manipulate an XML or JSON payload using a JavaScript expression.
MFL transform
Convert non-XML to XML or XML to non-XML in the pipeline.
nXSD translate
Convert native data format (nXSD) to XML or XML to native data format (nXSD) in the pipeline.
Rename
Rename elements selected by an XPath expression without modifying the contents of the element.
Replace
Replace a node or the contents of a node specified by an XPath expression.
Validate
Validate elements selected by an XPath expression against an XML schema element or a WSDL resource.
Table 14-4 Pipeline - Reporting Actions
Action Description More Information 
Alert
Send an alert notification based on pipeline message context.
Log
Construct a message to be logged.
Report
Enable message reporting for a proxy service.
-
14.2 Adding Publish Actions in the Console
Use a publish action to identify a statically specified target service for a message and to configure how the message is packaged and sent to that service.
For more information on publish behavior, see Performing Transformations in Pipelines.
To add a publish action:
- Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
- Select Add an Action > Communication > Publish.
- Click Service. The Select Service page is displayed.
- Select a service from the list, then click Submit. This service is the target service for the message.
- If the service has operations defined, you can specify an operation to be invoked by selecting it from the Operation list.
- To make the outbound operation the same as the inbound operation, select the Use inbound operation for outbound check box.
- To configure how the message is packaged and sent to the service, in the Request Actions field, click Add an Action. Select an action to associate with the service. You can add more than one action. See Adding and Editing Pipeline Actions in the Console.
- Click Save to commit the updates in the current session.
14.3 Adding Publish Table Actions in the Console
Use a publish table action to publish a message to zero or more statically specified services.
Switch-style condition logic is used to determine at runtime which services are used for the publish.
For more information on publish behavior, see Performing Transformations in Pipelines.
To add a publish table action:
- Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
- Select Add an Action > Communication > Publish Table.
- Click Expression. The XQuery Expression Editor page is displayed. Create an XQuery expression, which at runtime returns the value upon which the routing decision is made. See Creating and Editing Inline XQuery and XPath Expressions.
- From the Operator list, select a comparison operator. Then, in the adjacent field, enter a value against which the value returned from the XQuery expression is evaluated.
- Click Service to select a service to which messages are to be published if the expression evaluates true for the value you specified. The Select Service page appears.
- Select a service from the list, then click Submit. This service is the target service for the message.
- If the service has operations defined, you can specify the operation to be invoked by selecting it from the invoking list.
- If you want the outbound operation to be the same as the inbound operation, select the Use inbound operation for outbound check box.
- In the Request Actions field, to configure how the message is packaged and sent to the service, click Add an Action. Then select one or more actions that you want to associate with the service. To learn more about the type of action you want to add, see Adding and Editing Pipeline Actions in the Console.
- To insert a new case, click the Case icon, then select Insert New Case.
- Repeat steps 4–8 for the new case.
- Add more cases as dictated by your business logic.
- Click the Case icon of the last case you define in the sequence, then select Insert Default Case to add a default case at the end.
- Configure the default case—the configuration of this case specifies the routing behavior when none of the preceding cases are satisfied.
- Click Save to commit the updates in the current session.
14.4 Adding Dynamic Publish Actions in the Console
Use a dynamic publish action to publish a message to a service specified by an XQuery expression.
For more information on publish behavior, see Performing Transformations in Pipelines.
To add a dynamic publish action:
14.5 Adding Routing Options Actions in the Console
Use the routing options action to modify any or all of the following properties for the outbound request in $outbound: URI, Quality of Service, Mode, Retry parameters.
Although these properties can be modified using assign, insert, replace, or delete actions on $outbound, using routing options provides a simpler way to perform this task, without requiring knowledge of XPath, XQuery, or the structure of the $outbound context variable.
The routing options action can only be used where the context variable $outbound is valid. It can be added to the following actions:
-
Publish
-
Dynamic Publish
-
Publish Table
-
Service Callout
-
Routing
-
Dynamic Routing
-
Routing Table
For more information on routing, see Modeling Message Flow in Oracle Service Bus.
To configure a routing options action:
14.6 Adding Service Callout Actions in the Console
Use a service callout action to configure a synchronous (blocking) callout to a Service Bus-registered proxy or business service.
For more information on service callout actions, see Constructing Service Callout Messages.
To add a service callout action:
14.7 Adding Transport Header Actions in the Console
Use a transport header action to set the header values in messages.
To add a transport header action:
-
Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
-
Click the appropriate icon, then select Add an Action > Communication > Transport Headers.
-
From the Set Transport Headers for list, select one of the following, to specify to the runtime which of the message context locations are to be modified:
-
Outbound Request - Select this option to set header values for outbound requests (the messages sent out by a proxy service in route, publish, or service callout actions). This header element is located in the message context as follows:
$outbound/ctx:transport/ctx:request/tp:headers
-
Inbound Response - Select this option to set header values for inbound responses (the response messages a proxy service sends back to clients). This header element is located in the message context as follows:
$inbound/ctx:transport/ctx:response/tp:headers
-
-
Optionally, select Pass all Headers through Pipeline to pass all headers through from the inbound message to the outbound message or vice versa. Every header in the source set of headers will be copied to the target header set, overwriting any existing values in the target header set.
For information about using this option in conjunction with the header-specific pass through option, see Configuring Transport Headers in Pipelines.
-
Complete the following steps for each Header you want to add:
-
In the Transport Headers table, click Add Header to display fields for configuring the header.
-
Specify a header by doing either of the following:
-
From the list in the Name column, select a header name. The list contains all of the predefined header names for the target transport (for example, Content-Type for HTTP transports, JMSCorrelationID for JMS transports, and so on).
-
Enter a header name in the Other field. If that header name is not one of the predefined headers for this service's transport, it becomes a user-header, as defined by the transport specification.
-
-
Select one of the options in the Action column to specify how to set the headers value:
Set Header to Expression
Selecting this option allows you to use an XQuery or XSLT expression to set the value of the header. The expression can be simple (for example, "text/xml") or a complex XQuery or XSLT expression.
Because the Service Bus transport layer defines the XML representation of all headers as string values, the result of any expression is converted to a string before the header value is set. Expressions that return nothing result in the header value being set to the empty string. You cannot delete a header using an expression.
Caution:
Not all of the header settings you can specify in this action are honored at runtime.For information about which of the headers for a given transport you can set and which of those set are honored at runtime, see Configuring Transport Headers in Pipelines.
Delete Header
Specifies that the header is removed from the request or response metadata.
Copy Header from Inbound Request (if you are setting transport headers for the Outbound Request)
or
Copy Header from Outbound Response (if you are setting transport headers for the Inbound Response)
Specifies that this header is copied directly from the corresponding header of the same name from the inbound message to the outbound message and vice versa. For example, if you want to set the SOAPAction header for an outbound request, selecting Copy Header from Inbound Request causes the runtime to copy the value from the SOAPAction request header of
$inbound. In the case of inbound response headers, the source of the header to copy is the response headers of$outbound.If the Copy Header option is selected for a header that does not exist in the source, this option is ignored and no action is performed on the target for this header.
For information about using this option in conjunction with the global Pass all Headers through Pipeline option, see Configuring Transport Headers in Pipelines.
-
-
To add additional Headers to the table, click the Header icon, then click Add Header.
The table is expanded to include an additional row, which includes a new set of options that you can use to configure another transport header. You can add as many headers as necessary to this table. You do not have to order the headers in the table, because the runtime declares namespaces and places header elements in their proper order when generating the corresponding XML.
-
Click Save to commit the updates in the current session.
14.7.1 Setting Cookies in Outbound HTTP Transport Headers
In an HTTP pipeline you can set cookies on the transport header in the following ways:
14.7.1.1 Setting a Cookie as a Complex XML Expression
To set a cookie using a complex XML expression, which is the Service Bus default format, configure the value of the HTTP Cookie header in the outbound request using the following expression syntax:
<cookie-values xmlns="http://www.bea.com/wli/sb/transports/http">
<value>{fn:concat("cookie_name", "=", "cookie_value")}</value>
</cookie-values>14.7.1.2 Setting a Cookie with a String Expression
To set the Cookie header with a string in the outbound request, you must add the following option to your domain startWebLogic command:
-Dcom.bea.osb.http.cookieAsNoComplexElement=true
After you restart the server with this option, you can set an HTTP Cookie header with a string expression. For example:
$cookie_name = "cookie_value"
14.8 Adding Dynamic Routing to Route Nodes in the Console
Assign a route for a message based on routing information available in an XQuery resource.
This is a terminal action, which means you cannot add another action after this one. However, this action can contain request and response actions. For more information on dynamic routing, see Using Dynamic Routing.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add dynamic routing to a route node:
14.9 Adding Routing Actions to Route Nodes in the Console
Identify a target service for the message and configure how the message is routed to that service.
This is a terminal action, which means you cannot add another action after this one. However, this action can contain request and response actions. For more information on routing, see Modeling Message Flow in Oracle Service Bus.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a routing action to a route node:
- Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
- Click the Route Node icon, then click Edit Route. The Edit Stage Configuration page is displayed.
- Click the Add an Action icon, then select Communication > Routing.
- Click Service. The Service Browser is displayed.
- Select a service from the list, then click Submit. The service is displayed instead of the default link.
- If you want the outbound operation to be the same as the inbound operation, select the Use inbound operation for outbound check box.
- In the Request Actions field, click Add an Action to add an action, then select an action that you want to associate with the service. You can add more than one action. To learn more about the type of actions you can add, see the table of actions in Adding and Editing Pipeline Actions in the Console.
- In the Response Actions field, click Add an Action to add an action, then select an action that you want to associate with the service. You can add more than one action. To learn more about the type of actions you can add, see the table of actions in Adding and Editing Pipeline Actions in the Console.
- Click Save.
- On the Edit Message Flow page, continue to construct the pipeline, as described in Viewing and Editing Pipelines in the Console.
- Click Save to commit the updates in the current session.
- To end the session and deploy the configuration to the runtime, click Activate under Change Center.
14.10 Adding Routing Tables to Route Nodes in the Console
A routing table is a set of routes wrapped in a switch-style condition table. It is a short-hand construct that allows different routes to be selected based upon the results of a single XQuery expression.
You can nest multiple levels in the stage editor. Identify target services for messages and configure how the messages are routed to these services.
This is a terminal action, which means you cannot add another action after this one. However, this action can contain request and response actions. For more information on routing, see Modeling Message Flow in Oracle Service Bus.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a routing table to a route node:
14.11 Adding For-Each Actions in the Console
Use the for-each action to iterate over a sequence of values and execute a block of actions.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a for-each action:
- Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
- Click the appropriate icon, then select Add an Action > Flow Control > For Each.
- Enter variable names in the variable fields, click XPath to open the XPath editor to create an XPath expression, and configure the actions in the Do () loop.
- Click Save to commit the updates in the current session.
14.12 Adding If-Then Actions in the Console
Use an if-then action to perform an action or set of actions conditionally, based on the Boolean result of an XQuery expression.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add an if-then action:
14.13 Adding Raise Error Actions in the Console
Use the raise error action to raise an exception with a specified error code (a string) and description.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a raise error action:
- Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
- Click the appropriate icon, then select Add an Action > Flow Control > Raise Error.
- In the error code field, enter the error code you want to raise.
- In the error message field, enter a description of the error code.
- Click Save to commit the updates in the current session.
14.13.1 Transactions
If a service is transactional, a triggered Raise Error action aborts the transaction in the request (asynchronous) or in either the request or response (synchronous). For example, you may introspect messages and determine conditions under which a Raise Error action should occur even if no SOAP fault occurs, and Raise Error causes the transaction to be aborted.
14.14 Adding Reply Actions in the Console
Use the reply action to specify that an immediate reply be sent to the invoker. The reply action can be used in the request, response or error pipeline.
You can configure it to result in a reply with success or failure. In the case of reply with failure where the inbound transport is HTTP, the reply action specifies that an immediate reply is sent to the invoker.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a reply action:
14.15 Adding Resume Actions in the Console
Use the resume action to resume message flow after an error is handled by an error handler. This action has no parameters and can only be used in error pipelines.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a resume action:
- Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
- Click the appropriate icon, then select Add an Action > Flow Control > Resume.
When you complete the configuration of this action, continue by configuring other actions or by saving your configuration, as described in Adding and Editing Pipeline Actions in the Console.
14.16 Adding Skip Actions in the Console
Use the skip action to specify that at runtime, the execution of actions of this stage is skipped and the processing proceeds to the next stage in the pipeline.
Note:
If the action has a service callout or dynamic route in it, any skip action used in the service callout's or dynamic route's respective request or response actions skips only its remaining actions. The skip step does not have any impact on the caller stage's processing.This action has no parameters and can be used in the request, response, or error pipelines.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a skip action:
- Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
- Click the appropriate icon, then select Add an Action > Flow Control > Skip.
14.17 Adding Assign Actions in the Console
Use the assign action to assign the result of an XQuery expression to a context variable.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add an assign action:
- Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
- Click the appropriate icon, then select Add an Action > Message Processing > Assign.
- Click Expression. The XQuery Expression Editor page is displayed. The XQuery expression is used to create the data that will be assigned to the named variable. See Creating and Editing Inline XQuery and XPath Expressions.
- When you finish editing the expression, enter a context variable in the variable field. To learn more about context variables, see Inbound and Outbound Variables and Constructing Messages to Dispatch.
- Click Save to commit the updates in the current session.
14.18 Adding Delete Actions in the Console
Use the delete action to delete a context variable or a set of nodes specified by an XPath expression. The delete action is one of a set of update actions.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a delete action:
14.19 Adding Insert Actions
Use the insert action to insert the result of an XQuery expression at an identified place relative to nodes selected by an XPath expression. The insert action is one of a set of update actions.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add an insert action:
14.20 Adding Java Callout Actions in the Console
Use the Java callout action to invoke a Java method, or EJB business service, from within the pipeline.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a Java callout action:
14.21 Adding JavaScript Actions in the Console
Use a JavaScript action to manipulate the contents of an XML or JSON payload using JavaScript expressions.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
- Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
- Click the appropriate icon, then select Add an Action > Message Processing > JavaScript.
- Provide the JavaScript expression in one of the following ways:
- To
- To use a JavaScript expression from a JavaScript resource that has already been uploaded to the Service Bus Console, select the With Resource option, and then click Resource. Use the Select JavaScript dialog to search for and select a JavaScript resource.
- Select one of the following Timeout options:
- System Default: JavaScript processing times out when the system default JavaScript timeout is reached.
- Seconds field: provide a timeout value (in seconds) at which JavaScript processing times out.
- None: JavaScript processing does not time out.
- Click Validate to validate the JavaScript expression.
- Click Save.
14.22 Adding MFL Translate Actions in the Console
Use the MFL (Message Format Language) translate action to convert message content from XML to non-XML, or the reverse, in the message pipeline.
An MFL is a specialized XML document used to describe the layout of binary data. It is an Oracle proprietary language used to define rules to translate formatted binary data into XML data, or the reverse. See Defining Data Structures with Message Format Language.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add an MFL translate action:
14.23 Adding nXSD Translate Actions
Use the nXSD translate action to convert message content from XML to native format data, or the reverse, in the message pipeline.
See "Native Format Builder Wizard" in Understanding Technology Adapters for information on creating native schemas used for translation.
The nXSD Translate Action supports XML to JSON and JSON to XML translations if the associated XSD resource contains the relevant annotations, as shown in the following example:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://example.com/RestService_Operation1_request"
targetNamespace="http://example.com/RestService_Operation1_request" elementFormDefault="qualified"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:version="JSON" nxsd:encoding="US-ASCII">
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="country" type="xsd:string"/>
<xsd:element name="circuit" type="xsd:string"/>
<xsd:element name="date" type="xsd:date"/>
…The nXSD Translate action is enhanced in this version of Service Bus to enforce schema ordering when converting from JSON to XML.
Dynamic nXSD Reference
For dynamic NXSD schema configuration, at design time you specify the Xquery expression for computing the nxsd and scheme element QName details. At runtime, the Xquery expression results in an xml document containing the NXSD schema reference name and the schema element name.
The syntax for identifying the NXSD schema reference and XML element name is as follows:
<xs:schema targetNamespace="http://www.bea.com/wli/sb/context"
xmlns:tns="http://www.bea.com/wli/sb/context"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- ============================ -->
<xs:element name="nxsdTranslation" type="tns:NXSDTranslationType"/>
<xs:complexType name="TranslationQNameType">
<xs:sequence>
<xs:element name="namespaceURI" type="xs:anyURI" minOccurs="0"/>
<xs:element name="localname" type="xs:NCName"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NXSDTranslationType">
<xs:sequence>
<!-- Name is '/' separated string that starts with project name and ends with resource name -->
<xs:element name="schema" type="xs:string"/>
<xs:element name="schemaElement" type="tns:TranslationQNameType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>Below is an example of a full XML snippet:
<nxsdtranslation xmlns="http://www.bea.com/wli/sb/context">
<schema>default/MySchema</schema>
<schemaElement>
<namespaceURI>http://openuri.org</namespaceURI>
<localname>MyType</localname>
</ schemaElement>
</nxsdtranslation>The sample xquery below can generate an XML snippet in that format:
declare variable $children:= ("default/MySchema","http://openuri.org","MyType");
declare function local:message ($number as xs:integer) as item() {
$children[$number]
};
<nxsdtranslation xlmns="http://www.bea.com/wli/sb/context">
<schema>{ local:message(1) }</schema>
<schemaElement>
<namespaceURI>{ local:message(2) }</namespaceURI>
<localname>{ local:message(3) }</localname>
</schemaElement>
</nxsdtranslation>These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add an nXSD translate action:
14.24 Adding Rename Actions in the Console
Use the rename action to rename elements selected by an XPath expression without modifying the contents of the element. The rename action is one of a set of update actions.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a rename action:
14.25 Adding Replace Actions in the Console
Use a replace action to replace a node or the contents of a node specified by an XPath expression.
The node or its contents are replaced with the value returned by an XQuery expression. A replace action can be used to replace simple values, elements and even attributes. An XQuery expression that returns nothing is equivalent to deleting the identified nodes or making them empty, depending upon whether the action is replacing entire nodes or just node contents. The replace action is one of a set of update actions.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a replace action:
14.26 Adding Validate Actions in the Console
Use a validate action to validate elements selected by an XPath expression against an XML schema element or a WSDL resource.
You can validate global elements only; Service Bus does not support validation against local elements. You can also choose to dynamically select the XML schema element or WSDL resource, at runtime, based on the result of an XQuery expression.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a validate action:
-
Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
-
Click the appropriate icon, then select Add an Action > Message Processing > Validate.
-
Click XPath. to construct an XPath expression that specifies the elements to be validated. See Creating and Editing Inline XQuery and XPath Expressions. When you are finished constructing the expression in the XPath Expression Editor, click Save to insert the expression on the Edit Stage Configuration page.
-
In the in variable field, enter the name of the variable to hold the element to be validated.
-
Select one of the following options:
-
Against Resource: click the resource link, then select WSDL or Schema. From the WSDL Browser or XML Schema Browser, do the following:
-
Select the WSDL file or XML schema
-
Select the WSDL file or XML schema type or element
-
Click Submit.
-
-
Against Resource from Expression: click the Expression link. The XQuery Expression Editor page is displayed. Using the XQuery Expression Editor, create or edit an XQuery expression to dynamically specify a WSDL file or schema resource. See Creating and Editing Inline XQuery and XPath Expressions.
The following is an example of dynamically specifying a WSDL resource:
<validate xmlns="http://www.bea.com/wli/sb/context"> <wsdl>default/MyWSDL</wsdl> <schemaType> <namespaceURI>http://openuri.org</namespaceURI> <localname>MyType</localname> </schemaType> </validate>The following is an example of dynamically specifying a schema resource:
<validate xmlns="http://www.bea.com/wli/sb/context"> <schema>{dvm:lookup('SBProject/dvm/DVM_Validation', 'operation', $operationName, 'validationSchema','default')}</schema> <schemaElement> .........<namespaceURI>"http://www.example.com/date</namespace> <localname>{dvm:lookup('SBProject/dvm/DVM_Validation', 'operation', $operationName, 'validationElement','default')}</localname> </schemaElement> </validate>Note that the schema or WSDL selected has to be a resource and so must have been imported into OSB as a Schema/WSDL resource. You cannot point directly to a file or URL. The XML fragment that is required is created via an xquery expression, letting you enter any kind of xquery expression to create that XML. In the examples above, the XML provided is a constant XML, illustrating what kind of XML is expected.
For example, the name of the WSDL could be coming in a variable and you extract that name to find the resource name. Another example is to have one xquery module resource with a function that can do a lookup of the XML fragment given one or multiple keys. In this case, in the validate expression you can evaluate the keys required and make a call to that xquery module function. This allows you to externalize and manage all those dynamic entries in that one xquery module along with the lookup algorithm.
-
-
To save the result of this validation (a boolean result), select Save result of validation in variable and enter the name of the variable in which you want to save the result.
Alternatively, to raise an error if the element fails validation against the WSDL file or XML schema element, select Raise Error on validation failure.
-
Click Save to commit the updates in the current session.
14.27 Adding Alert Actions in the Console
Use the alert action to generate alerts based on message context in a pipeline, to send to an alert destination.
Unlike SLA alerts, notifications generated by the alert action are primarily intended for business purposes, or to report errors, and not for monitoring system health. Alert destinations should be configured and chosen with this in mind. To learn more about alert destinations, see Working with Alert Destinations.
If pipeline alerting is not enabled for the service or at the domain level, the configured alert action is bypassed during message processing.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add an alert action:
14.28 Adding Log Actions in the Console
Use the log action to construct a message to be logged and to define a set of attributes with which the message is logged.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
Note:
To see log data in the log file or standard out (server console), WebLogic Server logging must be set to the following severity levels:
-
Minimum severity to log: Info
-
Log file: Info
-
Standard out: Info
For information on setting log severity levels, see "Using Log Severity Levels" in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
To add a log action:
14.29 Adding Report Actions in the Console
Use the report action to enable message reporting for a proxy service.
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To add a report action:
-
Navigate to where you want to add the action, as described in Adding and Editing Pipeline Actions in the Console.
-
Click the appropriate icon, then select Add an Action > Reporting > Report.
-
Click Expression. The XQuery Expression Editor page is displayed. See Creating and Editing Inline XQuery and XPath Expressions. The XQuery expression is used to create the data that will be reported to the Service Bus dashboard.
-
When you finish editing the XQuery expression, click Add a Key. Two fields are displayed: a Key Name field and a Key Value field, which includes an XPath link that you can click to edit an XPath expression and an in variable field in which you can enter a context variable.
You use key value pairs to extract key identifiers from any message context variable or message payload, and ignore the rest of the message. The keys are a convenient way to identify a message. They are displayed as report indexes in the Reporting module. See "Working with Message Reports" in Administering Oracle Service Bus
-
Enter a key name in the Key Name field.
-
Click XPath. The Edit an XPath Expression page is displayed. See Creating and Editing Inline XQuery and XPath Expressions.
-
Enter a context variable in the in variable field.
-
To add more key values, click the Key icon, then select Add a Key. To delete a key, click the Key icon, then select Delete this Key.
-
For example, consider a report action configured on an error handler in a stage. The action reports the contents of the fault context variable in the event of an error. The report action is configured as follows:
-
Key name =
errorCode -
Key value =
./ctx:errorCodein variablefault
Each time this action is executed at runtime, a message is reported through the Reporting Data Stream. The following table shows the results after the report action is executed twice.
| Report Index | DB TimeStamp | Inbound Service | Error Code |
|---|---|---|---|
|
errorCode=OSB-382505 |
04/26/07 9:45 AM |
MortgageBroker/ProxySvcs/loanGateway3 |
OSB-382505 |
|
errorCode=OSB-382505 |
04/26/07 9:45 AM |
OSB-382505 |
14.30 Adding Error Handlers in the Console
You can configure error handling at the message flow, pipeline, route node, and stage level.
Configure error handlers on the Edit Error Handler page. You must always add at least one stage to the page to specify how the error handler will work.
Note:
You cannot create an error handler within an error handler.
14.30.1 Adding Pipeline Error Handlers in the Console
Before you begin
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
The instructions also assume you have created a pipeline pair node, as explained in How to Add Pipeline Pairs to Pipelines.
To add a pipeline error handler:
14.30.2 Adding Stage Error Handlers in the Console
Before you begin
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console. The instructions also assume you have added a stage to a pipeline, as explained in How to Add Stages to Pipelines in the Console.
To add a stage error handler:
14.30.3 Adding Route Node Error Handlers in the Console
Before you begin
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
The instructions also assume you have created a route node, as explained in How to Add Route Nodes to Pipelines in the Console.
To add a route note error handler:
14.30.4 Editing Error Handlers in the Console
Before you begin
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To view and change an error handler:
Do one of the following:
Table 14-8 Viewing and Changing the Error Handler
| To... | Complete This Step... |
|---|---|
|
View and change the pipeline error handler |
Click the appropriate Request Pipeline icon or the Response Pipeline icon, then click Edit Pipeline Error Handler. The Edit Error Handler page is displayed. See Adding Pipeline Error Handlers in the Console. |
|
View and change the route node error handler |
Click the appropriate Route Node icon, then click Edit Route Error Handler. The Edit Error Handler page is displayed. See Adding Route Node Error Handlers in the Console. |
|
View and change the stage error handler |
Click the appropriate Stage icon, then click Edit Stage Error Handler. The Edit Error Handler page is displayed. See Adding Stage Error Handlers in the Console. |
14.31 Disabling an Action or a Stage in the Console
You can choose to disable an action or a stage in a pipeline. A disabled action or stage is skipped from the pipeline execution.
When you disable an action or a stage, all the nested actions, if any, are disabled automatically. A disabled stage or action is not validated at design time.
Note:
If a disabled stage has an error handler, then the error handler is also disabled.
You can still edit the configuration of a disabled action or stage. Refactoring also takes place for disabled actions and stages. This means that if there is a call to a service in the disabled action or stage, and the service gets renamed, then the service callout is automatically updated.
You can re-enable a disabled stage or action at any time, and the action or stage is no longer skipped in the pipeline.
14.31.1 Disabling an Action on the Pipeline
Before you begin:
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To disable an action in the pipeline:
14.31.2 Re-Enabling an Action in the Pipeline
Before you begin:
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To re-enable an action in the pipeline:
14.31.3 Disabling a Stage in the Pipeline
Before you begin:
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To disable a stage in the pipeline:
14.31.4 Re-Enabling a Stage in the Pipeline
Before you begin:
These instructions assume you are already editing a pipeline in the Edit Message Flow page, as explained in Viewing and Editing Pipelines in the Console.
To re-enable a stage in the pipeline: