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
