Parallel Forks and Parallel Processing

[Alon Raskin]

Hi Nat,
 
Thanks for your suggestion. The end condition is correct due to other
external interactions that can occur.
 
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 Nat 4
Govender
Sent: Tuesday, March 09, 2004 7:51 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Parallel Forks and Parallel Processing
 
Hi Alon,
 
In your parallel forks how many of the legs must end is it, one of two
assuming that there are only two legs or two of two.
Based on what you said I am assuming that you have two of two therefore your
workflow is not completing.
If the activity  in fork A is completed then the workflow must end.
Please check your end condition for your parallel forks.
 
 
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 3i-consu
             lting.com>                                                 To
             Sent by: SAP              SAP-WUG at MITVMA.MIT.EDU
             Workflow                                                   cc
             <Owner-SAP-WUG at MI
             TVMA.MIT.EDU>                                         Subject
                                       Re: Parallel Forks and Parallel
                                       Processing
             2004/03/09 08:38
             AM
 
 
             Please respond to
               SAP Workflow
               Users' Group
             <SAP-WUG at MITVMA.M
                  IT.EDU>
 
 
 
 
 
 
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
=
=