Background Workflow steps taking many hours to execute

[Mike Pokraka]

Could be something that only happens on certain days. Or - if you like
conspiracy theories - someone may have found a "Doh!" problem of their own
making and quietly fixed it without telling anyone. Maybe it was sunspots.

Who knows? Keep an eye on it and if it doesn't happen again then just stay
sane and pretend it never happened.


On Tue, November 16, 2010 4:30 pm, Carolyn A Fuller wrote:
> Mike,
>
> I don't think it requires paperwork here. I think our basis team can do it
> pretty easily.
>
> What I don't understand is why the delays seem to have completely
> disappeared. Basis says the only thing they changed this weekend was how
> often RSWWERRE is scheduled to run.
>
> Carolyn
> On Nov 16, 2010, at 11:18 AM, Mike Pokraka wrote:
>
>> No, I just suggested it as it makes monitoring easier to catch an rogue
>> item because the job removes it. If it runs every 20 minutes you need to
>> check SWU2 at least every 20 minutes.
>> More time = no need to eat lunch at desk (an unhealthy habit anyway).
>> At some sites you can change the schedule yourself, others need a
>> mountain
>> of paperwork, so it's your call there.
>>
>> Cheers,
>> Mike
>>
>>
>>
>> On Tue, November 16, 2010 3:40 pm, Carolyn A Fuller wrote:
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>