Duplicate Workflows Being Triggered from Single Event

Bratzler, Loren loren.bratzler at nscorp.com
Tue Dec 10 11:26:29 EST 2013


Kjetil,



Thank you for the reply.  You wrote below:



One possible scenario is that the starting of the workflow failed, causing an

SM58 entry for a hanging RFC call, and then this was executed by someone while

the event was also being reprocessed by the event queue processing?



I am not familiar with SM58 (and do not have access to it in production).  When you say "this was executed by someone", does that imply that there is a function in SM58 that will allow us to manually reprocess a failed RFC call?



Also, thank you for the information on the event queue background job.  That was a mystery that was puzzling myself and our Basis team!



Loren





-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Kjetil Kilhavn
Sent: Tuesday, December 10, 2013 5:59 AM
To: SAP Workflow Users' Group
Subject: Re: Duplicate Workflows Being Triggered from Single Event



Tirsdag 3. desember 2013 11.28.11 skrev Bratzler, Loren:

> Hello,

>

> Need some help here!  We had some users complain that they were

> receiving duplicate approval tasks in their inbox for a single item.

> Upon investigating, I discovered that there were two workflows being

> triggered for the item.  I turned on the event trace for the

> triggering event and found that the event was only being raised once,

> but the workflow was being created twice from that event.



One possible scenario is that the starting of the workflow failed, causing an

SM58 entry for a hanging RFC call, and then this was executed by someone while the event was also being reprocessed by the event queue processing?



> Below is a screen-shot of the trace.

>

> [cid:image001.png at 01CEF019.FA0E68A0]<mailto:[cid:image001.png at 01CEF019.FA0E68A0]>

>

> The hi-lighted lines in the screen-shot show that the triggering event

> (BUS2042 - TO_BE_APPROVED) occurred at 14:55:04.  A workflow was then

> triggered at 14:55:11 and another workflow at 14:56:32.  The problem does

> not occur every time this event is raised.  Note that the entries before

> and after the hi-lighted entry worked fine.  Only one workflow was

> triggered and the events were all raised by the same user.

> The event linkage in SWE2 only has this one event associated to the

> WS20000139 receiver.

> This particular event uses the Event Queue.  Our event queue background job

> is configured to operate dynamically with a maximum of 100 events per read

> access.  Time interval between read accesses is 1 minute and interval

> between queue checks is 5 minutes.  So the background job will run every 5

> minutes unless there are more than 100 events to process.  Then it would

> run every 1 minute.

> I am wondering if the problem might be related to the background job?  Could

> it be running in the 1 minute mode (due to event queue load) causing it to

> somehow process the event twice?  I have tried to look at the execution

> history of the background job in SM37 but for some reason, SM37 will only

> show the latest execution of the job.  That is another question I have as

> well.  Does anyone know why the event queue background job (SWEQSRV) would

> not show the execution history in SM37?



The RSWEQSRV report deletes old job entries to avoid filling up the system.

Look at the code, there is a call to function module SWE_BATCHJOB_DELETE. You

could implement an enhancement to prevent that (temporarily) if you need to.





> All of the other workflow

> background jobs are showing their execution history but SWEQSRV does not.

> [cid:image002.png at 01CEF01A.BF4A5A20]<mailto:[cid:image002.png at 01CEF01A.BF4A5A20]>

>

> Loren Bratzler

> Norfolk Southern Corporation

> 110 Franklin Road SE

> Roanoke, VA  24042-0060

>

> Phone: 540-524-3072

> Email: loren.bratzler at nscorp.com<mailto:loren.bratzler at nscorp.com<mailto:loren.bratzler at nscorp.com%3cmailto:loren.bratzler at nscorp.com>>

--

Kjetil Kilhavn / Vettug AS (http://www.vettug.no)

_______________________________________________

SAP-WUG mailing list

SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>

http://mailman.mit.edu/mailman/listinfo/sap-wug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20131210/7d50b0b0/attachment.htm


More information about the SAP-WUG mailing list