Background Workflow steps taking many hours to execute

[Sample, Rick]

Hi Carolyn,

I have to step away for a bit, but just a quick follow-up on why not running after weekend comment.

The defaults are 20 mins cycle. 'Were' for 4.6c err monitor anyway. I believe on task for Temp errors will try 
x times and then just error after that number is reached. 3 times is what we have ours set to and 20mins apart. 
You would want Temp errors to trip for stuff like record locked, record not updated before <whatever occurred to trip error>, etc. Things that should shake loose if you just wait a few minutes. 

On ECC6 I have read in the help files these numbers changed. 'If' using BPM, these numbers are lower. 
As I have read. Don't know for sure. 

I think you and Mike are on right track. "Something" changed to cause these issues and you need to start back tracking transports while it is still fresh in everyone's minds. BASIS changes, I would get history on what and when.

Don't recall, can you reproduce this in dev or QA? 

Rick


> -----Original Message-----
> From: sap-wug-bounces at MIT.EDU
> [mailto:sap-wug-bounces at MIT.EDU] On
> Behalf Of Carolyn A Fuller
> Sent: Monday, November 15, 2010 9:17
> AM
> To: SAP Workflow Users' Group
> Subject: Re: Background Workflow steps
> taking many hours to execute
> 
> Mike,
> 
> I just ran SWU2 and I see one entry but it
> doesn't tell me much. I am pretty sure the
> SDN discussion about changing the
> context to a background user is the issue
> but I don't know why it all of a sudden
> became an issue.
> 
> Over the weekend the basis team did
> change the scheduling of RSWERRE to
> every 20 minutes. But I'm thinking
> something else changed over the weekend
> also. Because by this time Friday,
> SWWLOGIHIST entries indicate
> RSWERRE had executed 9 times. So far
> this morning, it has not executed at all.
> 
> Also, we discovered that this started
> becoming an issue on Oct 29 so I'm trying
> to find out what went into production the
> night before. I know the transport that
> increased the number of loops that one of
> the templates executes went into
> production that night. But I don't
> understand how that could have led to this
> particular problem.
> 
> Carolyn
> 
> 
> On Nov 14, 2010, at 5:03 AM, Mike
> Pokraka wrote:
> 
> > Hi Carolyn,
> >
> > Looks like it's not a WF problem but
> something on the basis end. The log
> shows it starts a tRFC transaction and
> then nothing until the error job picks it up.
> Part of the error job's function is to do
> exactly that. You would normally see these
> sitting in SM58 or if you don't have access
> then one of the WF transaction does the
> same (Could be SWU2? Just look in the
> menu under administration -> RFC-
> something). As Rick also mentioned, the
> RFC is to switch the context to a
> background user.
> >
> > You will only see this in SM58 between
> the step start and when the error job picks
> it up, so a long schedule will be better for
> troubleshooting. Maybe search for the
> task with today's date and status not
> COMPLETED in SWI1 and keep
> refreshing throughout the day until you
> spot one. Then go look in SM58 / SWU2
> which should give you further info. The
> system log may tell you more, or also
> worth checking dumps.
> >
> > Cheers,
> > Mike
> >
> >
> > -----Original Message-----
> > From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu] On
> > Behalf Of Carolyn A Fuller
> > Sent: 13 November 2010 21:44
> > To: SAP Workflow Users' Group
> > Subject: Re: Background Workflow
> steps taking many hours to execute
> >
> > Rick,
> >
> > I have my personal workflow settings set
> to Technical View. And the logs are all
> indicating green lights and no errors.
> >
> > I am not sure what you mean by "Admin
> would have logged a re-executed every 20
> mins." RSWERRE is scheduled for every
> 90 minutes. (Hopefully this will change by
> Monday morning.) But even with it
> scheduled for every 90 minutes I don't see
> a log indicating that anything re-executed.
> >
> > The workflow administrators do receive
> messages when any workflow errors occur
> but we have not received any messages
> from these delayed workflows.
> >
> > Carolyn
> >
> > On Nov 13, 2010, at 12:14 PM, Sample,
> Rick wrote:
> >
> >> one more thing, you should be able to
> see that in the log.
> >> Go to the task in question, tech view,
> and see what the logs tell you.
> >> Admin would have logged a re-
> executed every 20mins. Errors should be
> >> sent to the admin as msg.
> >>
> >>> -----Original Message-----
> >>> From: sap-wug-bounces at mit.edu
> >>> [mailto:sap-wug-bounces at mit.edu]
> On
> >>> Behalf Of Sample, Rick
> >>> Sent: Saturday, November 13, 2010
> 10:56 AM
> >>> To: SAP Workflow Users' Group
> >>> Subject: RE: Background Workflow
> steps taking many hours to execute
> >>>
> >>> I agree, need more info. Like, any
> recent changes to code like a
> >>> loop?
> >>>
> >>> But, temp errors are default to
> 20mins. 20 20 and 20 is around 60,
> >>> depending on start / finish of
> SWWERR job.
> >>> Note: in 4.6c, the default was 20mins
> for the Temp Err, I believe
> >>> that has changed for ECC6 due to
> BPM. But we stuck to 20mins.
> >>>
> >>> So, if temp error, sounds like it was
> re- attempting something until
> >>> it finished.
> >>> *sounds* like it.
> >>> Check the Task BOR method for
> temp
> >>> exceptions.
> >>>
> >>> Rick Sample
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: sap-wug-bounces at mit.edu
> >>>> [mailto:sap-wug-bounces at mit.edu]
> On Behalf Of Jimmy Sun
> >>>> Sent: Saturday, November 13, 2010
> >>> 9:58 AM
> >>>> To: SAP Workflow Users' Group
> >>>> Subject: Re: Background Workflow
> >>> steps taking many hours to execute
> >>>>
> >>>> Carolyn,
> >>>> If you can explain more detail of
> what is
> >>> the step doing, it will help
> >>>> to determine ther problem.
> >>>>
> >>>> Jimmy Sun
> >>>> Senior Consultant
> >>>> On 11/12/10, Carolyn A Fuller
> >>>> <fuller at mit.edu> wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Recently, my end users have
> started
> >>>> complaining about the performance
> >>>>> of some of their workflow
> background
> >>>> steps. They said that this has
> >>>>> just recently become a problem.
> >>>>>
> >>>>> Today, I looked at the logs for one
> of
> >>> the
> >>>> excessively slow workflow
> >>>>> background steps and it indicated
> that
> >>>> the background step was created
> >>>>> at 14:37:49, then started and
> ended
> >>>> over an hour later at 15:40:06.
> >>>>> This step normally takes less than
> a
> >>>> second to execute.
> >>>>>
> >>>>> What could cause the hour delay
> >>>> between when the step was created
> and
> >>>>> when the step actually started and
> >>>> ended?
> >>>>>
> >>>>> The workflow in question is using
> XML
> >>>> persistence. I converted this
> >>>>> workflow to using XML persistence
> >>>> about a year and a half ago.
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> Carolyn Fuller
> >>>>>
> >>>>> Senior Analyst/ Programmer
> >>>>>
> >>>>> Information Services and
> Technology
> >>>>>
> >>>>> Massachusetts Institute of
> Technology
> >>>>>
> >>>>> Room W92-210
> >>>>>
> >>>>> Cambridge, MA 02139
> >>>>>
> >>>>> (617) 253-6213
> >>>>>
> >>>>> http://fuller.mit.edu/
> >>>>>