PO approval workflow

Nicholas Brand nicholas.n.brand at uk.ibm.com
Fri Jul 29 07:54:51 EDT 2005





Mark, thanks for having a look.

I've actually 'resolved' the problem by:

- Writing a FM to query the event log table SWELOG and find the user who
last caused the 'RELEASESTEPCREATED' event to be triggered for the PO
- Creating a method that calls the function module
- Sticking the method in a task at the start of the workflow

This has stood up to testing and does the job.
So, although possibly not the ideal solution, given the limited time it was
the most expedient.

Thanks very much for all the advice that people gave.


Kind regards,
Nicholas Brand




                                                                           
             Mark Pyc                                                      
             <mark.pyc at gmail.c                                             
             om>                                                        To 
             Sent by:                  "SAP Workflow Users' Group"         
             sap-wug-bounces at m         <sap-wug at mit.edu>                   
             it.edu                                                     cc 
                                                                           
                                                                   Subject 
             28/07/2005 16:14          Re: PO approval workflow            
                                                                           
                                                                           
             Please respond to                                             
               "SAP Workflow                                               
               Users' Group"                                               
                                                                           
                                                                           




Well, with a few feeble tests in a 4.7/620 training system I can't
make it misbehave. Whatever is supplied as the event creator is what
appears in the Event trace and gets passed onto WF Initiator.

Have you tried the note Kjetil suggested??

