Long delay in raising events

[Mike Pokraka]

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