Terminating event of a task is not working

[Former Member]

Hi,

I implemented WS20000075 for purchase order release.

The dialog workitem of approval has terminating event 'released'

all thru the developement in dev and Q system., this was working

but in production , it happened that other user release PO from me29n

the approval workitem is still in process

i cant check events because trace is off

cud please suggest wat cud be the reason that inspite of release of PO, the workitem did not complete ?

thanks

r

[bhakti2]

the workitem was completed manually via SWIA and the PO creator for the expected workitem which was the next one in workflow

keeping a look at event queue in the production system.

[Former Member]

Hi Rita,

I see from your response at Sep 18, 2008 7:38 AM that ME29N was working in Dev and Q so I think you can ignore my novel above. Sorry...

I will say that I've had similar problems with general event handling when running in Prod because the system load is much heavier than in Dev and Q, and as such the order of processing in the tRFC Queue can't be predicted. You may want to keep an "eye open" to the tRFC Queue at the same time that you're focused on the Event Trace in trying to resolve this.

Regards,

Tom Carruth

[bhakti2]

hi Thomas,

I am extremely thank ful for your explaination , as it opened a different perspective of resolving the issue

I will keep a look at Event queue

fyi - even after triggering the event from SWUE, it was not caught by the workitem as terminating event

also, for your earlier post. is it not so that the terminating event terminated the workitem no matter in what status it is ? i have always seen the approval workitems in ready status getting terminated whenever i approve the document from the transaction and not from workitems.

thank you

[Former Member]

Hi Rita,

I've experienced so much inconsistency with Terminating Events that I've moved away from them. I rewrote my PO Release workflow to use User Decision in parallel with a Wait for RELEASED. If the Approver, chooses "Approve" from the User Decision, I then release the PO in a background activity. If it's released from outside the WF, my Wait picks it up and advances, making the Release Activity obsolete.

Back to your Production problem - For a running PO workflow, check SWEINST to see if it contains an instance linkage at BUS2012.RELEASED having the Workitem Id of the Release Activity.

If there is no event linkage, then the Terminating Event will never get picked-up.

[bhakti2]

Hi Thomas,

As its a standard workflow task which i am using i had not created any entry in SWEINST myself. however when i check it now, i can find the relevant entry for the standard BO event

I will keep in mind to minimise use of terminating event while designing workflows.

thank you

[Former Member]

Two questions first:

#1) In Dev and Q, did you test (or experience) the scenario you are facing in Prod, that being someone else is Releasing the PO?

#2) In Prod, when the Approver performs the release step, does the WF advance?

I'm going to presume that the answer to #1 is NO, and the answer to #2 is YES. If that is the case, here's what I believe to be the dilemma you face.

A "Terminating Event" is not the same as a "Wait for Event". The purpose of a Terminating Event is to essentially call back to an activity that is "In Progress" that the work is done and that its time for the activity to end and to move on.

Your PO Release for example; The user clicks the Release icon and then clicks Save. At that point, processing is handed off to the Update Process (Asynchronous) and the screen is exited. Even though you've left the screen, there's no telling if or when the Update Process for the save has even started or when it has been completed. But it's only when the Update Process has completed that the true Logical Unit of Work (LUW) has completed, and hence when it's appropriate to move on to the next step in the WF.

The way this gets accomplished is to trigger a Terminating Event at the very end of the Update Process, which in turn gets picked up by the PO Release activity that is still sitting and waiting with status "Executing". And that's the key.

I'm almost 100% certain that the Activity has to be in the state of "Executing" before it will react to a Terminating Event. In your scenario, where the Release gets performed outside of the WF, the Release Activity is still in "Ready" status.

I think the solution here is to put a "Wait for Released" in parallel with the Release Activity as a means of capturing the Release that occurs outside of the WF.

Hope this is relevant....Apologies if not.

Tom Carruth

[Former Member]

Hi rita c,

As Frank told, switch on the trace for one day and check event trace, more over dont forget to check for the binding between the event container to workflow container, since the same case happened to me too, and while i was checking the binding nothing is found in the binding, once again i did the binding and now it is working fine.

