John, On Sep 22, 2007, at 6:53 AM, John Mettraux wrote:
> > On 9/22/07, cappelaere <[EMAIL PROTECTED]> wrote: >> >> John, >> >> I turned logging on :) so this helps a little...although I am seing >> various problems tha tmight be related. So let me go over my use- >> case. >> SPOT_Feasibilities worflow starts and has one participant with one >> activity (for now). >> SPOT_participant starts GetFeasibility activity and sends x messages >> out. It also creates x workitems. It now waits until the x >> workitems >> have been completed to relinquished control to engine and go to the >> next activity. I am not sending any messages right now and am only >> creating one workitem to test. >> >>> From Densha, I can see the workitem pending in the store. So for >> testing, I proceed the workitem. > > Proceeding the workitem implies that the 'worklist' replies to the > engine. > >> 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. > > 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. In this case, I might need a new instance of that participant to handle the message... > 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.... > 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. > >> 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. 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... Thanks again, 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 -~----------~----~----~----~------~----~------~--~---
