Long delay in raising events
Edward Diehl
edwarddiehl at hotmail.com
Wed Oct 23 04:07:15 EDT 2013
We checked the tRFC and queues and found nothing that would cause such a problem. It appears to simply be a resource-performance problem. In our production system with multiple servers and load balancing these events are raised nearly simultaneously. When we implement EHP6 next month in production, I do not anticipate this performance problem.
If the problem persists, we have a wait step task that can be used to solve the problem.
Thanks.
Ed Diehl
"Success consists of going from failure to failure without loss of enthusiasm."
From: jocelyn.dart at sap.com
To: sap-wug at mit.edu
CC: sap-wug at mit.edu
Subject: Re: Long delay in raising events
Date: Mon, 21 Oct 2013 20:26:48 +0000
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> 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
To: 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]
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."
_______________________________________________ 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20131023/7eba19f0/attachment.htm
More information about the SAP-WUG
mailing list