Thursday, April 25, 2013
Friday, December 14, 2012
DB Adapter Message Throttling in Oracle SOA 11g
Friday, May 11, 2012
Oracle Fusion Middleware 11g (ofm11g) on Centos 5
Because of a little illness Lucas was a bit faster with the publish of his article
Now we need to invoke the first detail process
The last property is used in cases in which we have multiple detail processes and the signals need to get correlated back with the master process. Now lets see what is needed in the first detail process to receive the signal and eventually send one back to the master process. The first activity after the receive is the receive signal
After receiving the signal the detail process can execute some logic and eventually send back the signal to the master process
If this is not the case we need to wait on the receiveSignal from the first detail process before we can start the second one.  If both processes can execute their logic and eventually send the signal back we can also receive both signals on the end of the master process. If both signals are receive we can do the callback because the whole process (master and all his details have been completed). And in this case we can invoke the detail processes like oneway processes, but still inform the master process about the state of all these oneway (long running?) processes. At the end aggregate all the signals and do the callback or some other activity which is needed as soon all the detail processes reported back.  Testcase1 What will happen if we remove one of the receiveSignals from the Master process.  the master process will wait on the receivesignal activity until it receveid it. Testcase2 What will happen when we do not send the signal from the master process to the detail process but leave the receiveSignal in the detail process.   The master process will wait on the receiveSignal from detail process1. Since the invoke of the both detail processes are oneway and we do the ‘check’ on the receiveSignals at the end, detail process1 will just complete and send the signal back to the master process. After this the master process will keep on waiting on the signal from detail process1. Testcase3, when all just works     Eventually the flow of the master process can look like this. In here i placed the receiveSignals to the end of the process. You can also place them after the invokes of the detail processes, so you’re sure they will wait on each other.  |
but i decided to still post it on my blog.
Oracle BPEL Fault Policy Framework handling custom business faults
In certain situations the default set of faults defined by Oracle aren’t suited enough and you need to define your own faults. If we look into the examples which got supplied by Oracle we can see an example over here. In this example they defined their own NegativeCredit-fault. The Oracle BPEL Fault Policy Framework by default only handles the faults which are getting returned on an invoke-activity. So we have our own custom fault and the knowledge we can only let this fault getting catched by the framework by use of an invoke. So we need atleast for this testscenario 2 bpel processes. One mainprocess which calls a subprocess, and this subprocess will throw the custom business fault. This fault will get propogated back to the mainprocess and in here we will be able to let the framework handle the fault.  BPEL Processes Mainprocess  Subprocess  Just a simple invoke of the subprocess from the mainprocess. The subprocess with throw a fault, and this fault will be catched in the mainprocess.  The fault to be thrownFrom the console start the mainprocess and wait till it comes back with a fault message  Click the activity to see the thrown fault
So the custom fault we defined in the subprocess reaches the mainprocess. Now we need to config the fault policy framework so it will get active on our custom business fault. From the fault we pasted above we need the faultname (BusinessFault) and the namespace (http://nl.iteye/integration/faults/business). Edit /bpel/domains/default/config/fault-policies/DefaultPolicy.xml and add the next fault :
Now restart the components opmnctl stopall opmnctl startall Now start the mainprocess again and wait till it fails.  It looks like the framework got active (activity yellow marked) on our custom business fault. Go to the activities-tab  And click the activity which faulted.  Now we can edit some of the values and let the subprocess get re-invoked. So, at this moment we’re able to throw our custom business faults and let them getting catched by the framework. Since the fault is only getting catched on the invoke of a partnerlink, we aren’t able to let our custom business fault getting throwned to the process in which we maybe want do something with the data for which we actually throwed the custom business fault. So maybe we want to stay in the subprocess and somehow get the custome business fault thrown inhere, let the framework catch it and update the values of this subprocess with new values an re-execute the subprocess. The next solution will get this done. The mainprocess won’t get changed but in the subprocess we will invoke a new process called AllBusinessFaults. New subprocess 2  AllBusinessFaults  The AllBusinessFaults will throw the custom business fault we ‘request’ back on the invoke in this subprocess. Now it wil get catched by the framework and we will be able to change the values of the subprocess instead of the mainprocess.  By using the AllBusinessFaults bpel service like a sort of composite service, we can add the custom business faults in it and throw the one we would like to get thrown. This will work if the collection of custom business faults isn’t that big. I’m sure there will be better solutions for this, but for the scenario i wanted to describe inhere it was good enough for me. |
Getting started with Oracle SCA, SOA, BPEL, OSB, AIA
As I do SOA projects for a few years, many users are just entering this
service oriented architecture world. For me the technology is common
sense and I expect often that Service Oriented Arcitecture (SOA),
Business Process Execution Language (BPEL), Enterprise Service Bus (ESB)
is well known. But off-course this is not the case. When I started
working with SOA/BPEL/ESB it was, and still is, a steep learning curve.
The Oracle developers world comes from a traditional approach; thinking
in functions and entities and since Java came to us, we are even
thinking about objects and inherited them.
Oracle Application Integration Architecture Documentation
Installation
API Tutorials Oracle Blogs Oracle Forum Oracle General Useful tools
|
Oracle BPEL 11g - Correlation Sets
Correlation
Sets is as set of configurations that allow the process to receive
messages during its execution even if the invoker doesn't have the
Correlation ID necessary to indicate to the engine to which instance
the message needs to be delivered. With Correlation Sets a group of
business data can be used to inform the engine how to match the message
received with the correct instance that is already in execution.
To understand correlation sets is necessary to know some main concepts:
Itens below is a step-by-step showing how to configure Correlation Sets:
1 - Create a new operation in the process interface, allowing it to receive a message during process execution
2 - Change the process to use the new operation during the process execution
3 - Create and initialize the Correlation Set with business value that will be used to match the message that will be received
4 - Match the incoming message
With this configuration, BPEL engine can match business value
stored in the property (initialized in the first Receive activity)
with the the message value received by the Intermediate Operation and
deliver the message for the correct running instance.
To download this sample, click here.
|
BPEL - Correlation, fault handling, and compensation
The previous entries have covered the fundamentals of BPEL, providing
an understanding of the activities defined and how they can be combined
together using structured activities and the  The invoke activity exhibits a short-cut mechanism for defining handlers directly on its definition. The behavior is effectively that it becomes wrapped in a scope that will have these specified handlers. BPEL defines a set of built-in faults that notify of errors such as assignment type mismatches, a scope forcing the termination of a nested scope, and activating a reply activity that doesn't have a matching receive activity. The BPEL engine is responsible for detecting these faults and throwing them to the appropriate scope. Compensation While a business process is running, it might be necessary to undo one of the steps that have already been successfully completed. The specification of these undo steps are defined using compensation handlers that can be defined at the scope level. Each handler contains one activity which is run when a scope needs to be compensated. The activities within such a handler must see the container data to be that which it was when the scope completed. Due to activities sharing containers and loops caused by while activities, completing scopes that are compensation-enabled must save a snapshot of the data for the handler to possibly use later. Once a scope completes successfully, its compensation handler becomes ready to run. This can happen in either of two cases: explicit or implicit compensation. Explicit compensation occurs upon the execution of a compensate activity. This activity may occur anywhere, and refers to the name of the scope that it wants compensated. Scopes that might be rolled back in this manner must therefore be named. BPEL further specifies that names of scopes must be unique within a BPEL process. When a compensate activity is reached, it runs the compensation handler on the specified scope. On the other hand, implicit compensation occurs when faults are being handled and propagated. Consider the scenario in which a scope A contains a compensatable scope B that has completed normally, but then another nested activity in A throws a fault. Implicit compensation ensures that whatever happened in scope B gets undone by running its compensation handler. Therefore, implicit compensation of a scope goes through all its nested scopes and runs their compensation handlers in reverse order of completion of those scopes. |
SOA ,OSB,REST and Middleware Related Stuff
Basic Fault Handling in SOA 11gIn Oracle SOA 11g, faults can be categorized broadly into two categories:- System Faults and Custom Faults.So, let us get started to see how it works.In this first example, we are going to see how faults are propagated. First,open JDev and create a new SOA Application and a SOA project, select empty composite template.Now drag and drop a BPEL process onto your composite application.Name it FaultHandlerBPEL and choose synchronous template;leave the default input and output and make sure the "Expose as SOAP service" check box is checked.  Hit ok once you are done.In the FaultHandlerBPEL process, we are going to handle the faults.Drag another BPEL process.Name it FaultThrowerBPEL.Like before, choose synchronous template and accept the default input and output.However, do not expose this BPEL process .i.e. the check box "Expose as SOAP service" should be unchecked.  As the name implies, the FaultThrowerBPEL process throws a fault Now wire the FaultHandlerBPEL to the FaultThrowerBPEL process.Your composite should look like the following image:-  Now, double click on the FaultThrowerBPEL process to open the BPEL process editor.Now,drag a Throw activity between the receive and reply activity.Name the activity ThrowFault.  Now double click on the Throw activity.A window will pop up.Click on the magnifying glass as shown in the image below to select the fault.  In the fault chooser window, expand the System Faults node and select remoteFault.Hit ok once you are done.  This will bring you back to the previous window.Now click on the green plus sign to add a fault variable as shown in the image below:-  Accept the default name and scope in the variable creation window.Hit Ok twice to come back to the BPEL process.  So in the previous steps, what we have done is we have created a throw activity which throws a remoteFault.While throwing the fault, we have also specified a fault variable.Using the throw activity, we can throw system faults and custom faults.However, the custom faults are discussed later.So, if you are familiar with java, up to now we have written something like this:- throw new Exception(); Notice that, once we create a fault variable, a new WSDL file is added to our project.The name of the WSDL file is RuntimeFault.wsdl.The wsdl file is a simple one which contains a message on which the fault variable is based on.It is important to mention here that in SOA 11g, the fault variables must be WSDL message based,be that a custom fault variable or a system fault variable. Now, drag and drop an Assign activity just before the Throw activity.Name it AssignFaultDetails.The BPEL file should look like the following image:-  Now double click on the assign activity.Add a copy operation.  Choose expression on the from side and enter the string '007'.On the to side,expand the FaultVar node and select the code part.  Hit Ok once you are done.Now,add another copy operation.On the from side, select expression and enter the string 'My Fault Summary'.On the to side, expand the FaultVar node and select the summary part .  Add another copy operation.Like before, on the from side select expression and enter the string 'My Fault Details'.On the two side, expand the FaultVar node and select detail node.Hit Ok twice to complete the Assign activity. So the assign activity populates the fault variable with some dummy data before the fault is thrown. This completes our FaultThrowerBPEL process. Next open the composite.xml and double click on the FaultHandlerBPEL to open the BPEL editor.Next, drag and drop an Invoke activity onto the BPEL process between the Receive and Reply activity.Double click on the invoke activity.Enter the name InvokeFaultThrower.Next click on the magnifying glass beside the Partner Link as indicated in the following image:-  The partner link chooser dialog opens.Select the FaultThrowerBPEL.faultthrowerbpel_client partner link and hit ok.  Back in the invoke dialog, create input and output variables.Choose the default name.Your BPEL process should look like the following image.  Add an Assign activity before the invoke activity.Name it initialize variable.Create a copy operation as shown in the follwing image:-   Hit Ok twice to come back to the BPEL process.Now click on the validate icon on the upper left corner of the BPEL process as shown on the image below:-  All the warning signs from the BPEL process should disappear now.If you test the process now and invoke the FaultHandlerBPEL, when executing the invoke activity InvokeFaultThrower, a fault is going to be thrown.This is because the FaultThrowerBPEL is going to be invoked which is going to throw a remoteFault.As we do not have any catch or catchAll activity in the FaultThrowerBPEL, the fault is going to be propagated to the FaultHandlerBPEL. Now add a catch all branch.To do this, click on the add catch all branch icon as indicated in the image below:-  A new catch all branch is going to be added to the BPEL process.Expand the catch all activity and drag and drop an Assign activity under the catchAll activity and name it PopulateOutput.The BPEL process should now look like the following image:-  Double click to open the Assign activity and add a copy operation.On the from side select, expression,open the expression builder and enter expression:- concat(ora:getFaultName(),'::',ora:getFaultAsString()) On the to side, select the result element as shown in the image below:-  The function ora:getFaultName() returns the fault name i.e. remoteFault in this case.The function ora:getFaultAsString() returns the details of the fault which contains all the parts i.e. code, summary and detail.Next drag and drop a Reply activity under the catchAll branch just below the PopulateOutput Asign activity.Your BPEL process should look like the following image:-  Double click to open the Reply activity.Enter replyOutput as the name.Now select the partner link as before.In the partner link chooser, select the faulthandlerbpel_client partner link.Hit ok to comeback to the previous window.  Now click on the magnifying glass beside the Variable chooser as shown in the image below:-  In the variable chooser, choose the output variable.  Hit Ok twice to complete the Reply activity.In the previous steps, we created a catch all branch synonymous to java "catch(Exception e){}".Now,inside the catch all, we have implemented an Assign activity which update the output variable with the details of the fault and a Reply activity which replies to the calling process. Now deploy and test the service from the EM console.A fault is going to be returned when you invoke the ErrorHandlerBPEL from the EM console. Returning a fault from a synchronous BPEL process:- Now we are going to see how we can return a fault from a synchronous BPEL process.To do this, open the FaultThrower BPEL process. Next add a catch branch by clicking on the add catch branch as indicated in the image below:-  Now double click on the catch branch that is created .Now we are going to choose the fault that we intend to catch which is, in this case, a remoteFault.Click on the magnifying glass icon as indicated in the image below to bring up the fault chooser window. 
In the fault chooser window, select remoteFault.Hit Ok once you are done.
 Next click on the magnifying glass icon as indicated in the image below to select a fault variable.Here, we are going to reuse the same variable that we created while throwing the fault.Alternatively, you can create a new fault variable by clicking on the green plus icon.In this case, the fault variable is going to be automatically populated when the fault is caught. .  Next, choose the FaultVar and hit Ok once you are done.Hit Ok again to complete the catch activity.So in java syntax, we have written something like this:- catch(RemoteFault faultVar){}  Now drag and drop a Reply activity under the catch activity.Your BPEL process is going to look like the following image.  Next we are going to configure the reply activity to reply with a fault.Double click on the Reply activity.Enter ReplyFault as name.Choose the faultthrowerbpel_client partner link.Now, select the fault variable as the variable.Next click on the magnifying glass as indicated in the following image to choose the fault that we intend to return.  In the fault chooser dialog, select remoteFault.Hit Ok once you are done.  The reply activity should look like as shown in the following image.  Hit Ok to complete the reply activity.The BPEL process should look like the following image.  Next,we have to configure the operation for the FaultThrower BPEL to indicate that he process can return a fault.To do this, open the FaultThrower.wsdl file and go to source.Notice that the RuntimeFault.wsdl is imported into this WSDL automatically.  Now, add a new fault inside the operation.The fault should be based on the message as defined in the RuntimeFault.wsdl.file.Make sure the namespace is declared.  This completes the BPEL process.Now deploy and test the web service.The behavior is going to be the same;this time though, the fault is caught by the FaultThrowerBPEL.Once caught, the FaultThrowerBPEL replies to the calling BPEL i,e, the FaultHandlerBPEL in this case with a remoteFault.This remoteFault is then caught by the catchAll activity inside the FaultHandlerBPEL.So in java syntax, we are doing something like this in the FaultThrowerBPEL:- .... catch(RemoteFault faultVar){ throw new RemoteFault(faultVar); } |