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
-~----------~----~----~----~------~----~------~--~---
