Hi Pat, start reading at the bottom.
On 9/22/07, Patrice Cappelaere <[EMAIL PROTECTED]> wrote: > > > > >> I get "workitem got proceeded" back and workitem is deleted from db > >> but my participant never got called. > > One issue here is that the user thinks that the workitem was properly > handled but the engine ran into a problem and discarded the item. The engine does not discard workitem : the error is logged and also placed in the error journal for potiental "replay". > > Yes, your participant got called : it is an ActiveStoreParticipant > > (its workitem are visible in a store), it stored the workitem in a > > table, what else should it do ? > > At some point, a message comes back. The proper workitem needs to be > retrieved and removed from the queue. > The threading model is important to understand here. > If the participant instance is busy, the engine times out and > workitem is discarded. Well, it's your threading model, not the one of OpenWFEru. > In this case, I might need a new instance of that participant to > handle the message... You need a thread that receives the replies, fetches the workitem concerned and replies to the engine. The participant itself will just have received the workitem, in a thread piloted by the engine. Note that it's possible for the engine to dispatch and listen for workitems, but you have decided here to store the workitems in a database, that is a good idea. You want to implement something asynchronous then do it really asynchronous. > > OK, maybe you mean you have a participant that receives a workitem and > > stores it via OpenWFE::Extras::WorkItem and then does some work based > > on the info found in the workitem. When the work is done, it proceeds > > by itself. > > All of that should occur in the consume() method, not in the > > proceed/reply/forward one as you seem to expect. > > > > Participant does store the workitems and stores them via > OpenWFE::Extras::Workitem and then waits until those workitems have > been processed. > Part 2: SOAP messages targeted to that Participant/activity come > back. The application receives them. I was using densha to simulate > that and proceed the workitem via the worklist. This seems to be > flawed if participant is busy. > I might need to launch a new instance of it.... The participant is busy doing what ? It has its own thread for putting the workitem in the database and then maybe doing something else (if you have extended the class somehow). > > Another idea would be to have a vanilla ActiveStoreParticipant that > > stores incoming wi in store X and then an independent process Y that > > wakes up from time to time and consumes X. But well somehow, you're > > just replicating some of the process engine functionality. > > > > indeed. So it does no sound right but might be the solution. I think now that you need to extend ActiveStoreParticipant to store the workitem in database (a call to "super") and then trigger your SOAP / whatever message. Then you should have a process that listens for messages coming back, fetches the workitem implied and replies to the engine. > >> In log file I see: > >> OpenWFE::ExpressionPool 'expressionPool' - reply() to (fei > >> SPOT_Feasibilities 0.1 20070921-jimidomefu 0.0.0 participant) > >> OpenWFE::ExpressionPool 'expressionPool' - reply() from (fei > >> SPOT_Feasibilities 0.1 20070921-jimidomefu 0.0.0 participant) > >> OpenWFE::ParticipantExpression - unschedule_timeout() @timeout_job_id > >> is (oid 25070620) > >> > >> Does this mean that my participant did not respond because it was > >> busy > >> in a thread? > > > > It means that your participant replied, the engine resumed the flow. > > What is there after that participant ? (assuming it's a sequential > > execution). > > > > Well in this case, my participant never got the message and the > engine timed out. How could the engine then log that it got a reply from the participant then ? > This use-case really illustrates an activity sending a message out > and trying to get a response back somehow. this appears to be a > little trickier that I first thought. > I might really need 2 stores... The specifications seem to be : - participant P receives workitem w - P sends SOAP message/call based on w's data - process S receives SOAP message/call r - S recreates/retrieves workitem based on r's data - S replies to engine S is a listener somehow, P just does the dispatching, it's stateless, it just transforms the workitem into a SOAP call (see for example : http://openwferu.rubyforge.org/svn/trunk/openwfe-ruby/lib/openwfe/participants/soapparticipants.rb ) An example of listener : http://openwferu.rubyforge.org/svn/trunk/openwfe-ruby/lib/openwfe/listeners/socketlisteners.rb I could implement this pair for you, if you want, but my day job is really demanding these days (for instance, I am in the office right now). OK, best regards, -- John Mettraux -///- http://jmettraux.openwfe.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
