Hi, ok - thank for you help.
Peter On Fri, Sep 3, 2010 at 4:48 PM, Tammo van Lessen <[email protected]>wrote: > Hi Peter, > > for any type of correlation there is currently no integrated mechanism > to clean up unmatched messages. > > However, you can setup a cron job that executes a SQL script that > deletes such messages. Look for old messages in BPEL_UNMATCHED and > delete connected entries in BPEL_MESSAGE_EXCHANGE, BPEL_MESSAGE, > BPEL_UNMATCHED and LARGE_DATA. > > Hope that helps, > Tammo > > On Thu, Aug 26, 2010 at 09:48, Peter Lanser <[email protected]> > wrote: > > 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 <[email protected] > >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 > >> > > > > > > -- > Tammo van Lessen - [email protected] - http://www.taval.de >
