Background Workflow steps taking many hours to execute

[Carolyn A Fuller]

Mike,

Do we really need to change how often RSWWERRE is launched if there are no entries in SWWLOGHIST for RSWWERRE? 

I have been monitoring SWWLOGHIST and I have not seen any RSWWERRE since Friday.

Again, thank you so much.

Carolyn
On Nov 16, 2010, at 9:35 AM, Mike Pokraka wrote:

> Hi Carolyn,
> 
> Going from past experience, RFC-related problems rarely have anything to
> do with workflow changes. Usually they're either environment-related or
> code changes that explicitly involve RFC (e.g. querying something in a CRM
> system).
> 
> Environment issues are what I've seen most often, but notoriously
> difficult to pinpoint without understanding the error.
> Could be a system parameter change.
> Could be a job that's been rescheduled and conflicts with something else
> that causes a lock.
> Could be network troubles.
> Could be something that was changed weeks ago and only starts to surface
> during peak loads or whilst XYZ is processing.
> You get the picture.
> 
> Suggest to keep monitoring SWU2 until the problem crops up again. If not
> an administrative nightmare then I'd temporarily change RSWERRE to a
> fairly long schedule (1h or more) so that it doesn't disappear before you
> can catch it.
> 
> Cheers,
> Mike
> 
> On Mon, November 15, 2010 6:12 pm, Carolyn A Fuller wrote:
>> Mike,
>> 
>>> so, what was the issue? BASIS change? Other non WF change? Sun spots? (I
>>> hate sun spots!)
>> 
>> Missed that question.
>> 
>> So far we don't know what caused this problem. We keep careful records of
>> what goes into production and the only thing that went into production the
>> night before the problems began was a custom "configuration" transport
>> that had the effect of increasing the loops a particular workflow template
>> goes through. Prior to this transport the workflow went through 8 loops
>> and after the transport the workflow is going through 9 loops.
>> 
>> The workflow template itself wasn't touched. The loops are dynamically
>> determined by the custom "configuration" table mentioned above.
>> 
>> If this is what caused our problems, I would have expected the delays to
>> be associated with the new loop or, at least, just the workflow template
>> executing the loop. But our delays have been associated with all our
>> workflows including standard SAP iDoc flows. And the steps are always
>> background steps that happen right after a dialog step.
>> 
>> Carolyn
>> 
>> 
>> _______________________________________________
>> 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