John, This will be getting hard to follow but my reply is inlined. Thanks again.
>>>> 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". Well, let's look around line 251 of activeparticipant.rb in reply method. The Engine reply method is overloaded. It does an "oldreply' and destroys the workitem. Densha thinks everything went fine and tells the user that the workitem was proceeded when it was a ctually deleted from the database. No potential replay possible. >>> 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. Why are you saying that? I am not using any thread but trying to use the worklist. > >> 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. I am trying to! > >>> 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). Participant is busy sending out 200 messages while the responses start coming back. If the workitems are not queued, what happens? >>> 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. I can do that. But then, I am not really calling back my participant but another one. This feels a little clunky but easily doable. >>>> 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 ? I do not know. I do not see any printouts from my participant so it does not appear to have been invoked (was busy). > >> 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 It would be more elegant if a workitem could get back to P asynchronously. You only need a message queue that P could be going back to when available (like the sqs) > 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/so > cketlisteners.rb > I am very familiar with those examples. > 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). Thanks but I can handle this if this is what needs to be done. I still thinks that replying to an activity ought to be implemented within the engine itself. It has a queue capability after all. No need to rush in this just an idea for future :) Thanks again for all your help, V/R, Pat. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
