Parallel Forks and Parallel Processing

[Michael Pokraka]

Hi Alon,
Good point about the testing hardware - yes, starting a workflow does use=
 up a
dialog process. However that still means that this can happen in prod as =
well
if the system is busy.
In addition to the other excellent suggestions, can you not move the wait
event out of the subflow and into a subfork of the main flow's B-branch?
 
Branch A                 Branch B
  |                       /    \
Start WF          subfork 1    subfork 2
             listen for event  Start WF B
 
('drawn' in fixed-pitch font)
 
Cheers
Mike
 
Alon Raskin wrote:
> 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 N=
at 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>                                         Subj=
ect
>                                        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 r=
eason
> we are listening for an event in fork B is because the event can be rai=
sed
> 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 N=
at 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 co=
rrect
> we have changed our workflow because of technical limitations.
>
> Alon what I do not understand about your design is why parallel forks w=
hen
> it seems to me that an activity B in fork B is waiting for activity A i=
n
> 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 wou=
ld
> check the result of activity A and created the activity B in the approp=
riate
> 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>                                         Subj=
ect
>                                        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 paral=
lel
> fork. One of the sub-workflows does some processing and raises an event=
 .
> The second sub-workflow needs to trap that event and handle appropriate=
ly.
> It seems that the sencond sub-workflow is missing the event being raise=
d
> 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 ra=
ise
> 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 thought=
s and
> possible solutions.
>
> Regards,
>
> Alon
> =3D
> =3D
>
>