Parrallel Forks and Parallel Processing

[Alon Raskin]

Hi Robert,
 
I think I like your suggestion best. It is a good idea to check if the event
has already been raised before I 'wait for' . This seems most robust
approach to me.
 
The event can be raised by an external transaction as well as by one of the
sub-workflows. Trust me the modeling is right (its quite a complex
scenario), the problem is this 'unexplained delay' in one of the
sub-workflows...
 
Thanks again for your suggestion
 
Regards,
 
Alon Raskin
e: araskin at 3i-consulting.com
w: http://www.3i-consulting.com
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of
Robert.vande.Berg at nuon.com
Sent: Tuesday, March 09, 2004 8:07 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Parrallel Forks and Parallel Processing
 
Perhaps you could build-in a step that checks wether or not the event is
already raised before you set the 'wait-for-event' step. This way, you only
wait for the event if it isn't raised.
 
Or perhaps the event could be set to be queued in the eventque. This way,
you have a build-in delay.
 
If the first parallel fork always has to wait on the raised event in the
second fork, the obvious way to model your workflow should be that you raise
the event in the workflow after you set the 'wait-for-event' task.
 
Robert
-----Oorspronkelijk bericht-----
Van: Alon Raskin [mailto:araskin at eOutlook.com]
Verzonden: maandag 8 maart 2004 17:17
Aan: SAP-WUG at MITVMA.MIT.EDU
Onderwerp: Parrallel Forks and Parallel Processing
 
 
Hi All,
 
We have a situation where a workflow calls two sub-workflows in a parallel
fork. One of the sub-workflows does some processing and raises an event .
The second sub-workflow needs to trap that event and handle appropriately.
It seems that the sencond sub-workflow is missing the event being raised
because the first sub-workflow raises it before the second sub-workflow has
a chance to reach the 'wait for event' step.
 
I know the obvious solution is to put a wait step for a few seconds to make
sure that the listening sub-workflow is ready but I hate that approach
because it feels like the 'wait step' is required due to technical
limitations rather then a business requirements. I know I could also raise
an event when the listening sub-workflow is ready and only then process the
first sub-workflow but again this seems like modelling an event for the sake
of the technology rather then the business process.
 
Has anyone else experienced this issue? I would appreciate your thoughts and
possible solutions.
 
Regards,
 
Alon