Long delay in raising events

[Tedde Taege]

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] On Behalf Of Edward Diehl
Sent: Monday, October 21, 2013 1:56 PM
To: 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20131021/d302a24a/attachment.htm