Today I will show you one of the most important concept in any software developed using any programming language i.e "Handling Faults".Like in every other language there are number of mechanisms to handle exceptions that may arise while invoking certain piece of code. In BPEL as well there is a meachanism for handling faults.These faults should be handled and required actions should be taken in event of failure at any stage.There are two categories of BPEL faults:
Business faults are application-specific faults that are generated when there is a problem with the information being processed (for example, when a social security number is not found in the database). A business fault occurs when an application executes a throw activity or when an invoke activity receives a fault as a response. The fault name of a business fault is specified by the BPEL process service component.A business fault can be caught with a faultHandler using the faultName and a faultVariable.
<catch faultName="ns2:BusinessFault" faultVariable="BusinessFaultVar">
Runtime faults are the result of problems within the running of the BPEL process service component or web service (for example, data cannot be copied properly because the variable name is incorrect). These faults are not user-defined, and are thrown by the system. They are generated if the process tries to use a value incorrectly, a logic error occurs (such as an endless loop), a Simple Object Access Protocol (SOAP) fault occurs in a SOAP call, an exception is thrown by the server, and so on.
Several runtime faults are automatically provided. These faults are included in the http://schemas.oracle.com/bpel/extension namespace. These faults are associated with the messageType RuntimeFaultMessage. The WSDL file shown below defines the messageType:
<?xml version="1.0" encoding="UTF-8" ?>
<definitions name="RuntimeFault"
targetNamespace="http://schemas.oracle.com/bpel/extension"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<message name="RuntimeFaultMessage">
<part name="code" type="xsd:string" />
<part name="summary" type="xsd:string" />
<part name="detail" type="xsd:string" />
</message>
</definitions>
If a faultVariable (of messageType RuntimeFaultMessage) is used when catching the fault, the fault code can be queried from the faultVariable, along with the fault summary and detail.
bindingFault
A bindingFault is thrown inside an activity if the preparation of the invocation fails. For example, the WSDL of the process fails to load. A bindingFault is not retryable. This type of fault usually must be fixed by human intervention.
remoteFault
A remoteFault is also thrown inside an activity. It is thrown because the invocation fails. For example, a SOAP fault is returned by the remote service.
replayFault
A replayFault replays the activity inside a scope. At any point inside a scope, this fault is migrated up to the scope. The server then re-executes the scope from the beginning.
In this example I'll demonstrate how to handle different types of BPEL faults inside any BPEL process and take required actions.BPEL process will be created based on a schema and it will be exposed as web service.To showcase diferent types of faults we will be using primarily two activities such as Throw and Catch.
Throw Activity is used to generates a fault from inside the business process.
Catch Activity is used to catch specific faults indiviually such as business,runtime or binding fault.Catch All activity catches all the faults that are not being catch in other catch activities.
For my tutorial i am using below WSDLs :
Lets start with the tutorial
1. Create a new SOA project with name "FaultHandling".Drag and drop BPEL process onto the components lane.Pop will open up, give BPEL process the name "FaultHandlingProcess" and in tmplate select "Base on a WSDL".
2. Click the cog icon next to WSDL URL to generate WSDL from schema.Create WSDL pop will open up.
3. In the input section, click on "+" icon to add message part.In the next window change the partname to paylaod and click the torch button.
4. Type chooser window will come up.Drill down to Employee.xsd and select "EmployeeDetails" and click OK.
5. Click OK again.
6. BPEL process is configured based on WSDL.Click Finish.
7. Since we have chose the option to expose as web service.Our composite will look like this.
8.Double click and open up the BPEL process.Drag and drop switch activity after receive activity.
9. We will be using this switch activity to throw different faults explicitly.Add a switch case.
10. Under first switch case, add the condition to check for City name "Canada".
11. Similarly for the second switch case do it for "London".
12.Save all.Your BPEL process will look like this so far.
13. Drag and drop throw activity inside first switch case. In this activity we will be throwing Business Fault.
14. Open up your BusinessFault.wsdl and copy namesapce from there "http://xmlns.example.com/service/fault/businessfault".
15. Double click the throw activity and under namespace URI paste the copied namespace and give local name as "BusinessFault".What this activity does is it will throw a business fault and all the details of the fault such as faultcode, details and summary will be stored under "Fault Variable".
16. Create new variable "BusinessFaultVar" of message type as "Business Fault Message".
17. Inside throw activity browse for fault variable that we just created.Click OK.
18. Inside second switch case drag and drop one more throw activity.And for Fault QName click Browse.
19. Window that will pop up, you will see number of system faults that cane be there.Since we are throwing binding fault in this switch case.Select Binding Fault.
20. Like we did for business fault ,similarly create variable for binding fault as well.But this time it should be of "RunTimeFaultmessage" type.
Because binding fault is a part of runtime fault.Its details will be captured using this variable only.
21. Click OK.
22.In the otherwise case configure thorw activity to throw remote fault.
23. Now add 3 catch blocks for the main scope activity,by clicking the "Add Catch branch."
24. Similarly add one catch All activity.
25. Your process will look like this.As explained earlier, we will be using three catch activities to handle business,remote and binding faults indiviually and all other remaining fault that may come will be catch by CatchAll activity.
27. Double click first catch activity.Populate the fields like we did for throw activity.In the first catch we will be catching Binding Fault.
28. Similary catch remote and business fault in other two catch activities.
29. Now we will assign values to these variables that will be used inside catch activities.As we are explicitly throwing faults thats why we are populating these fault variables,otherwise in real case scenario thses will get automatically populated.Drag and drop three assign activiies under each throw activity.
30. In the first assign in case of Business Fault we will populate "BusinessFaultVar".
31. Same for Binding and remote fault.
32. Create a variable of FaultMessage type using FaultSchema.xsd.Now we will assing the fault details such as code, summary to this fault variable just to show how to fetch the fault details in case of any Fault.
33. Drag and drop assign activity under each catch and catchAll activity and map Fault details to the FaultMessage variable.
34. Now our composite will look like this.
35. Save all, compile and deploy it.Open EM and drill down to your SOA Composite.Click on Test Button.First we will check Binding Fault.So enter City name = "Canada" rest other any random details.Test WebService.
37. Open up the flow trace.You will see binding fault being thrown and it is being caught in Catch Binding Fault block.
38. Similarly like this test Business and remote fault as well.
So, in this way you handle faults in any BPEL process. Please note in real case scenarios you dont have to explicitly use throw activity to throw faults such as binding or remote fault.Only use throw activity whenever you want to raise Business exception such as invalid credit card no or negative balance for instance.Binding or remote or any other fault that may raise during execution of code can be catch using catch activity and remaining using CatchAll activity.
- Business Faults
- Runtime Faults
Business faults are application-specific faults that are generated when there is a problem with the information being processed (for example, when a social security number is not found in the database). A business fault occurs when an application executes a throw activity or when an invoke activity receives a fault as a response. The fault name of a business fault is specified by the BPEL process service component.A business fault can be caught with a faultHandler using the faultName and a faultVariable.
<catch faultName="ns2:BusinessFault" faultVariable="BusinessFaultVar">
Runtime faults are the result of problems within the running of the BPEL process service component or web service (for example, data cannot be copied properly because the variable name is incorrect). These faults are not user-defined, and are thrown by the system. They are generated if the process tries to use a value incorrectly, a logic error occurs (such as an endless loop), a Simple Object Access Protocol (SOAP) fault occurs in a SOAP call, an exception is thrown by the server, and so on.
Several runtime faults are automatically provided. These faults are included in the http://schemas.oracle.com/bpel/extension namespace. These faults are associated with the messageType RuntimeFaultMessage. The WSDL file shown below defines the messageType:
<?xml version="1.0" encoding="UTF-8" ?>
<definitions name="RuntimeFault"
targetNamespace="http://schemas.oracle.com/bpel/extension"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<message name="RuntimeFaultMessage">
<part name="code" type="xsd:string" />
<part name="summary" type="xsd:string" />
<part name="detail" type="xsd:string" />
</message>
</definitions>
If a faultVariable (of messageType RuntimeFaultMessage) is used when catching the fault, the fault code can be queried from the faultVariable, along with the fault summary and detail.
bindingFault
A bindingFault is thrown inside an activity if the preparation of the invocation fails. For example, the WSDL of the process fails to load. A bindingFault is not retryable. This type of fault usually must be fixed by human intervention.
remoteFault
A remoteFault is also thrown inside an activity. It is thrown because the invocation fails. For example, a SOAP fault is returned by the remote service.
replayFault
A replayFault replays the activity inside a scope. At any point inside a scope, this fault is migrated up to the scope. The server then re-executes the scope from the beginning.
In this example I'll demonstrate how to handle different types of BPEL faults inside any BPEL process and take required actions.BPEL process will be created based on a schema and it will be exposed as web service.To showcase diferent types of faults we will be using primarily two activities such as Throw and Catch.
Throw Activity is used to generates a fault from inside the business process.
Catch Activity is used to catch specific faults indiviually such as business,runtime or binding fault.Catch All activity catches all the faults that are not being catch in other catch activities.
For my tutorial i am using below WSDLs :
1. Create a new SOA project with name "FaultHandling".Drag and drop BPEL process onto the components lane.Pop will open up, give BPEL process the name "FaultHandlingProcess" and in tmplate select "Base on a WSDL".
2. Click the cog icon next to WSDL URL to generate WSDL from schema.Create WSDL pop will open up.
4. Type chooser window will come up.Drill down to Employee.xsd and select "EmployeeDetails" and click OK.
5. Click OK again.
6. BPEL process is configured based on WSDL.Click Finish.
7. Since we have chose the option to expose as web service.Our composite will look like this.
8.Double click and open up the BPEL process.Drag and drop switch activity after receive activity.
9. We will be using this switch activity to throw different faults explicitly.Add a switch case.
10. Under first switch case, add the condition to check for City name "Canada".
11. Similarly for the second switch case do it for "London".
12.Save all.Your BPEL process will look like this so far.
13. Drag and drop throw activity inside first switch case. In this activity we will be throwing Business Fault.
14. Open up your BusinessFault.wsdl and copy namesapce from there "http://xmlns.example.com/service/fault/businessfault".
15. Double click the throw activity and under namespace URI paste the copied namespace and give local name as "BusinessFault".What this activity does is it will throw a business fault and all the details of the fault such as faultcode, details and summary will be stored under "Fault Variable".
16. Create new variable "BusinessFaultVar" of message type as "Business Fault Message".
17. Inside throw activity browse for fault variable that we just created.Click OK.
18. Inside second switch case drag and drop one more throw activity.And for Fault QName click Browse.
19. Window that will pop up, you will see number of system faults that cane be there.Since we are throwing binding fault in this switch case.Select Binding Fault.
20. Like we did for business fault ,similarly create variable for binding fault as well.But this time it should be of "RunTimeFaultmessage" type.
Because binding fault is a part of runtime fault.Its details will be captured using this variable only.
21. Click OK.
22.In the otherwise case configure thorw activity to throw remote fault.
23. Now add 3 catch blocks for the main scope activity,by clicking the "Add Catch branch."
24. Similarly add one catch All activity.
25. Your process will look like this.As explained earlier, we will be using three catch activities to handle business,remote and binding faults indiviually and all other remaining fault that may come will be catch by CatchAll activity.
27. Double click first catch activity.Populate the fields like we did for throw activity.In the first catch we will be catching Binding Fault.
28. Similary catch remote and business fault in other two catch activities.
29. Now we will assign values to these variables that will be used inside catch activities.As we are explicitly throwing faults thats why we are populating these fault variables,otherwise in real case scenario thses will get automatically populated.Drag and drop three assign activiies under each throw activity.
30. In the first assign in case of Business Fault we will populate "BusinessFaultVar".
31. Same for Binding and remote fault.
32. Create a variable of FaultMessage type using FaultSchema.xsd.Now we will assing the fault details such as code, summary to this fault variable just to show how to fetch the fault details in case of any Fault.
33. Drag and drop assign activity under each catch and catchAll activity and map Fault details to the FaultMessage variable.
34. Now our composite will look like this.
35. Save all, compile and deploy it.Open EM and drill down to your SOA Composite.Click on Test Button.First we will check Binding Fault.So enter City name = "Canada" rest other any random details.Test WebService.
37. Open up the flow trace.You will see binding fault being thrown and it is being caught in Catch Binding Fault block.
38. Similarly like this test Business and remote fault as well.
So, in this way you handle faults in any BPEL process. Please note in real case scenarios you dont have to explicitly use throw activity to throw faults such as binding or remote fault.Only use throw activity whenever you want to raise Business exception such as invalid credit card no or negative balance for instance.Binding or remote or any other fault that may raise during execution of code can be catch using catch activity and remaining using CatchAll activity.
Happy Learning
By
Deepthi Reddy
