Long delay in raising events

[Edward Diehl]

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