Long delay in raising events
Dart, Jocelyn
jocelyn.dart at sap.com
Mon Oct 21 16:26:48 EDT 2013
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
More information about the SAP-WUG
mailing list