Long delay in raising events

[Mike Pokraka]

Hi Ed,

It should still work, because fortunately most of HR works in days and is
usually pretty well defined. Sometimes it may be a little difficult to
fathom exactly where said definitions live, but that's half the fun.

So my first approach in your scenario would be to dig ino the config
(SWEHR2/3) to determine exactly whcih conditions trigger REHIRED. Most
likely it will be a combination of infotype data at current date. Then
test for the same during the startup of POSITIONCHANGED WF, or wherever
else it may be appropriate. Now we are relying on a series of dependent
actions (one must add a person into the org chart before we can move them
around), rather than events.

Regards,
Mike


On Wed, October 23, 2013 4:22 pm, Edward Diehl wrote:
> 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
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>