One more thing: Start workflow in background without using event - is it possible (R/3 ver 46C)

[Flavio Oliveira]

What if you put your event listener inside your subflow, not on the main 
flow. So, when something changes, the subflow will finishes and the main 
flow will be called again.

You can have a container element (if necessary) to tell you how the sublow 
has finished (because of the process completion or because of any change).

Then your main flow can reevaluate again and start another subflow if 
necessary.

I do not know if this can solve your problem, but is what I could think 
about...

Flavio.


>From: "Kjetil Kilhavn" <KJETILK at statoil.com>
>Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>To: "SAP Workflow User's Group" <sap-wug at mit.edu>
>Subject: One more thing: Start workflow in background without using event - 
>is it possible (R/3 ver 46C)
>Date: Sat, 12 Nov 2005 17:25:40 +0100
>
>Before I changed it to parallell processing I tried another obvious
>solution, using a starting event on the subworkflow. Then the loop
>could just create the event and continue and get back to the wait step
>again. There was only one catch, and it was catch 22. With that
>solution I lost the possibility to look at the approval process from
>the Generic Object Services of the document, because the workflows
>that were started by the events weren't available in the log of the
>main workflow.
>--
>Kjetil Kilhavn, Statoil ØFT KTJ ITS BKS SAP Basis
>
>
> > From: Kjetil Kilhavn
> > Sent: 12. november 2005 17:08
> > To: SAP Workflow User's Group
> > Subject: Start workflow in background without using event - is it 
>possible (R/3 ver 46C)
> >
> > I think I have come across a real show-stopper in the new approval
> > solution I am working on. Since I have now been twisting my head for
> > hours, trying to change the solution to parallell processing and
> > realising that that won't work either I now hope someone reads this
> > message has a brilliant idea. Otherwise it is probably time to go
> > back to the design stage again.
> >
> > One basic idea behind the solution was that workflows should not be
> > stopped unless it was necessary (so attachments would be available),
> > and therefore the design was created so it would listen for
> > significant events and then do what should be done before it went
> > back to listening again.
> >
> > In the design I have a workflow which is started per document. This
> > workflow has to be created for each document type (requisition,
> > order, service entry and so on). It evaluates the document and
> > decides if it is ready and needs to be approved at all. If approval
> > is required a generic subworkflow for approval is started.
> >
> > The workflow for approval finds out which objects are responsible
> > for approval and creates one event for each such responsible object.
> > This event is captured in a parellell branch which listens for the
> > event, starts a subworkflow and loops back to listen for the event.
> > However - and I could kick myself for not thinking about this before
> > now - when the subworkflow is started the main workflow waits for it
> > to complete. So when the document is changed and there is another
> > approver in addition to the original one, there is no-one listening
> > for the event because the loop hasn't completed its circle!
> >
> > What I need is a multistep task that can be started in background so
> > the flow continues. As far as I can see there is no such thing, at
> > least in version 4.6C.
> > I've been thinking about ways to circumvent the problem, e.g. having
> > a parallell branch that completes after a minute, but that will only
> > cause the subworkflow to be killed when the other branch completes.
> >
> > I just changed it to a parallell processing step so all the
> > subworkflows can be started in parallell when there are multiple
> > approvers at first, but that doesn't solve the real problem which is
> > related to changes. I'm being driven back inch by inch and it is
> > rather depressing....
> >
> > Right now I only see one solution: if there are any changes in
> > responsibility, kill all the active subworkflows and start new ones.
> > I'm hoping someone else sees a better solution.
> > --
> > Kjetil Kilhavn, Statoil ØFT KTJ ITS BKS SAP Basis
>
>
>-------------------------------------------------------------------
>The information contained in this message may be CONFIDENTIAL and is
>intended for the addressee only. Any unauthorised use, dissemination of the
>information or copying of this message is prohibited. If you are not the
>addressee, please notify the sender immediately by return e-mail and delete
>this message.
>Thank you.
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug