Task locking fun fun fun....

[Weaver, Karen]

Jerry,
 
In your case, I would set a temporary error for your method when it find a
lockout situation.  When the job SWWERRE runs, it will pick up all tasks in
error and reprocess them.  I use this methodology and it works very well for
lockouts.
 
An example from our custom object for BUS2044.  Message 9001 is defined as a
temporary exception for the method.  Of course, for your object, you would
need to extend it and create a new method:
 
   CALL FUNCTION 'ENQUEUE_ECKEKOB'
        EXPORTING
             mode_keko_enque = 'E'
             mandt           = sy-mandt
             bzobj           = object-key-referenceobject
             kalnr           = object-key-costingnumber
             kalka           = object-key-costingtype
             kadky           = object-key-costingdate
             tvers           = object-key-costingversion
             bwvar           = object-key-valuationvariant
             kkzma           = object-key-enteredmanually
        EXCEPTIONS
             foreign_lock    = 1
             system_failure  = 2
             OTHERS          = 3.
 
   IF sy-subrc = 0.
     CALL FUNCTION 'DEQUEUE_ECKEKOB'
          EXPORTING
               mode_keko_enque = 'E'
               mandt           = sy-mandt
               bzobj           = object-key-referenceobject
               kalnr           = object-key-costingnumber
               kalka           = object-key-costingtype
               kadky           = object-key-costingdate
               tvers           = object-key-costingversion
               bwvar           = object-key-valuationvariant
               kkzma           = object-key-enteredmanually.
   ELSE.
     exit_return 9001 sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
   ENDIF.
 
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU]On Behalf Of
Martinek, Jerry
Sent: Wednesday, August 18, 2004 4:15 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Task locking fun fun fun....
 
 
Hi,
 
I'm curious to find out about the various techniques for implementing a wait
step. Are there any non-programmatic options?
 
Our custom ESS course approval workflow under certain conditions triggers a
locking/contention condition in the BAPI_BOOK_ATTENDANCE. Our current plan
is to introduce some kind of a wait step and then repeat the booking
process.
 
Regards,
Jerry Martinek
 
 
-----Original Message-----
From: David Weston [mailto:weston at clockwork.ca]
Sent: Wednesday, August 18, 2004 12:15 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Task locking fun fun fun....
 
Mike, how about another dummy step in between 1 and 2 that just waits a bit
?
The parked docs wf does this sort of thing.
 
Dave
 
Quoting Michael Pokraka <workflow at quirky.me.uk>:
 
> Hi folks,
> I've a situation which occurs in a variety of flows (4.7/620):
>
> Step 1 is executed, user does something which triggers wait for event
> elsewhere in the flow.
> Step 2 is a custom method and uses Advance with Dialog.
> Step 2 kicks in before the wait step gets the event and locks the task
>
> The end result: a workflow in status COMPLETED or CANCELLED and one step
in
> the middle somewhere in status STARTED.
>
> We've peppered the methods with lots of little WAIT statements, but I
don't
> like it one bit and doesn't always help: In some flows it's the other way
> around, the task that raises the event takes too long to complete and
> remains active at the point in time the WF is cancelled/completed. Thus
the
> user is returned to the inbox to find two identical tasks - one he just
> executed belonging to the now cancelled flow and one from the new
restarted
> one.
>
> Oh, the orphaned task completes itself during the next error monitoring
run
> within 20 min, but that's long enough to confuse people in between.
>
> Has anyone had any similar issues? Any suggestions?
>
> Cheers
> Mike
>
>
>