Runtime Parallelism in Fork?

Stephan Becker stephan.becker at walldorftech.com
Fri Jun 23 01:09:07 EDT 2000


Hi Mark,
 
in my experience, forks are parallel; I often use forks where I have one
waiting for an event, and another one doing the mainstream processing. Both
forks are active at the same time, the wait event sits there and at the same
time, the other fork goes forward.
 
Could you explain in a little more detail what you are seeing in the log,
maybe that will give us some more clues.
 
Greetings,
Stephan
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]On Behalf Of
Mark Huffman
Sent: 21 June 2000 00:01
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Runtime Parallelism in Fork?
 
 
Hello out there on the WUG,
 
I am on a 4.0B system, but am using the 4.6A online doco. The doco
describing Maintenance of Forks reads that the branches in
"the business process can be continued by several agents at the same
time", which seems to imply a parallelism in runtime.
 
We have a workflow with only two branches in the fork, both of which are
independent of each other and both have several steps that process
various business objects. However, the steplog reports that the workflow
actually waits for one branch to complete before processing the second,
so we don't actually end up with any time savings.
 
In the fork I have that two of two branches must be processed and the
fork condition is left blank.
 
A couple of questions:
 
A) Is there something that I am missing with the fork? What if you had
say 10 or more branches - would they still all be processed in serial?
Is it possible to put in some dummy branches, maybe with wait steps, to
force a parallel race, and change the fork end conditions?
 
 
B) In total for the workflow, if both branches actually ran in parallel,
we might save 25 - 30 seconds of runtime, which some people at the
client site think would be a good thing. If I set this up using the
table driven parallel processing do you think that the new overhead of
calling sub-workflows etc. will chew up any runtime advantage that the
the parallelism would provide?
 
Note -> I have used table driven parallel processing on a previous
project to good effect, but there the runtime was not a factor since
workitems were sent to inboxes anyway.
 
Mark
 


More information about the SAP-WUG mailing list