Thanks and Regards

Balaji K.

[bhakti2]

hi .

i will have the trace switched on and wait for another instance like this in production

also i will try to do SWUE for released event for the same purchase order and see if this time the task catches this terminating event

but i dont know how binding will effect this scenario ? there is no binding between the terminating event 'released' and the task

cud u please explain how binding will matter here ?

thanks.......

[Former Member]

Hi Rita C,

I will explain it with an example.

Let us take that my PO have 4 release R1, R2, R3, R4 (one by one). The workflow will be triggered for the event "releasestepcreated" for the release code R1 if the approver releases the PO at that point of time for the Corresponding release code the "released" event will get triggered so based upon the release code the terminating event will get triggered and it terminate the corresponding task.

For example let us take the same scenario PO R1, R2, R3, R4 (without any order). The workflow will be tiggered for the event "releasestepcreated" for all the release codes, if the approver approves for a release code R1, the "released" event will get triggered for that corresponding release code only not for other release code.

I think my explanation will clear you doubts.

Thanks and Regards

Balaji K.

[bhakti2]

Hi Balaji,

The scenario in the above explaination is possible only if the approval tasks for R1, R2, R3, R4 exists at the same time.

am i right ?

so that whenthe approver releases any release code it knows which of the approval workitems should be terminated

but that will never happen in my case. there will be one and only one approval workitem at any point of time for the po. and when the release event for that PO occurs the approval workitem should be terminated.

i have not created any binding between the terminating event and the task to pass PO number or release code etc

in dev and Q system its working perfectly fine..........its a very simple thing and i didnt do explicitly anything other than what is there in std workflow.

thanks.

[Former Member]

Hi Rita C,

As you told "i didnt do explicitly anything other than what is there in std workflow". If this is going to be case can you please check for the same standard workflow WS20000075>TS20000166>Termination event tab.

Please check for the same. You can see binding will be there for all the three events "release" "reset" and "significantlychanged".

Thanks and Regards

Balaji K.

[bhakti2]

Hello Balaji,

yes, there is binding

same thing is there in production system

in Dev and Q it happened everyday while testing that we approved from me29n and the task got terminated

but in prod its still in process. and i can see that the PO is approved.

thanks.

[Former Member]

Hi Rita C.

Thats really good. Now, switch on the trace and create a dummy PO (With releases) and check the event trace in SWEL.

If the "release" event got triggered then there may some buffer issue. If the "release" event not got triggered then we have to go for some other options.

But upto my knowledge. I think "release" event wont get invoked when a PO is release, but for sure "releasestepcreated" and "significantlychanged" events will get triggered. Kindly check for the event trace by release the PO (Dummy in production).

Kind advice :- Never try to create a PO and test the workflow in Production system (there may be some legal implication effect can happent), so better try creating PO in QA and check for the event trace and then proceed further.

Thanks and Regards

Balaji K.

[bhakti2]

Hi Balaji,

-- the events are working perfectly fine in Q.

-- i certainly cant create PO in the production system

-- all i can do it start the event trace in prodcution and wait for another such occurance or i can trigger the 'release' event thry SWUE for the same PO

-- as per my knowledge -

release event --- triggered whenver a release code is approved.

releasestep -- when there is a release code that needs to be released

significantly changed -- when the PO is changed so much that the release strategy changes

so in my case release event shud definitely have triggered when the release code was approved.

and obviously it got triggered while the workitem was with a user because order is -

PO with release strategy created -- approval workitem goes to user -- someone else approved the release code

there is no release step after that so there is no releasestepcreated event and the PO is fully released.

-- another point in my case is that the person who got the workitem did not have authorisation to release the particular release code. he had got the workitem by mistake. i assumed tht this shud have nothing to do with terminating event because afterall the task shud in any case catch the terminating event. but ill try to setup a scenario with missing authorisation in Q and check wat happens.

thank you

[imthiaz_ahmed]

Rita C,

Your understanding is just perfect. Just turn on the trace and wait for another instance to happen. Check the WF log and see what it says there.

Regards, IA

[Former Member]

Best option is enable the trace for one day and check if there is any error in the event linkage.