bpelx:postAssert and bpelx:preAssert Extensions

11-48 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite In Example 11–38 , the assertion with the expression that checks that the response credit rating is greater than zero is evaluated first. Table 11–4 describes the assertion behavior. Any number of assertions can be nested. For no fault to be thrown from the activity, all assertions specified must evaluate to true. This construct enables you to apply multiple levels of validation on an incoming payload, similar to if...else if...else statements in Java. To enable a fault to always be thrown regardless of validation logic, the assertion expression can be specified as false. This is similar to the else construct in Java. 11.14.4 Use of Built-in and Custom XPath Functions and variable References You can also use built-in and custom XPath functions and variable references within the assertion condition. Example 11–39 provides several examples. Example 11–39 Built-in and Custom XPath Functions bpelx:postAssert expression=bpws:getVariableData crOutput, payload, tns:rating 0 ... bpelx:postAssert expression=custom:validateRating ... bpelx:postAssert xmlns:fn=http:www.w3.org2005xpath-functions expression=fn:false ... If an error is thrown by the XPath expression evaluation, the error is wrapped with a BPEL fault and thrown from the activity. Faults that are thrown from a request-response invoke activity, receive activity, or onMessage branch of a pick or scope activity because of a failed assertion evaluation can be caught and handled by BPELs fault policy framework. The fault policy framework enables you to specify the action to take whenever a fault business or system is thrown from an invoke activity. For example: ■ Retry of the invocation with exponential backoff ■ Execution of custom Java classes ■ Replay of the immediate scope containing the invoke activity ■ Review of the activity by an administrator and the permitting of manual editing of variables Faults that are not caught and handled within a BPEL process flow are thrown from a BPEL component if the component WSDL declares the fault on the operation. If the Table 11–4 Assertion Behavior If The Credit Rating For The Returned Response Is... Then... Less than zero The services:NegativeCredit fault is thrown. Greater than or equal to zero The assertion is correct and the second assertion is evaluated. Less than 600 The services:InsufficientCredit fault is thrown. Greater than or equal to 600 The assertion is correct and no fault is thrown from the invoke activity. Using Fault Handling in a BPEL Process 11-49 fault is not declared on the operation, the fault is converted into a FabricInvocationException, which is a runtime fault. This fault can be caught by any caller components including BPEL components, but the fault type is no longer the one originally thrown however, the fault message string still retains traces of the original fault message. For more information about fault policies, see Section 11.4, Using the Fault Management Framework.

11.14.5 Assertion Condition Evaluation Logging of Events to the Instance Audit Trail

Each assertion condition that is evaluated causes an event to be logged to the instance audit trail. The event indicates whether the assertion passed or failed for failure, the fault name and message are printed. The event also includes the name attribute specified in the assertion element; if no name attribute is provided, the line number of the assertion element in the BPEL process flow is used. The assertion condition printed in the audit event helps identify the assertion and better enables debugging of the flow.

11.14.6 Expressions Not Evaluating to an XML Schema Boolean Type Throw a Fault

If the assertion condition XPath expression does not evaluate to an XML schema boolean type, a bpelx:postAssertFailure fault is thrown from the activity. An event in the instance audit trail is also logged indicating the error. Example 11–40 provides details. Example 11–40 Throwing a bpelx:assertFailure Fault bpelx:postAssert expression=bpws:getVariableData crOutput, payload, tns:rating 0 ... bpelx:postAssert expression=custom:validateRating ... bpelx:postAssert xmlns:fn=http:www.w3.org2005xpath-functions expression=fn:false ... Analysis of the assertion expression is performed by the BPEL compiler and errors are reported if an expression does not evaluate to an XML schema boolean type. For custom XPath functions, this type of analysis is not performed.

11.14.7 Assertion Conditions in a Standalone Assert Activity

You can also create assertion conditions in a standalone assert activity in BPEL 1.1. The assertion specifies an XPath expression that, when evaluated to false, causes a BPEL fault to be thrown from the activity. The bpelx:assert extension implements assertions in the standalone assert activity: bpelx:assert name=Assert1 expression=string message=string For information on using the standalone assert activity, see Section 11.14.8, How to Create Assertion Conditions.

11.14.8 How to Create Assertion Conditions

You can create assertion conditions in the following activities: ■ In invoke activities, receive activities, reply activities, and OnMessage branches