Work Item Stalled (Another one today!)

[Mark Huffman]

I think that this is sound advice and should probably be in everybody's
bag of tricks. As I said last week, I have come around to the viewpoint
where I don't like to use the Method exception handling and instead trap
any errors within the method and report them back to the workflow level.
Then you can notify any front line users and also send something
meaningful off to a production support team. So the workflow itself
hopefully never goes into error status.
 
Another trick for complex workflows and (sounds like you may have one
with lots of sub-flows)is to maintain a status table where bascially one
row per workflow gets written to as objects are created or updated.
While this approach has its pros and cons, one clear advantage is that
you can include logic so that if the workflow is called again with the
key(s) of the table, it checks the status table and doesn't redo
anything that it has successfully already done. So in your case if it
stalls out in a sub-workflow somewhere, you run it again and it should
pick up again in that path at that step (of course the original workflow
would eventually have to be set to logicaly deleted by somebody since
you don't want it to be resurrected).
 
You can also do reporting against the table to figure out what the
workflow did before it died. Instead of sifting through the step logs -
which tends to get tedious with many workflows and also may not be the
right reporting  tool in the hands of front line users.
 
One disadvantage to this restart approach is that if your initial
workflow is supposed to report back to some sort of Front Office or
other Internet call etc. then you lose context with that old call.
 
I have used this status approach now on two major projects and I think
under the correct circumstances that it provides some advantages. Any
comments from out there on the WUG?
 
 
 
Van der Burg, Jeroen JA SI-PSTP-L wrote:
>
> Tammy,
>
> As your first problem only seems to occur occasionally; I would look into
> the locking/unlocking of your table when changing it through your method/FM,
> and especially what happens with the function module when the table is
> locked and the database can not be updated.
>
> Do a bit of testing on your FM while locking the record which is to be
> changed at the same time, and see what your FM returns to your object
> method, or just build in a general exception in your FM when SY-SUBRC ne 0
> and capture that in your FM call from the object method.
>
> If this is indeed the problem then build in correct error handling. What I
> do for situations like this is build in a loop and a wait step in the
> workflow process, which will retry the operation after 10 minutes or so.
> Never had a problem with that, although foreground steps need clear
> descriptions when doing so to avoid user confusion.
>
> Hope this helps,
>
> Jeroen
>
> -----Original Message-----
>> From: STARK,TAMMY (HP-Roseville,ex1) [mailto:tammy_stark at hp.com]
> Sent: Saturday, 22 July 2000 4:37
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Work Item Stalled (Another one today!)
>
> Hello Again!
>
> Well I read all of your suggestions and none have helped yet.  Let me try to
> give you more info.
>
> The workflow that is stalled is a sub-workflow (not a single step task).
> The first step in this sub-workflow is a single step task that runs in the
> background, calls a customer defined method and function module to change a
> table.  This is a very simple method.  This single step task has not yet
> executed.  Basically you are looking at a sub-workflow that gets triggerred,
> but the first step is not starting.  This particular workflow gets called
> many, many times a day and does not always error out.  In fact it has been
> approximately two months since I have had this problem and I am not even
> sure if it was at this same point in the Workflow last time.  This problem
> happens in other steps of my workflows.  It does not discriminate.  Note:
> There is another sub-workflow that gets called just before this one, and it
> completed successfully.
>
> I have another workflow that is stalled as of 9:00 am this morning.  Here's
> the scenario on that one.  The user executed a work item (User Decision
> step).  The next step in the workflow never appeared.  I took a look at it
> and the workflow log and found that it was in an error status.  I corrected
> the error (Restart After Error) and everything looked good.  But, the next
> work item is still not showing up in the user's workflow inbox.  The User
> Decision is the first step within a sub-workflow, and is completed (the user
> made a decision).  The second step within this sup-workflow, which is a
> container operation is not starting.  This is where it is stalled.
>
> Two very different examples with the same problem.  (SM58 still shows
> nothing and the RSWWERRE is not catching anything).
>
> Hope this helps.  Anymore ideas?  Thanks a 1,000,000!!!
>
> Best Regards,
>
> Tammy Stark
> Information Technology Engineer
> Hewlett Packard, Business Critical Computing - IT
> Voice mail: 916-748-2170
> tammy_stark at am.exch.hp.com
>
> -----Original Message-----
>> From: Mark Huffman [mailto:m.r.huffman at worldnet.att.net]
> Sent: Friday, July 21, 2000 11:12 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Work Item Stalled
>
> Just a follow-on here - I think Jeroen is quite right that this could be
> a potential problem.
>
> A few months back Stefan Becker commented that he always explicitly
> models error handling within the graphical workflow and avoids using
> exceptions. Since reading that, I have been doing this as well, so in an
> error case, the workitem always completes and you can review any error
> codes or text returned. In general this takes a bit more homework - for
> example BAPI return codes are not uniform - but I think that it pays
> dividends in the long run.
>
> Van der Burg, Jeroen JA SI-PSTP-L wrote:
> >
> > Hi Tammy,
> >
> > Situations in which I have come across this problem is incorrect error
> > handling, especially when the object method calls a function module. If
> your
> > function module has changed in 45b, and the exception is not properly
> > recognised within your object method (is this a custom one?), the result
> is
> > a short dump which can not be resolved by the workflow system. This
> results
> > in your background task not calling it's terminating event but just
> hanging
> > in there, just as you described it.
> >
> > Easy way out (if this is your problem) is returning the exception to your
> > object method using the exception statement of the function module call
> but
> > not processing it further, or - if required - set up correct event
> > processing for the exception. Need some more info though to make sure this
> > is indeed your problem.
> >
> > Good luck!
> >
> > Jeroen van der Burg
> >
> > -----Original Message-----
> > From: STARK,TAMMY (HP-Roseville,ex1) [mailto:tammy_stark at hp.com]
> > Sent: Friday, 21 July 2000 9:22
> > To: SAP-WUG at MITVMA.MIT.EDU
> > Subject: Re: Work Item Stalled
> >
> > Thanks Mark.  I will keep checking this out.  I can try changing the
> > workflow, but seems kinda strange because this workflow (and the
> background
> > task) has been in production for three years.  It has only been since we
> > upgraded to 4.5B that I have had this problem.  It doesn't happen very
> > often.
> >
> > P.S. Roseville is near Sacarmento.
> >
> > Tammy Stark
> > Information Technology Engineer
> > Hewlett Packard, Business Critical Computing - IT
> > Voice mail: 916-748-2170
> > tammy_stark at am.exch.hp.com
> >
> > -----Original Message-----
> > From: Mark Huffman [mailto:m.r.huffman at worldnet.att.net]
> > Sent: Thursday, July 20, 2000 4:21 PM
> > To: SAP-WUG at MITVMA.MIT.EDU
> > Subject: Re: Work Item Stalled
> >
> > Since what i suggested earlier probably isn't going to apply to your
> > scenario, another little trick would be to ask do you really need that
> > to run as a background item. Maybe change the method flag to synchronous
> > (if it isn't already) and delete the Bkgrd flag on the task (you will
> > need to update the workflow as well, but don't necessarily need to
> > create a new version). We have a  lot of items running this way, that in
> > previous releases I would have automatically thought should be
> > "background".
> >
> > Sometimes you come across a persnickety object method that has to be run
> > as a background task and errors out if this flag is not set - though the
> > method flag is still synchronous.
> >
> > Other things to look at are of course timing issues - the "black plague"
> > of workflow - maybe you need to build a sleep in if you think some table
> > has already been updated and in certain runtime scenarios it hasn't
> > been.
> >
> > In any case - you need to give us out here on the WUG a bit more info ..
> >
> > Good Luck
> >
> > Mark
> >
> > P.S. Where is Roseville?
> >
> > STARK,TAMMY (HP-Roseville,ex1) wrote:
> > >
> > > Ya, I can manually end it.  I was hoping I could find a solution to this
> > > rather than doing that.  I definately don't want to delete the work
> item.
> > >
> > > I will keep trying.
> > >
> > > Tammy Stark
> > > Information Technology Engineer
> > > Hewlett Packard, Business Critical Computing - IT
> > > Voice mail: 916-748-2170
> > > tammy_stark at am.exch.hp.com
> > >
> > > -----Original Message-----
> > > From: Bernhard Koenig [mailto:Bernhard.Koenig at ubsw.com]
> > > Sent: Thursday, July 20, 2000 12:34 PM
> > > To: SAP-WUG at MITVMA.MIT.EDU
> > > Subject: Re: Work Item Stalled
> > >
> > >      Tammy,
> > >      I'm working with a 46B system. I hope 45 is similar to 46.
> > >
> > >      Use transaction SWUF ==> runtime administrator functions.
> > >
> > >      OR
> > >
> > >      Go to your inbox. Highlight the workitem, press icon (small yellow
> > >      button with a cross) "Other functions". Pick "change workitem",
> than
> > >      select "manually completed", or "logically deleted".
> > >
> > >      Thanks
> > >      Bernhard Koenig
> > >
> > > ______________________________ Reply Separator
> > > _________________________________
> > > Subject: Work Item Stalled
> > > Author:  tammy.stark (tammy_stark at hp.com) at unix,mime
> > > Date:    7/20/00 2:10 PM
> > >
> > > Hello!
> > >
> > > I am having this problem again.  I have a workflow that is stalled.
> When
> > I
> > > look at the log, everything is fine.  The workflow is NOT in an "Error"
> > > status.  The workitem (which is a background step) that it is currently
> > > trying to process is just sitting there (reading "In Process") but it
> will
> > > not finish.  It started yesterday.  I checked transaction SM58 and there
> > are
> > > NO entries.  This used to be very simple to fix on 3.0D.  We are on
> 4.5B.
> > > Any
> > > ideas?
> > >
> > > Thanx!
> > >
> > > Tammy Stark
> > > Information Technology Engineer
> > > Hewlett Packard, Business Critical Computing - IT
> > > Voice mail: 916-748-2170
> > > tammy_stark at am.exch.hp.com
> > >
> > > This message contains confidential information and is intended only
> > > for the individual named.  If you are not the named addressee you
> > > should not disseminate, distribute or copy this e-mail.  Please
> > > notify the sender immediately by e-mail if you have received this
> > > e-mail by mistake and delete this e-mail from your system.
> > >
> > > E-mail transmission cannot be guaranteed to be secure or error-free
> > > as information could be intercepted, corrupted, lost, destroyed,
> > > arrive late or incomplete, or contain viruses.  The sender therefore
> > > does not accept liability for any errors or omissions in the contents
> > > of this message which arise as a result of e-mail transmission.  If
> > > verification is required please request a hard-copy version.  This
> > > message is provided for informational purposes and should not be
> > > construed as a solicitation or offer to buy or sell any securities or
> > > related financial instruments.