Handeling locked objects during background steps in workflows.

[Workflow99@aol.com]

Elad,
 
What BAPI are you are using? BAPIs for some objects accept the Changed by
User as a parameter.
 
Ramki.
 
In a message dated 2/26/2004 1:37:47 AM Eastern Standard Time,
saarell at netvision.net.il writes:
Ramki,
I am using a BAPI to set the status,
I want the user to be able to approve or reject a project without accessing
the project through CJ20N.
 
Elad.
 
 
 
----- Original Message -----
From: <Workflow99 at aol.com>
To: <SAP-WUG at MITVMA.MIT.EDU>
Sent: Wednesday, February 25, 2004 11:19 PM
Subject: Re: Handeling locked objects during background steps in workflows.
 
 
> Elad,
>
> 1) I am not sure if an UNLOCKED event could be created for an object
(maybe
> possible via user exit). You could probably have the step in a loop until
it is
> successful but I do not think it is good design.
>
> 2) How are you updating the status of the project? I thought call
transaction
> for CJ20N is not possible?
>
> Regards,
> Ramki.
>
>
> In a message dated 2/25/2004 2:57:10 PM Eastern Standard Time,
> saarell at netvision.net.il writes:
> Hello,
> Thank you for your reply,
> but there are two main problems with the solution you've proposed :
> 1. This is not a fully automated solution, I can't rely on time interval
for
> re-executing the step in the case of a locked object (unlike other
exception
> situations).
> 2. My "background" step is not really a background step because I want the
> status to be set in the name of the current agent,
>     therefore it's like a "background" step on the client side.
>
> What do you think about the idea I wrote down ? do you think it's possible
?
> will it work ?
> Any other ideas ?
>
> Thank you,
> Elad.
>
> ----- Original Message -----
>> From: <Workflow99 at aol.com>
> To: <SAP-WUG at MITVMA.MIT.EDU>
> Sent: Wednesday, February 25, 2004 8:50 PM
> Subject: Re: Handeling locked objects during background steps in
workflows.
>
>
> > Elad,
> >
> > If your locking from WF fails, end the background method with a
temporary
> > exception and let the Worklfow system re execute it. If the lock is not
> resolved
> > after the specified number of tries, the WF will go to error status.
> >
> >
> > Regards,
> > Ramki Maley
> > Workflow Developer, USCBP.
> > 248-613-1287 (C)
> >
> > In a message dated 2/25/2004 1:33:32 PM Eastern Standard Time,
> > saarell at netvision.net.il writes:
> > Hello,
> > I have a workflow for projects approval.
> > The actual approval steps takes place while activating user\system
> statuses
> > of the project (Transaction CJ20N).
> > I use decision steps followed by background steps to set the status by
> ABAP
> > code,
> > this may cause problems when one user is working on the project using
the
> > CJ20N transaction, and the other user is using the decision step to
> approve the
> > project.
> > This situation may cause data\flow inconsistencies.
> >
> > How can I use the standard locking mechanism during the workflow to wait
> > until the project is unlocked and only then run my ABAP code to set the
> statuses?
> > I thought about placing a wait step right before a background (status
> change)
> > step, that will listen to an UNLOCK event of the project object, or
> something
> > like that,
> > Is there a better way to do that ? Is there a standard mechanism in the
> > workflow system that knows how to handle these kind of situations ?
> >
> > Thank you,
> > Elad.
 
Regards,
Ramki Maley
Workflow Developer, USCBP.
248-613-1287 (C)