Thanks Greg, it helps in understanding, the problem is that it is a bit intrusive on the invoked web services. Is there a way to do it without forcing the partner links having to receive the process id as parameter?
With regards to ODE specific extensions, is there anything that could be useful for what I want to do? (I don't mind portability much, it's a research project rather than a product) Thanks, Dawg Greg Lucas-3 wrote: > > Hi Dawg, > > Ignoring engine-specific extensions, a BPEL correlation set is initialized > as part of a messaging activity (receive/invoke/reply/onMessage/onEvent) > based on properties of the incoming or outgoing message. On a messaging > activity you can identify the correlation set(s) for that message and > whether each correlation set should be initiated. (There's also a third > option called join, which means initialize the correlation set if it > hasn't yet been initialized - take a look at BPEL spec for details.) > > So correlation sets are not like variables that you assign directly, but > are initialized based on content of a message being sent or received. ODE > provides an extension to get the process id (ode:pid). The typical way to > do what you describe would be to invoke some partner link and include the > pid in the outgoing message, initiating the correlation set from the > message as part of the invoke. You can then use that correlation set to > correlate a receive for the same or another partner link. > > Does that help? > > On Wed, 16 Dec 2009 06:35:54 -0500, dawg <[email protected]> wrote: > >> >> 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? > > -- > Greg Lucas > > -- View this message in context: http://old.nabble.com/Callback-to-a-process-tp26800917p26811911.html Sent from the Apache Ode User mailing list archive at Nabble.com.
