Parrallel Forks and Parallel Processing

[Alon Raskin]

Hi Mike,
 
For the sake of the discussion lets call the sub-workflow that does the
processing WF A and the listening event sub-workflow is WF B.
 
Your first point is an excellent one. I don't really know why there is a
delay between the sub-workflows. WF B does not do any processing, all it
does is create a few parallel forks and listen for several events. The only
think I can speculate on is that perhaps our Testing environment hardware
does not have enough dialog processes available so the workflow has to wait
for a dialog process to become available before it can execute one of the
parallel branches. Does anyone know if this is a fair assumption or am I
being stupid? Does anyone know if parallel branches are executed in separate
system processes?
 
Interesting point on the event queue, may be worth a look. Not ideal but if
there are no other options....
 
Thanks again for your thoughts Mike, they are very much appreciated.
 
Regards,
 
Alon
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of
Michael Pokraka
Sent: 08 March 2004 18:12
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Parrallel Forks and Parallel Processing
 
Hi Alon,
I agree with you on the wait step - it also consumes unnecessary resources.
Two thoughts spring to mind:
 
- How come the branch that 'does some processing' completes before the first
one establishes it's wait status? OK, it's never guaranteed that less work
should arrive earlier but still it's a bit odd. Unless both flows do some
processing? In which case the design might profit from some more thought -
like how about putting the wait step into a new fork. I've had similar
issues
and managed to solve them by 'forking around' a bit.
 
- If you're using the event queue, try setting the instance linkage to queue
the event. This will incur an automatic delay without extra coding.
 
- If the 'does some processing' part is custom, maybe a WAIT statement in
the
code is less conspicuous than a wait step in the workflow (clutching at
straws)
 
OK, those were three thoughts, so I was mistaken...
Cheers
Mike
 
 
Alon Raskin wrote:
> 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
>
>