ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Lanser <lanser.pe...@gmail.com>
Subject Re: Correlation - invalid session identifier - no routing match
Date Thu, 26 Aug 2010 07:48:18 GMT
Hi Tammo,

first of all thanks for your answer and I'm really sorry for my late reply.

My aim is to assign an unique identifier for each conversation (ODE <--->
external service), whereby this unique ID should be generated by ODE. I
thought that instead of reinventing the wheel I could use those internal
tokens (although these session identifiers don't seem to bee unique per
call).

However, when using explicit correlation, I've got the same problem:
Messages which can't be routed to a workflow instance are not rejected with
a fault but saved to the DB. I've got the following setup with explicit
correlation:

<process>
...
<partnerLinks>
    <partnerLink xmlns:ns="http://myapp.com/" myRole="me" name="myApp"
partnerLinkType="ns:myApp" partnerRole="app"/>
</partnerLinks>
...
<correlationSets>
    <correlationSet name="myCorrelation" properties="tns:myCorrelation" />
</correlationSets>
...
<assign>
    <copy>
        <!-- ... some other initual input variables are initialized here ...
//-->
        <from><literal>myUniqueCorrelationString<literal></from>
        <to part="correlation" variable="initRequest"/>
    </copy>
</assign>
<invoke inputVariable="initRequest" operation="myOperation"
outputVariable="initResponse" partnerLink="myApp">
    <correlations>
        <correlation set="myCorrelation" initiate="yes" pattern="request"/>
    </correlations>
</invoke>
<pick>
    <onMessage operation="myCallback" partnerLink="myApp"
variable="callbackResponse">
    <correlations>
        <correlation set="myCorrelation" initiate="no"/>
    </correlations>
    ...
    </onMessage>
</pick>
...
</process>

The operation myOperation is a two-way operation. myCallback is one-way.

So when using explicit correlation - is there a way to reject callback
requests using an invalid correlation string?

BTW: In the above example I'm using "myUniqueCorrelationString". I always
tested this with $ode:pid. I saw that there's an issue for adding
ode:generate-guid() (or the like) which I think would fullfill my needs for
uniqueness per conversation [1].

Thanks for your help!

Peter

[1] https://issues.apache.org/jira/browse/ODE-839



On Fri, Aug 6, 2010 at 9:19 PM, Tammo van Lessen <tvanlessen@gmail.com>wrote:

> Hi Peter,
>
> no, these implicit correlation tokens are internally used like explicit
> correlation. Unmatched messages are queued for the case that the
> corresponding receive has not yet been activated. So it's currently not
> possible to reject such messages.
>
> What didn't work with explicit correlation in your case?
>
> Tammo
>
> On 04.08.2010 09:34, Peter Lanser wrote:
> > Hello,
> >
> > using Apache ODE 1.3.4 I need to implement an asynchronous call to an
> > external service. After hours of trial and error (and some code-lookup) I
> do
> > not use explicit correlation any more, but rather the external service is
> > setting the session ID within the SOAP header. Basically it works - all
> > messages are routed correctly. The only problem is that messges with an
> > invalid session identifier are not rejected by ODE. They are saved to the
> DB
> > instead. Within
> > org.apache.ode.bpel.engine.PartnerLinkMyRole#noRoutingMatch(...) the
> > incoming mex is tested whether it is asynchronous or not. Obviously i'm
> > reaching the synchronous branch...
> >
> > Is there a way to reject messages with an invalid session identifier?
> >
> > The asynchronous call looks something like this:
> >
> > ...
> > <partnerLink myRole="me" name="app" partnerLinkType="..."
> > partnerRole="app"/>
> > ...
> > <invoke inputVariable="request" operation="theOperation"
> > outputVariable="initResponse" partnerLink="app"/>
> > <pick>
> >   <onMessage operation="callback" partnerLink="app" variable="response">
> >   ...
> > </pick>
> > ...
> >
> > The operation invoked is a two-way operation. The callback operation is
> > one-way.
> >
> > Many thanks for your help!
> >
> > Peter
> >
>
> --
> Tammo van Lessen - http://www.taval.de
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message