SOA 11g - Setting and getting Preferences in SOA BPEL Process.

SOA 11g - Setting and getting Preferences in SOA BPEL Process.

Deployment descriptors are BPEL process service component properties used at runtime by Oracle WebLogic Server, Oracle Enterprise Manager, or both.

Oracle has provided the functionality to add preferences to your bpel process.Preferences are like a variable whose value can be changed from EM console requiring no code change.For instance,consider one use case for File adapter.Suppose in test environment we are writing the files to /test/source location.Now once the code is migrated to production environment, now you want to write the files to /prod/source location.

These type of properties can be set using preferences, where you have to just update the value of preference variable for dircetory location on EM and there you go.We dont have to explicitly make changes in the code to point it to new location and deploy it again.

Depends upon requirement,what type of variables in BPEL can be declared as preferences.Ill be demonstrating how to set and get the values of these preference variables and how to change them using Enterprise Manager.

Step1: I will be using "HelloWorld" tutorial for this that we created in my first post.Open up your Hello World BPEL process.

Step2: Got to source of composite.xml and add "<property name="bpel.preference.MyVar">Old Value in Response</property>" in component section.Here we are setting the value for variable "MyVar" which we will be using in our BPEL process.

Step3: Now double click and open your BPEL process.Open the assign action.We will be populating the result of our BPEL process using this preference variable.Double click on result of our output variable to open up the expression window.Drill down to BPEL XPath Extension Functions and insert getPreference into expression field.Add the preference var in the function asora:getPreference("MyVar").Make sure you enclose your preference variable using double quotes.Click OK.

Step4: your assign action will look like this.Click OK.

Step5: Now deploy your composite on EM and test it passing any random input and open the flow trace of invoke composite.In the assign action you will see value of result as "Old Value in Response".It is the same value that we set inside composite.xml.

Step6: Now we will change this value from EM to some other value.Right click on SOA-Infra --> Administration --> System MBean Browser.

Step7: Drill down to your composie following this path oracle.soa.config-->Mgd Sever --> SCAComposite-->HeloWorld-->SCacomponnt.SCAComposite-->HelloWorldProcess.

Step8: Click on the properties tab on the right hand side and expand properties tab to find out element containg your defined preference variable

Step9: Change its value and click "Apply"

Step10: Test your interface again and thsi time you will see the updated value in the result.

In this way you can define n number of preference variables in your composite.xml and use them in your BPEL process.Should you guys have any question ,feel free to ask.

SOA 11g - BPEL Fault Handling

SOA 11g - BPEL Fault Handling

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
• 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.

Kindly download below artifacts required for this tutorial:

RuntimeFault WSDL
BusinessFault WSDL
Employee Schema
Fault Schema

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.

Hope you guys enjoyed it.....Any doubt please feel free to ask me...!!!!

SOA 11g - Setting a Timeout for a WebService invocation in BPEL

1. Given a process that invokes a Local or Remote WebService, we want to set a timeout of 10 seconds that the BPEL will wait for the answer. If no response is received within the specified timeout, we want to perform a series of activities (eg. WebService not available, end the BPEL process, etc). "WS_Call" is the Invoke operation on the WebService.


2. In the Sequence where "WS_Call" Invoke activity, add a Catch branch :

and set it's properties to catch a RemoteFault. We need to Catch a RemoteFault because this is the type of fault that the "timeout" we are setting in next step will throw when the timeout will expire:

In the Catch branch you can process the error : Terminate the process, insert a Reply/Response to return from the Bpel, make some Assign activity and then continue the Bpel, etc.


3. Set the property "timeout" for the PartnerLink to 10 seconds .
This specifies the number of Seconds to wait until expire. A remote fault is thrown if this happens.


and if the WebService is on the SAME host as the BPEL you also need to set the property "optSoapShortcut" to FALSE.
You need this to FALSE to force local SOAP request to go through SOAP instead of internal calls.

This final step can be directly configured in bpel.xml in partnerLinkBinding section:

Now if the WebService invocation takes more than 10 sec, it should throw a RemoteFault that will be catched in the Catch branch that we built.