Parallel Forks and Parallel Processing
Alon Raskin
araskin at eOutlook.com
Thu Mar 11 08:54:40 EST 2004
Hi Jocelyn,
=20
Thanks very much for your reply.
=20
As Robert (and yourself) had suggested we will test for a value as well =
as 'look' for the event.
=20
Thanks everyone for their input.
=20
Alon=20
________________________________
From: SAP Workflow on behalf of Dart, Jocelyn
Sent: Thu 11/03/2004 11:54
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Parallel Forks and Parallel Processing
Hi Alon,
Is an event really the only option to find out if you can move forward?
Perhaps there is some value you can test as well as looking for the =
event. If you are in WAS system you could perhaps use a work item =
"before" condition to check for this.
Another option may be to add a parallel fork to the event-handling =
subflow that captures the event and sets a flag in the container. Your =
event handling then checks to see if the flag is set and only waits for =
the event if the flag is not yet set. Otherwise it can continue.
If you just want to add delay to the event you could also try using the =
event queue to deliver the event.
Jocelyn
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of =
Alon Raskin
Sent: Tuesday,9 March 2004 8:47 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Parallel Forks and Parallel Processing
Hi Mike,
Good suggestion. Unfrotunately, due to other design considerations this =
can not be done.
Thanks,
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
>
>
More information about the SAP-WUG
mailing list