Background Workflow steps taking many hours to execute

[Mike Pokraka]

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
>