Hello Lei, I work a lot with correlations. I don't understand correctly your question especially when you talk about the "client" orchestration and the "server side" ? Are you talking about 2 independent workflow ? If yes, the correlation set in the "client side" are non sense.
You should first explain what you want to do... Anyway, in the server side part, if you want to create a correlation on the first receive, then correlates with the second receive : - you should specify that the first correlation set should initiation the correlation (attribute iniate = yes) - you should be sure that the correlation property of c1 is exactly the same in the first and second receive Kind regards, Christophe. -----Original Message----- From: 王雷 [mailto:[email protected]] Sent: mardi 14 juin 2011 23:58 To: user Cc: a.wombacher Subject: Questions About Correlation Sets Hi, I have a question about Correlation Sets. If I design a client orchestration as the following: <process ...> ... <invoke name="invoke1" operation="o1"...> <correlations> <correlation set="c1" pattern="request-response".../> </correlations> </invoke> <invoke name="invoke2" operation="o1"...> <correlations> <correlation set="c1"... pattern="request-response".../> </correlations> </invoke> </process> The feature is that I make the two invoke activities ("invoke1" and "invoke2") invoke the same operation "o1" for two times. For the server side, I design this way: <process ...> <receive name="receive1" operation="o1" createInstance="yes"> <correlations> <correlation set="c1" pattern="request-response".../> </correlations> </receive> <reply .../> <receive name="receive1" operation="o1" createInstance="no"> <correlations> <correlation set="c1" pattern="request-response".../> </correlations> </receive> <reply .../> <process> The feature is that I make the orchestration receives the two invocations one by one. When the first message sent and received by the receiver, a new instance created and everything is OK. After that I find strange things happens. When the client send the second invocation message, which is the same to the first invocation message, for the server part, as I expected, the message is still in a correlationset and the engine should route the message to the currently existing instance. However, the actual behavior is: the engine route the message to the currently existing instance, then the engine create a new instance and also routes the message to the newly created message. Finally, when both orchestrations deployed and tested, it ends up with one completed client instance but two server instance, one in complete state but the other ends up with active state waiting for a message which will never come. As I didn't find any information in BPEL specification about this. I want to ask whether this is expected behavior or a bug? Thanks. Best Regards Lei
