I'm sure I need an extra partner link, and so I did add another port type to the process wsdl which should be mapped to the receive activity. As for the rest, I'm not sure I understand how that works. What does "initiate correlation set" mean? If I'm basing my correlation to the process instance by instance id which is a part of the callback message, it means that all other activities have nothing really to bind to the correlation set, so I'm not sure what would attaching correlation set to this activities do. Another question is how would I "initialise" the correlation set with the process id so that when it has to be matched later with the callback part, it would be able to.
Given the following example simple workflow attached with a receive1 which activates the workflow, invoking some activity on a web service and returning the result, with parallel receive for receiving the callback, how can I configure the correlation such that messages having the part process id equals the process instance id will join the running instance rather than create a new one? http://old.nabble.com/file/p26809806/Picture%2B2.png Picture+2.png I created a property called process id: <vprop:property name="processId" type="xsd:string"/> and added a alias for the callback message part: <vprop:propertyAlias messageType="tns:MediaCompositeFaultCallbackOperationRequest" part="pid" propertyName="tns:processId"/> But that surely is not enough. For one thing there needs to be a way to say that I want to match the incoming message part process id with a variable from the process. Another thing is what must be done with regards to correlation for the rest of the invoke/receive activities. Thanks, Dawg Greg Lucas-3 wrote: > > Sorry, hit send by mistake. > > You will need a partner link for the receive, but it does not have to be a > partner link used elsewhere in the process. You will also need to initiate > the correlation set prior to the async receive; but you can do that on a > message activity associated with a different partner link. For example, > you might initiate the correlation set on the receive activity that > instantiates the process instance, or on some invocation of another > partner link that happens before entering the scope with your async > receive. > > > ~Greg > > On Tue, 15 Dec 2009 16:00:03 -0500, Greg Lucas <[email protected]> > wrote: > >> For this to work you'll need: >> - a partner link for the receive activbity >> >> >> >> On Tue, 15 Dec 2009 15:07:05 -0500, dawg <[email protected]> wrote: >> >>> >>> Hi, >>> >>> Here's what I'm trying to do: >>> In parallel to the whole execution flow of the process, I want to have >>> another receive activity that would be able to receive a message. Now >>> the >>> match between the process to select and the message sent can be based >>> on the >>> process id, so it is reasonable to assume that the sender has it. This >>> is >>> the use case (or its vague version). >>> >>> I thought I'd be able to implement that with correlation sets, but I'm >>> not >>> sure that's correct. The problem is that this callback message is not >>> sent >>> from any of the partner links, and has no direct relation to any invoke >>> activity. So what I really want is that every other message that is >>> directed >>> to this process will create a new instance, while this message will be >>> directed to the process which has this process id. >>> >>> Assuming I created a property process Id, and created an alias to it >>> from >>> the message part that matches the callback message, and defined and >>> attached >>> the correlation set to this callback receive activity. How do I >>> initialise >>> the process id to match with? why do I have to attach the correlation >>> set >>> (if I do) to all invoke/receive activities? >>> >>> Perhaps correlation sets are not the right solution to my problem. In >>> that >>> case, any other ideas? > > -- View this message in context: http://old.nabble.com/Callback-to-a-process-tp26800917p26809806.html Sent from the Apache Ode User mailing list archive at Nabble.com.
