Hi John, thank you for your fast response ! Your response improve my understandig of OpenWFEru but I have some additional questions.
>>Well, it dispatches the workitem to the queue and then, the job is >>over, until the workitem comes back from the queue or from somewhere >>else If an external application read the workitem from the queue what does it mean for this application to implement ... until the workitem comes back from the queue ... --> What does it mean (without using SqsListner ) ? Is it possible to give a short explanation. >>>Most of the time, there is a one to one relation, one participant >>>dispatches a workitem, and it somehow comes back via a listener. The >>>participant is sometimes passed a 'timeout'. >>>The 'listen' expression is about tying listening behaviours to do >>>cross process instance tricks. I think this 'listen' expression is >>>close to the BPEL "receive activity" thing. Does it mean that there is no way to have a "receive only" participant ? Potentially this is related to the problem: How do you define the enty point in a running process instance ? This is not really a problem but it could be a source for confusion. >From my point of view it could be better to make some small syntax changes to describe more intentionally in which way the communication between the engine an the participant should be performed. Somethink like: concurrence do participant :alice, :listen participant :bob, :call participant :alpha :send end ------------------------------- :listen, :call, :send are values for a standar parameter which defaults to :call (asynchron request/response ) - :call correspond to the current standard notation - :send correspond to forget - :listen is from implementation point of view the same as :call but the only meaningfull infos which are needed from workitem is the "flow expression id" . :listen, :call, :send are only examples for possible values. What do you think ? Best regards, Andreas On 23 Okt., 02:05, "John Mettraux" <[EMAIL PROTECTED]> wrote: > Hi Andreas, > > On 10/23/07, andreas <[EMAIL PROTECTED]> wrote: > > > > > Hallo, > > > at first, OpenWFEru looks very interessting for me !!! > > > I'm not completely new to the BPM topic. In the past I' was working > > with a BPMS from Intalio. > > Welcome on board, thanks ! Your BPEL knowledge is visible throughout > your questions. > > > I have tested some small examples and it was OK. After that I tried to > > expand the example using SqsParticipant. > > I read the documentation and inspecting the implementation scope and > > was expecting that a SqsParticipant behaves like the "fire and forget" > > pattern. In my tests the process (or workflow) works like expected as > > long as it arrive the SqsParticipant 'statement'. The SqsParticipant > > send a message to the queue -- this was OK, but after that the process > > execution "hang". It looks like the SqsParticipant is waiting for > > something ? > > Well, it dispatches the workitem to the queue and then, the job is > over, until the workitem comes back from the queue or from somewhere > else (some listener). > > > This is not described in the documentation. What sould be done to > > enforce the SqsParticipant to give the control back to the engine. > > forget do > participant :sqsparticipant > end > > or > > participant :sqsparticipant, :forget => true > > The flow continues without bothering about any replies for the > participant expression. > > > It would be also very interesting to have more information in detail > > about the magic which is performed by the engine exspecially because > > of potential some implicit activities. > > It would help me if you had specific questions, currently my day job > prevents from writing detailed documentation, but I take care of > writing documentation for all the features/elements added. > > Questions are good but they help me figure out how the engine is perceived. > > > After that problems I define a SqsListner which was listening to the > > queue which was also used by the SqsParticipant. The SqsListner was > > receiving a message and after that the SqsParticipant gave back the > > control and the excepted flow was executed. > > > This "correlation" is could not be found if you look in the > > implementation code of both classes. > > The correlation is done via the "flow expression id" of the workitem. > > A process definition, when parsed by the engine, is turned into a tree > of expressions. Each expression has its own "flow expression id". When > a participant dispatches a workitem [outside of the realm of the > engine], it makes sure to tag it with its own "flow expression id". > > When the workitem comes back (in that 'external' case, via a > listener), the "flow expression id" is used to look up the flow > expression (instance of ParticipantExpression) and 'reply' with the > potentially modified workitem. > > Each expression has two main methods, 'apply' and 'reply' it also has > children expressions (linked via their 'flow expression id' and a link > to an environment (scope for variables). > > The engine, when launching a process definition, simply applies the > root expression, which will apply its children expressions as needed. > A process instance terminates when the reply method of the root > expression is called. > > > Is it possible to enforce the SqsParticipant to give the control back > > to the engine without using SqsListner ? > > Yes, with the forget attribute or the forget expression as mentioned above. > > > Is there a way to define a "receive activity" in the process > > definition using the defined SqsListner (the listen expression is only > > listening to a participant) ? > > Most of the time, there is a one to one relation, one participant > dispatches a workitem, and it somehow comes back via a listener. The > participant is sometimes passed a 'timeout'. > > The 'listen' expression is about tying listening behaviours to do > cross process instance tricks. I think this 'listen' expression is > close to the BPEL "receive activity" thing. > > > In the documentation you can read: > > > "A listener allows InFlowWorkItems to resume back in their originating > > process instance. " > > > ==> but at which location in the process definition ??? > > The location defined by the 'flow expression id'. > > > The general relation between Participant and Listner in detail needs a > > little bit more clarification ( I have some ideas but I'm not sure > > abaout the details ). > > > Potentially some UML sequence diagramms could supply some information. > > I can create such diagrams if I have enough background information. > > I'll gladly supply any required information via this mailing list. > > In order to make the engine more grokkable by Ruby developers I > focused on things like block participants > > ( > engine.register_participant :toto do |workitem| > puts "hello world !" > end > ) > > and somehow neglected the participant/listener advanced subjects. > > > Some more complex examples could be also a good thing. > > Yes, I was planning to writing one complex example, but my schedule > did not allow it. > > Some more documentation : > > http://jmettraux.wordpress.com/2007/09/24/reply-there/http://jmettraux.wordpress.com/2007/05/29/listen/ > > Best regards, your questions are welcome, > > -- > 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 -~----------~----~----~----~------~----~------~--~---
