ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Noel <Christophe.N...@spacebel.be>
Subject RE: Questions About Correlation Sets
Date Wed, 15 Jun 2011 08:28:42 GMT
Hello Lei,

The correlation works like this:
- You define that a property (an element of a message) defines a unique key used for the correlation
- In your receive activity (if initiate=yes), the workflow instance is mapped with the correlation
key present in the message
- Future incoming message will be mapped to the workflow instance if the exact correlation
key is found in the defined location

Therefore, your client workflow doesn't have to "correlate" anything. You are just sending
message to a service (server workflow) with a key (used by the server correlation) in the
message.

Regarding your problem, are you saying that when the second invoke is done both the existing
instance and the new one receives the message ?! This is not a normal behaviour. Please send
your code.

Christophe.

-----Original Message-----
From: 王雷 [mailto:mail.lei.wang@gmail.com] 
Sent: mercredi 15 juin 2011 10:01
To: user@ode.apache.org
Subject: Re: Questions About Correlation Sets

Hi Christophe,

    Sorry that I did explain it clearly. By talking about "client" orchestration and "server
side", I am talking about 2 independent workflow. The following is what I want to do: One
workflow, name it workflow A, sends the same invoke message twice. Another workflow, name
it workflow B, receives the same invoke messages twice.
    I am not famaliar with correlation sets very much. I find in your comments you said that
the correlation set in the "client side" are non sense. Did you mean in the workflow A (client
side), for the invoke activities, I do not need to put correlation set information in them?
    The two points you metioned are confirmed.
     - For workflow B (server side), the correlation set is initialized in the first receive
activity with initiate property valued to "yes". The
     - The correlation property of c1 is exactly the same.

    However, it still works in the following way: For the first invoke activity, workflow
B (server side) creates a new instance for the invocation. For the second invoke activity,
the engine routes the request message to the existing running instance of workflow B correctly.
However, while at the same time, the workflow B (server side) create a new instance and also
routes this message to the newly created instance. I do know whether my question is clearly
explained or not. If necessary, I can put the source code somewhere and share it with everyone.
Thanks for helping.


    Best Regards



                     Lei
2011/6/15 Christophe Noel <Christophe.Noel@spacebel.be>

> 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:mail.lei.wang@gmail.com]
> 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
>

Mime
View raw message