Runtime Parallelism in Fork?

[Mark Huffman]

Stephan,
 
Thanks for your reply - looks like we will eventually get into event
driven processing on this one.
 
The workflow runs in a call center environment where after some initial
screen handling a whole set of business object create steps run and then
there is contact log screen handling. Remember all of this is suppposed
to run in a minute or so, so there is no inbox handling - and therein
lies the problem. All the bus obj create steps are defined as
synchronous but not dialog and also not as background, so that that any
follow-on steps in the workflow appear on the screen and are not sent to
the inbox. To my knowledge that is a 4.0B specific problem and in 4.6
there is a task or method level flag that specifies this behavior.
 
So, as far as I have been able to test, any parallel processing (both
fork and table-driven)doesn't really work when the WIs are defined this
way. The parallel paths are called as they should be, but run
sequentially instead. If some of the workitems are defined instead as
dialog, then the parallel paths run as they should because in each path,
the immediate flow to the next WI has been broken and the workflow
engine is able to kick off the next parallel path in the sequence.
 
(I can hear Alan Hans laughing heartily in the background - hello Alan
how ya doing?)
 
Anyway, the parallel creates of different business objects was kind of a
nice to have, not a show-stopper.
 
Thanks,
 
Mark
 
Stephan Becker wrote:
>
> 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