Thanks for your interest. The thing I'd like to do is combining
createInstance=yes and initiate=join. However, as mentioned on
http://ode.apache.org/ws-bpel-20-specification-compliance.html (see below)
this is not supported in Ode, or is it?

Multiple start activities as described in section 10.4, and 15.4 of the
specification <http://ode.apache.org/ws-bpel-20.html>) are not officially
supported. This precludes the use of initiate="join".

I'd like to build a BPEL process in which a new instance is created when two
(or more) correlated  messages are received. For example, if both a order is
ready for delivery and the order is paid a message must be sent to the
shipping service (correlated means the order that is ready for delivery and
the order that is paid have the same id). It is more or less like an ECA
approach.

When invoking the BPEL process using the code from my previous mail,
different process instances are created... I'm not sure this is caused by
the 'implicit correlation', but it gives me that feeling... (see
http://ode.apache.org/bpel-extensions.html#BPELExtensions-ImplicitCorrelations
for
more information on the session thing)

Geert

On Thu, Aug 5, 2010 at 17:18, Tammo van Lessen <tvanles...@gmail.com> wrote:

> Hi Geert,
>
> ODE supports multiple instantiating activities, but of course they then
> start a new instance and thus cannot make use of correlation. Also these ti
> activities activities must be in a flow without links. Could you share
> your bpel file so that I can understand what you're doing?
>
> I don't really understand the session behaviour you're describing as ODE
> does not maintain a session.
>
> Thanks,
>   Tammo
>
> On 05.08.2010 14:09, Geert Monsieur wrote:
> > Thanks for your swift reply!
> >
> > Well, I just noticed that Apache ODE does not support multiple start
> > activities...while this is the thing I would like to have...multiple
> start
> > activities and the possibility to correlate upcoming messages.
> >
> > Session difference:
> >
> >  try { // Call Web Service Operation
> >             slapen.Geertishetmoeservice service = new
> > slapen.Geertishetmoeservice();
> >             slapen.GeertishetmoeservicePortType port =
> > service.getGeertishetmoeserviceSOAP12PortHttp();
> >             // TODO initialize WS operation arguments here
> >             long s = id;
> >             port.operation1(s);
> >             port.operation2(s);
> >         } catch (Exception ex) {
> >             // TODO handle custom exceptions here
> >         }
> >
> > versus
> >
> >  try { // Call Web Service Operation
> >             slapen.Geertishetmoeservice service = new
> > slapen.Geertishetmoeservice();
> >             slapen.GeertishetmoeservicePortType port =
> > service.getGeertishetmoeserviceSOAP12PortHttp();
> >             // TODO initialize WS operation arguments here
> >             long s = id;
> >             port.operation1(s);
> >         } catch (Exception ex) {
> >             // TODO handle custom exceptions here
> >         }
> >
> >  try { // Call Web Service Operation
> >             slapen.Geertishetmoeservice service = new
> > slapen.Geertishetmoeservice();
> >             slapen.GeertishetmoeservicePortType port =
> > service.getGeertishetmoeserviceSOAP12PortHttp();
> >             // TODO initialize WS operation arguments here
> >             long s = id;
> >             port.operation2(s);
> >         } catch (Exception ex) {
> >             // TODO handle custom exceptions here
> >         }
> >
> >
> > Currently my process is not sending anything back, but I can detect the
> > process' behavior using the http://localhost:8080/ode/instances.html and
> > looking at which processes are active and completed.
> >
> > cheers
> > Geert
> >
> >
> > On Thu, Aug 5, 2010 at 14:03, Tammo van Lessen <tvanles...@gmail.com>
> wrote:
> >
> >> Hi Geert,
> >>
> >> first, what do you mean by session? And is your process sending
> >> something back to the client? Otherwise the client cannot be aware of a
> >> potential implicit correlation token. These guys are proprietary btw, so
> >> a client would need to explicitly extract them and include them in
> >> follow up messages.
> >>
> >> While looking at your code, I think at least Receive2 should have set
> >> createInstance to no. Maybe that solves already your issue.
> >>
> >> HTH,
> >>  Tammo
> >>
> >> On 05.08.2010 13:47, Geert Monsieur wrote:
> >>> Dear
> >>>
> >>> I'm deploying a simple BPEL process consisting of one flow which holds
> >>> two receive activities (createInstance=yes). I defined a property to
> >>> correlate message in the BPEL's WSDL file:
> >>>
> >>> <vprop:property name="testprop" type="xsd:long"/>
> >>>      <vprop:propertyAlias messageType="tns:operation1message" part="s"
> >>> propertyName="tns:testprop"/>
> >>>      <vprop:propertyAlias messageType="tns:operation2message" part="s"
> >>> propertyName="tns:testprop"/>
> >>>
> >>> In the BPEL process I've added a correlation set.
> >>>
> >>> <bpel:correlationSets>
> >>>         <bpel:correlationSet name="CorrelationSet"
> >>> properties="ns:testprop"></bpel:correlationSet>
> >>> </bpel:correlationSets>
> >>>
> >>> This correlation set is used together with the two receive activities.
> >>> initiate=join because I want the process instance to be continued
> >>> (=ended) when two correlated messages are received by the BPEL engine.
> >>>
> >>> <bpel:receive name="Receive1" partnerLink="client"
> >>> operation="operation1" portType="tns:geertishetmoe"
> variable="Variable1"
> >>> createInstance="yes" xmlns:tns="http://slapen";>
> >>>                 <bpel:correlations>
> >>>                     <bpel:correlation set="CorrelationSet"
> >>> initiate="join"></bpel:correlation>
> >>>                 </bpel:correlations>
> >>> </bpel:receive>
> >>>
> >>> <bpel:receive name="Receive2" partnerLink="client"
> >>> operation="operation2" portType="tns:geertishetmoe"
> variable="Variable2"
> >>> createInstance="yes" xmlns:tns="http://slapen";>
> >>>                 <bpel:correlations>
> >>>                     <bpel:correlation set="CorrelationSet"
> >>> initiate="join"></bpel:correlation>
> >>>                 </bpel:correlations>
> >>> </bpel:receive>
> >>>
> >>> When using operation 1 and operation 2 in one unique session,
> >>> correlation is working properly (probably because of the fact that
> ODE's
> >>> implicit correlation mechanism relies on the session id?). However,
> when
> >>> using operation 1 and operation 2 in two different sessions, ODE never
> >>> manages to correlate two messages containing the same id.
> >>>
> >>> Does this mean I'm not able to use the BPEL correlation mechanism? Or
> >>> what else can be wrong?
> >>>
> >>> Thanks in advance!
> >>>
> >>> In attachment you can find both my BPEL and corresponding WSDL file.
> >>>
> >>> Cheers
> >>>
> >>> Geert Monsieur
> >>>
> >>>
> >>
> >> --
> >> Tammo van Lessen - http://www.taval.de
> >>
> >
>
> --
> Tammo van Lessen - http://www.taval.de
>

Reply via email to