Multiple Assertions Throwing Faults with Assertion Conditions

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 11-50 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite ■ In standalone assert activities To create assertion conditions in invoke activities, receive activities, reply activities, and OnMessage branches: 1. In the SOA Composite Editor, double-click the version 1.1 BPEL process service component.

2. In the Component Palette, expand BPEL Constructs.

3. Drag a Receive activity, Invoke activity, Pick activity, or Scope activity into the

designer.

4. Expand the Receive, Invoke, or onMessage branch of the Pick or Scope activity.

5. Click the Assertions tab.

6. Click the Add icon.

7. Select when to execute the condition. ■ Pre Assert : If selected, the condition is executed before the invoke or reply activity send out the outbound message. ■ Post Assert : If selected, the condition is executed after an invoke activity, receive activity, or onMessage branch receives the inbound message. Based on your selection, the Pre Assert or Post Assert dialog is displayed. 8. Specify values for the assertion condition, as shown in Figure 11–20 . For this example, Post Assert was selected for an assertion condition on a receive activity.

a. Select the Fault QName to be thrown by clicking the Search icon and selecting

an existing fault from the Fault Chooser dialog. You can also provide your own values for the Namespace URI and Local Part fields of the fault. If you do not specify anything for the Fault QName, then a bpelx:assertFailure fault is thrown. Figure 11–20 Assertion Condition Values

9. When complete, click OK to return to the Assertions tab of the activity. The

completed assertion condition is displayed, as shown in Figure 11–21 . Using Fault Handling in a BPEL Process 11-51 Figure 11–21 Assertions Tab with Data

10. Click Apply, then OK.

To create an assertion condition in standalone assert activities: 1. In the SOA Composite Editor, double-click the version 1.1 BPEL process service component.

2. In the Component Palette, expand BPEL Constructs.

3. Drag an Assert activity into the designer.

4. Expand the Assert activity.

5. To the right of the Expression field, click the XPath Expression Builder icon.

6. Create an expression.

7. When complete, click OK.

The Assert dialog looks as shown in Figure 11–22 .