The ‘Validate’ activity in Oracle BPEL gives us the functionality to validate variables again schema definitions.
When using it in your bpel process you will get a nice informative message in the ‘Flow trace’.
When you’re using some generic error hospital functionality you also want this message to be available in there.
First try would be, add a Scope around the activity and catch the ‘invalidVariables’ System Fault.
<myRuntimeFault> <part name="summary"> <summary xsi:type="def:string"/> </part> <part name="detail"> <detail xsi:type="def:string"/> </part> <part name="code"> <code xsi:type="def:string"/> </part> </myRuntimeFault>
Because of some bug in the engine you won’t be able to get a handle to the fault message.
To be able to retrieve the fault message do the next.
Create a mediator in the composite based on a wsdl/operation which you ‘represent’ the element you’re trying to validate.
If you have a variable in your process like this :
variable name=”myEmployee” messageType=”emp:myEmployeeMessage”
variable name=”myEmployee” element=”emp:myEmployeeRef”
Then also create/use a wsdl which exposes an operation with the same messagetype/element in it.
In certain situations you will be validating an element which isn’t available directly in some operation in some wsdl (for example when you validate against an element which is only defined in a canonical xsd definition).
In that case just create a dummy wsdl/operation and use the element-definition in there, make sure you use the same namespace-structure.
In the mediator enable the validateSchema option (true)
<Mediator name="validateInput" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" wsdlTargetNamespace="http://xmlns.oracle.com/ValidateService/ValidateProject/ValidateProcess" xmlns="http://xmlns.oracle.com/sca/1.0/mediator"> <operation name="process" deliveryPolicy="AllOrNothing" priority="4" validateSchema="true"/> </Mediator>
We won’t be defining any routing rules, we just need the operation to validate the input and that’s it.
When the input isn’t validate it will trigger a remote fault which we will catch in our bpel process.
Instead of using the validate-activity, create an invoke to the mediator partnerlink.
As you can see, we now receive a fault stack back which includes our validation message.
The remote fault will be thrown by the mediator, in the second scope we now catch the remote fault instead of the invalid variables fault, and this fault variable does contain the information we need.
download : ValidateProject.zip