Long delay in raising events

[Dart, Jocelyn]

Hi Ed
it may not be this but you might want to check txn SM58 and see if there is some hold up in th tRFC queue causing the delay

Likewise check for queues in the LUW in txn SM13

Also check txn SWEQADM and see if that is indicating problems in event delivery
Rgds
Jocelyn

Sent from my iPhone with many apologies for the spelling, grammar and any other deficiencies

On 21 Oct 2013, at 12:27 pm, "Edward Diehl" <edwarddiehl at hotmail.com<mailto:edwarddiehl at hotmail.com>> wrote:

Thanks, Tedde.
Both events are simultaneous in our production system and nothing has been changed for EHP6.  It's executed by SAVE.


Ed Diehl
"Success consists of going from failure to failure without loss of enthusiasm."



________________________________
From: ttaege at nebraska.edu<mailto:ttaege at nebraska.edu>
To: sap-wug at mit.edu<mailto:sap-wug at mit.edu>
Subject: RE: Long delay in raising events
Date: Mon, 21 Oct 2013 19:03:25 +0000


The standard REHIRED event is triggered off of infotype 0000 where the standard POSITIONCHANGED event is triggered off of infotype 0001.  If your user is pausing for a significant amount of time after saving infotype 0000 and before saving infotype 0001, then your time lag between events will be extended.



To counter this type of problem, we have created our own event triggers and merged the event triggers from infotype 0000 into a custom trigger for infotype 0001.





Tedde Taege
University of Nebraska | Administrative Systems Group | HR Lead | 402.472.7544









From: sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu> [mailto:sap-wug-bounces at mit.edu] On Behalf Of Edward Diehl
Sent: Monday, October 21, 2013 1:56 PM
To: sap-wug at mit.edu<mailto:sap-wug at mit.edu>
Subject: Long delay in raising events



We are testing EHP6 and have a workflow where BUS1065.REHIRED is followed by BUS1065.POSITIONCHANGED, all on the same object instance.  This is as it should be.  The workflow has a step that checks for a running instance of REHIRED.  If found it cancels itself as it is not needed.

We have a couple of instances where the POSITIONCHANGED event is not being raised until after the REHIRED workflow has completed and thus does not cancel itself.

We have an instance where the POSITIONCHANGED event follows a full 20 seconds after the REHIRED event.

Has anyone seen such behavior?   Any suggestions as to what needs to checked/changed?

Thanks all.

Ed


Ed Diehl
"Success consists of going from failure to failure without loss of enthusiasm."

_______________________________________________ SAP-WUG mailing list SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu> http://mailman.mit.edu/mailman/listinfo/sap-wug
_______________________________________________
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/20131021/0c3a91f2/attachment.htm