Parallel Forks and Parallel Processing
Dart, Jocelyn
jocelyn.dart at sap.com
Thu Mar 11 06:54:56 EST 2004
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
> =
> =
>
>
More information about the SAP-WUG
mailing list