One more thing: Start workflow in background without using event - is it possible (R/3 ver 46C)
Dart, Jocelyn
jocelyn.dart at sap.com
Mon Nov 14 03:50:16 EST 2005
Kjetil,
Yes - SRM exploits ad hoc anchors programmatically.
Re viewing the rejection - so long as all of your workflows are linked to the Requisition object so that they show in Generic Object Services you could use that to see who has the rejection.
So far as displaying the requisition the same applies - you just need the link to the Requisition object.
Getting a complete overview of the approval process would require some thought and careful tailoring of the log information displayed - but that's why of course you really want ad hoc anchors.
Regards,
Jocelyn Dart
Senior Consultant
SAP Australia Pty Ltd.
Level 1/168 Walker St.
North Sydney
NSW, 2060
Australia
T +61 412 390 267
M + 61 412 390 267
E jocelyn.dart at sap.com
http://www.sap.com
The information contained in or attached to this electronic transmission is confidential and may be legally privileged. It is intended only for the person or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any distribution, copying, review, retransmission, dissemination or other use of this electronic transmission or the information contained in it is strictly prohibited. If you have received this electronic transmission in error, please immediately contact the sender to arrange for the return of the original documents.
Electronic transmission cannot be guaranteed to be secure and accordingly, the sender does not accept liability for any such data corruption, interception, unauthorized amendment, viruses, delays or the consequences thereof.
Any views expressed in this electronic transmission are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of SAP AG or any of its subsidiaries. SAP AG, its subsidiaries, and their directors, officers and employees make no representation nor accept any liability for the accuracy or completeness of the views or information contained herein. Please be aware that the furnishing of any pricing information/ business proposal herein is indicative only, is subject to change and shall not be construed as an offer or as constituting a binding agreement on the part of SAP AG or any of its subsidiaries to enter into any relationship, unless otherwise expressly stated.
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Kjetil Kilhavn
Sent: Monday, 14 November 2005 6:45 PM
To: SAP Workflow Users' Group
Subject: RE: One more thing: Start workflow in background without using event - is it possible (R/3 ver 46C)
Too late.... At 2:30 AM on Sunday I had a new solution in QA. I slept well when I got home.
To my knowledge the responsibilities are not changed too often, so I think it is acceptable that the logs will display multiple reporting entries if that happens.
I think your suggestion suffers from the same problem as Flavios suggestion. I wouldn't be able to display a purchase requisition, look at workflow overview and follow the complete approval process. With the solution I have, if the document is rejected I can see who has that rejection for processing. I wouldn't be able too if I did what you suggested (or would I?).
With regards to the ad hoc anchor - is that something one can exploit programatically? I noticed your mentioning of them in another post and it seemed they are more of a manual thing. I suppose I will learn all about it in a couple of years.
--
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 Dart, Jocelyn
> Sent: 14. november 2005 02:20
> To: SAP Workflow Users' Group
> Subject: RE: One more thing: Start workflow in background
> without using event - is it possible (R/3 ver 46C)
>
> Kjetil,
> Too bad you are in 4.6C. Sounds exactly like an ad hoc
> anchor step scenario - but that's 6.10 and above.
>
> All I can think of is to possibly implement your subflows as
> separate workflows - passing the main work item id of the
> main workflow, and then have them pass back their results to
> the main workflow, e.g. via a custom event.
>
>
> Regards,
> Jocelyn Dart
> Senior Consultant
> SAP Australia Pty Ltd.
> Level 1/168 Walker St.
> North Sydney
> NSW, 2060
> Australia
> T +61 412 390 267
> M + 61 412 390 267
> E jocelyn.dart at sap.com
> http://www.sap.com
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu] On Behalf Of Kjetil Kilhavn
> Sent: Sunday, 13 November 2005 6:14 AM
> To: SAP Workflow Users' Group
> Subject: RE: One more thing: Start workflow in background
> without using event - is it possible (R/3 ver 46C)
>
> 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
More information about the SAP-WUG
mailing list