Parallel Forks and Parallel Processing

[Alon Raskin]

Hi Nat,
 
The reason we have gone with this approach are fairly complex but the reason
we are listening for an event in fork B is because the event can be raised
from fork A as well as from an external transaction at any point in the
workflow. Hence we always want to listen for the event (event after
processing in WF A is complete).
 
Regards,
 
Alon
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Nat 4
Govender
Sent: 09 March 2004 05:20
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Parallel Forks and Parallel Processing
 
Hi Alon,
 
We had a similar problem and we added the wait step, however you are
correct we have changed our workflow because of technical limitations.
 
Alon what I do not understand about your design is why parallel forks when
it seems to me that an activity B in fork B is waiting for activity A in
fork A to raise and event for activity B to do something.  I would not have
had parallel forks at all but created a check after activity A that would
check the result of activity A and created the activity B in the
appropriate leg of the check.
 
 
 
Regards
Nat Govender
Toyota South Africa
SAP Support  - SAP Workflow
Ext.              : 32645
Direct Line : 031 - 910 2645
Fax              : 031 - 902 9633
E-Mail         : ngovender4 at toyota.co.za
 
 
 
 
 
             Alon Raskin
             <araskin at eOutlook
             .com>                                                      To
             Sent by: SAP              SAP-WUG at MITVMA.MIT.EDU
             Workflow                                                   cc
             <Owner-SAP-WUG at MI
             TVMA.MIT.EDU>                                         Subject
                                       Parrallel Forks and Parallel
                                       Processing
             2004/03/08 06:16
             PM
 
 
             Please respond to
               "SAP Workflow
               Users' Group"
             <SAP-WUG at MITVMA.M
                  IT.EDU>
 
 
 
 
 
 
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
=