Long delay in raising events

[Edward Diehl]

Interesting view, Mike.  In our production system the events are (almost) simultaneous and that is what our design is based on.  The problem with any other method is that changes to PA information can occur quite often, even for the same person, so testing the database for data that obsoletes the current workflow might yield conflicting results.

If necessary we will try a wait step for the relevant events as the next step.

And you're right.  It is totally a performance issue.

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



CC: sap-wug at mit.edu
From: wug at workflowconnections.com
Subject: Re: Long delay in raising events
Date: Wed, 23 Oct 2013 15:49:51 +0100
To: sap-wug at mit.edu

Hi Ed, 
20 seconds is nothing. Event triggers are processed via RFC and these can be held up for hours in cases of system load. Due to load balancing, event receivers are often triggered on different servers, and can even be out of sequence. The whole event mechanism is designed to be decoupled, and hence relying on timing is not appropriate when dealing with events.
Your design works if workflow 1 is something long running, but if a 20 second delay is too long for workflow 2 to function correctly, you have an unstable setup. I would suggest that workflow 2 should look at the underlying data of the relevant object to see whether it's needed. Or perhaps wf1 should wait for wf2 to start up and kill it via an event, or maybe manage it in start conditions, there are a few ways to address this other than relying on the timing of events.
Regards, Mike

On 21 Oct 2013, at 19:56, Edward Diehl <edwarddiehl at hotmail.com> wrote:




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 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20131023/1cbc5cf3/attachment-0001.htm