On 7/28/05, Sushil Guragain <sguragain at interpublic.com> wrote:
> Hi Mark and Nicholas,
>
> I think what Mark stated on 2nd paragraph is what might be causing the
WF_INITIATOR to be different when you do it on test mode (SWDD). I have not
tested it either but if you test it please let me know what you find out.
>
> Thanks,
>
> Sushil
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Mark Pyc
> Sent: Wednesday, July 27, 2005 3:52 PM
> To: SAP Workflow Users' Group
> Subject: Re: PO approval workflow
>
> I'm not sure that you can say what was in _EVT_CREATOR based on what's in
the event log. One of the more annoying things in WF (of course there are
many) is that there is no way of knowing the contents of an event container
once that event has passed.
>
> I think the WF log would simply list SY-UNAME as the event creator which
is different to the container element _EVT_CREATOR which is
programmatically controllable.
>
> I can test this tomorrow, but maybe someone can already confirm?
>
> Have fun,
> Mark
>
> On 7/27/05, Nicholas Brand <nicholas.n.brand at uk.ibm.com> wrote:
> >
> >
> >
> >
> > Sushil,
> >
> > Thanks for passing on the relevant FM - they can be really time
> > consuming to locate.
> >
> > I've checked out the FM and it seems to be related to our problem.
> > The 'Releasestepcreated' event is raised by the FM with the creator =
> > creator of the PO The 'Significantlychanged' event is raised by the FM
> > with creator = SY-UNAME
> >
> > In fact it seems to show the cause of the issue.
> >
> > However, in the event log, against the event 'Releasestepcreated', the
> > event creator is shown and it's *not* the creator of the PO (as the
> > above FM seems to say) but the user who changed the PO and caused the
> > 'Releasestepcreated' event to be created for a second time against the
PO.
> >
> > No 'Significantlychanged' events were raised in this scenario.
> >
> > I'd have thought the workflow container element '_WF_INITIATOR' would
> > have the same value as the event container element '_EVT_CREATOR' (as
> > there's a direct binding between them) but it doesn't; instead the
> > workflow container element has the value of the user who created the PO
in the first place.
> >
> >
> > Kind regards,
> > Nicholas Brand
> >
> >
> >
> >
> >
> >             "Sushil Guragain"
> >             <sguragain at interp
> >             ublic.com>
To
> >             Sent by:                  "SAP Workflow Users' Group"
> >             sap-wug-bounces at m         <sap-wug at mit.edu>
> >             it.edu
cc
> >
> >
Subject
> >             27/07/2005 15:17          RE: PO approval workflow
> >
> >
> >             Please respond to
> >               "SAP Workflow
> >               Users' Group"
> >
> >
> >
> >
> >
> >
> > Hi Nicholas,
> >
> > I ran into the exact same issue earlier. It is going to use the PO
> > creator as WF_INITIATOR when triggering event RELEASESTEPCREATED is
> > used. But if you use triggering event SIGNIFICANTLYCHANGED, it uses
> > the person who changed the PO significantly.
> >
> > The FM ME_REL_EVENT_EKKO has details on what gets passed on these
events.
> > Again, thanks to Satish for pointing me to this FM.
> >
> > Thanks,
> >
> > Sushil
> >
> > -----Original Message-----
> > From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> > Behalf Of Nicholas Brand
> > Sent: Wednesday, July 27, 2005 6:40 AM
> > To: SAP Workflow Users' Group
> > Subject: Re: PO approval workflow
> >
> >
> >
> >
> >
> > Mark,
> >
> > Hi, the workflow was already in place - I've been called in to resolve
> > this issue.
> >
> > The SWETYPV entry uses Receiver FM 'SWW_WI_CREATE_VIA_EVENT' - so it's
> > standard.
> >
> > The triggering event for the workflow is 'RELEASESTEPCREATED' (not
> > 'significantlychanged' as in my original email).
> > A wait for event listens for the 'significantlychanged' event - if
> > this happens the workflow is terminated, and a new one triggered
> > through the new 'RELEASESTEPCREATED' event that is also raised by SAP
> > when a significant change is made to the PO.
> >
> > In SWUD, I've created the event 'RELEASESTEPCREATED' manually and the
> > event creator *is* passed correctly to the new workflow instance (the
> > old workflow instance had completed before I created the event
manually).
> >
> > So to summarise, if I create the event manually, the event creator is
> > passed into the workflow container and if SAP creates the event, the
> > workflow container value for _WF_INITIATOR is set to the user who
> > originally created the PO and not the one who created the new release
step.
> >
> >
> > Kind regards,
> > Nicholas Brand
> >
> >
> >
> >
> >
> >             Mark Pyc
> >             <mark.pyc at gmail.c
> >             om>
To
> >             Sent by:                  "SAP Workflow Users' Group"
> >             sap-wug-bounces at m         <sap-wug at mit.edu>
> >             it.edu
cc
> >
> >
Subject
> >             27/07/2005 09:00          Re: PO approval workflow
> >
> >
> >             Please respond to
> >               "SAP Workflow
> >               Users' Group"
> >
> >
> >
> >
> >
> >
> > G'day Nicholas,
> >
> > Is this a WF you've just developed or was it already in place on site?
> > Although I'm not sure why it would be but could this be intentional in
> > the development? Are the SWETYPV entries using the standard FMs?
> >
> > Have fun,
> > Mark
> >
> > On 7/27/05, Kjetil Kilhavn <KJETILK at statoil.com> wrote:
> > > Just to make sure it is as strange as it sounds: this happens when
> > > user C changes the PO significantly *after* the workflow has
> > > completed, so it is a _new_ workflow that is started when the change
> > > is
> > made?
> > >
> > > That does indeed sound strange, but if it was true that the function
> > > module has an error the same error should be observable for any type
> > > of document for which an event can be triggered multiple times. Not
> > > that I have tested this, but it seems strange that no-one has
> > > discovered it before so that it could be corrected. Have you tried
> > > to create the event manually with the workflow trace on (SWUD). Then
> > > you can see what goes on when the bindings are transferred.
> > >
> > > There are only seven OSS Notes for "WF_INITIATOR" - no such luck.
....
> > > But there are 20 for "_WF_INITIATOR" - that search engine makes me
> > > wonder.
> > >
> > > Note 497893 is relevant for 46C (but only up to SAPKB46C30 according
> > > to the note) and mentions a similar problem I guess, but it is for
> > > events created in a workflow, and that is probably not what happens
> > > here. You may want to have a look at it anyway.
> > > --
> > > Kjetil Kilhavn, Statoil KTJ IT BKS
> > >
> > >
> > > -----Original Message-----
> > > From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> > > Behalf Of Nicholas Brand
> > > Sent: 26. juli 2005 19:14
> > > To: sap-wug at mit.edu
> > > Subject: PO approval workflow
> > >
> > >
> > >
> > >
> > >
> > > A quick question...
> > >
> > > We have a PO approval workflow using business object BUS2012.
> > > It has one triggering event: 'SIGNIFICANTLYCHANGED'.
> > > The relevant binding between the event container and workflow
> > > container
> > > is:
> > > '_EVT_CREATOR' ==> '_WF_INITIATOR'
> > > Fairly standard.
> > >
> > > If User-A creates a PO it is workflowed to User-B for approval.
> > > In the event log and workflow log the event creator and workflow
> > > initiator are both shown as User-A.
> > > User-B approves and releases the PO and the workflow completes.
> > > This is all as it should be.
> > >
> > > Now, if User-C significantly changes the PO so that a new release
> > > strategy is required, the workflow is re-triggered.
> > > In the event log the event creator (for the new workflow) is
> > > correctly shown as User-C.
> > > In the workflow log you'd expect the workflow container element
> > > '_WF_INITIATOR' to be equal to the '_EVT_CREATOR' value (User-C) -
> > > but it ain't!
> > > Instead the workflow container element '_WF_INITIATOR' is still
> > > shown as User-A.
> > >
> > > In other words, the user who first creates the PO is entered in the
> > > workflow container element '_WF_INITIATOR' even for subsequent
> > > workflows against the same PO.
> > >
> > > At a guess it seems like an error in the function module that
> > > populates the _WF_INITIATOR workflow container element.
> > >
> > > Any clues out there? Is there an OSS note for this?
> > >
> > > BTW we're on v4.6c
> > >
> > >
> > > Kind regards,
> > > Nicholas Brand
> > >
> > > _______________________________________________
> > > 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.
> > >
> > > _______________________________________________
> > > 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
> >
> >
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> > This message contains information which may be confidential and
privileged.
> > Unless you are the intended recipient (or authorized to receive this
> > message for the intended recipient), you may not use, copy,
> > disseminate or disclose to anyone the message or any information
> > contained in the message.  If you have received the message in error,
> > please advise the sender by reply e-mail, and delete the message.
> > Thank you very much.
> > (A)
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> This message contains information which may be confidential and
privileged.
> Unless you are the intended recipient (or authorized to receive this
message
> for the intended recipient), you may not use, copy, disseminate or
disclose to
> anyone the message or any information contained in the message.  If you
have
> received the message in error, please advise the sender by reply e-mail,
and
> delete the message.  Thank you very much.
> (A)
>
> _______________________________________________
> 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




More information about the SAP-WUG mailing list