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

Sat Nov 12 14:13:56 EST 2005

Not a bad idea, but right off the bat I don't think it solves the 
problem, because I would basically just move it somewhere else. 

I think the core of my problem is that I want to have a dynamic and 
changeable number of parallell branches, in essence a dynamic fork
(requiring all branches to complete), where new branches can be added
without touching the existing branches. Otherwise it can be solved by
using dynamic parallell processing.
Basically I want an even more dynamic parallell processing solution.

I was probably too brief in my explanation as well, but a picture or 
ten should make the design a little clearer. The initial workflow is 
not of interest for this problem. What you can see in the "Approve 
document" workflow is that I have three parallell branches. The two 
rightmost ones are endless loops. The rightmost one is in the -02 
picture, while the leftmost one is in the -01 picture.

So, whenever it is detected by the middle branch that there has been a 
change in responsibility, a "ReportTo" event should occur. This is 
also true for the initial reporting. The left branch waits for the 
workflows which report the document to a specific approving object to
complete. Thus I can't simply finish the Repord document flows by 
publishing events, because then the left branch will complete. 
Catch 22 again!

To make things worse I would prefer that the workflow log is readable, 
by having all the "Report document" workflows at the same level and by 
hiding a lot of the steps from the ActiveX version of the log.

The simplest solution is to use a triggering event for the workflow, 
but then the workflow log will be less interesting as it will not be 
possible to see the rejections and read the notes that are associated 
with the rejections.

I suppose I will have to resort to a dirty trick - modifying the 
container to add a dummy element to the list of approvers, stopping 
and starting workflows and then removing the dummy element again.
-- 
Kjetil Kilhavn, Statoil ØFT KTJ ITS BKS SAP Basis 

> -----Original Message-----
> From: sap-wug-bounces at mit.edu 
> [mailto:sap-wug-bounces at mit.edu] On Behalf Of Flavio Oliveira
> Sent: 12. november 2005 18:32
> To: sap-wug at mit.edu
> Subject: RE: One more thing: Start workflow in background 
> without using event - is it possible (R/3 ver 46C)
> 
> 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
> 
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> 

-------------------------------------------------------------------
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Workflow - approve document.png
Type: image/png
Size: 13539 bytes
Desc: Workflow - approve document.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20051112/62e5f8c6/attachment.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Workflow - approve document-01.png
Type: image/png
Size: 11666 bytes
Desc: Workflow - approve document-01.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20051112/62e5f8c6/attachment-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Workflow - approve document-02.png
Type: image/png
Size: 7126 bytes
Desc: Workflow - approve document-02.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20051112/62e5f8c6/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Workflow - report document.png
Type: image/png
Size: 23895 bytes
Desc: Workflow - report document.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20051112/62e5f8c6/attachment-0003.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Workflow Log - multiple responsible objects.png
Type: image/png
Size: 21950 bytes
Desc: Workflow Log - multiple responsible objects.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20051112/62e5f8c6/attachment-0004.png