You can also use built-in and custom XPath functions and $variable references within the assertion condition. The following code provides several examples.

<bpelx:postAssert expression="bpws:getVariableData( 'crOutput', 'payload',
 '/tns:rating' ) > 0" ... />

<bpelx:postAssert expression="custom:validateRating()" ... />

<bpelx:postAssert xmlns:fn='http://www.w3.org/2005/xpath-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 BPEL's fault management framework. For information, see Handling Faults with the Fault Management Framework.

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 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 runtime faults, see Introduction to the Business and Runtime Fault Categories of BPEL Faults.

For more information about fault policies, see Handling Faults with the Fault Management Framework.