Parallel Forks and Parallel Processing

[Alon Raskin]

Hi Mike,
=20
Good suggestion. Unfrotunately, due to other design considerations this =
can not be done.
=20
Thanks,
=20
Alon
 
________________________________
 
From: SAP Workflow on behalf of Michael Pokraka
Sent: Tue 09/03/2004 09:37
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Parallel Forks and Parallel Processing
 
 
 
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 =
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
> =3D
> =3D
>
>