Well correlation is not as complex as it seems.
Well when I first looked at it, it did not make any sense.
But this is what my experience with correlation is, and it was not as hard as I though it would be.
Though it was not difficult to get it working, I had to do a lot of ground work basically read a couple of articles before I understood what it was all about.
But once I did understand, it was a cake walk.
Whatz correlation? What does it correlate?
What correlation meant to me as a maths student was linear relationship between two random variables.
I initially understood it was to relate two seemly unrelated instances in BPEL, that are related in business sense. And it did turn out that way.
Where to use?
When BPEL is in synchronous mode, the caller waits for the response, so caller instance does the correlation in the background using WS-Addressing, basically add its own correlation to the message header send out.
Itz the asynchronous execution where the BPEL instance fires and forgets who received it. That when you want to say to BPEL which instance to go back to. Here is where BPEL correlation kicks in. What is basically does is use the data in the message to relate the instance. And so the correlation should be unique to the instance.
It does not always need to be A --> B --> C --> A but can be A --> B --> A if BPEL fires and forgets and wants to send back to the caller.
What forced it?
First of all correlation has force itself into my workspace in 2 of the projects that I was involved in. And both of these were for different reasons.
Circular call
Firstly was for the generally known and widely written about one i.e. A--calls -> B --> C --> A, basically a transitive calls that ends up on the caller, and the caller needs to figure out which instance of A --> C should return to.
If canonical data model id used to pass data across then one or more of the elements in the message will be used to build the correlation else one of the those fields in the message will be used for correlation.
FlowN
Second was for a entirely different scenario.
I tried to use FlowN to spawn 'N' 'ProcessB' from a master 'ProcessA'.
Call from 'ProcessA' to 'ProcessB' was asynchronous call. After ProcessB was complete it would return status back to ProcessA.
Without any correlation I was getting
"Conflicting receive.Another receive activity or equivalent (currently, onMessage branch in a pick activity) has already been enabled with the partnerLink "Process", operation name "onResult" and correlation set "" (or conversation id). Appendix A - Standard Faults in the BPEL 1.1 specification specifies a fault should be thrown under these conditions."
To solve this I had to create correlation. The reason being each of the branches in FlowN created exactly the same asynchronous call, but the receiving instance had to identify which spawn in the FlowN was the response coming back to. And yes creation of correlation did solve the problem.
But making correlation in FlowN to work was not straight forward as there were scope issues that I had to address, and I initially did not see coming. I only found explanations about FlowN in oracle forums from the Google I did. Hopefully I would write another blog post for the correlation in FlowN.
Where to setup correlation?
Only the receiver should perform the correlation.
And the sender should only worry about sending enough data to perform correlation.
Related Articles that helped me:
- http://technology.amis.nl/blog/?p=2813
- http://forums.oracle.com/forums/thread.jspa?messageID=2018318
- http://swapnil-soa.blogspot.com/2008/01/correlation-this-post-would-effort-to.html
There was another very good article that helped me but I am unable to find that now.
No comments:
Post a Comment