Page 1 of 1

Workflow reaction to the key object instance being deleted

PostPosted: Thu Feb 28, 2013 5:18 am
by DeathAndPain
Hello everyone,

so I created a workflow that works with trips that are to be approved. A trip is created, then my workflow offers the trip to a responsible person for approval, then processes the result. (Please note that trips are only an example. This is a problem that applies to all sorts of object instances a workflow can work with.)

But what do I do when someone deletes the trip (e.g. in transaction PR05) while the workflow is in progress? I am facing the following situation:

- trip is created by someone
- approval workflow on the trip is being started
- approval workflow is waiting for the responsible boss to execute the approval dialogue
- someone deletes the trip
- the responsible boss tries to execute the approval dialogue

The workflow now finds that the object instance (the trip) of the workflow no longer exists. There is no visible reaction, but the workflow quietly switches from state "Ready" into state "ERROR" with no error message whatsoever.

How can I - as the workflow programmer - catch the above situation and create an appropiate reaction, such as the workflow being cancelled and a proper error message being displayed to the boss? Of course instances of objects that are being used in a workflow should not be deleted in the first place, but nobody is perfect, and silently crashing is the worst reaction the workflow can do.

Re: Workflow reaction to the key object instance being deleted

PostPosted: Thu Feb 28, 2013 5:22 am
by Gothmog
There is usually a DELETED event in objects - you can use a fork to wait for this event in the another branch and terminate the workflow when you receive it.

Re: Workflow reaction to the key object instance being deleted

PostPosted: Thu Feb 28, 2013 8:44 am
by DeathAndPain
Your idea is great, and indeed transaction SWEL (event trace) reveals that a DELETED-event is created when a trip is deleted.

However, when trying to use this event in my workflow I am running into a technical problem. The standard business object type for trips is BUS2089. I wanted to use it in my workflow, but needed additional methods, because I wanted to program tasks of my own. So what I did was define a new business object type ZREISEANTR and declare BUS2089 as the superclass. This way ZREISEANTR inherited all attributes, methods and events from BUS2089 and could be enhanced with my own methods. Works nicely, but for obvious reasons, when someone deletes a trip using transaction PR05, an event DELETED of object type BUS2089 and not of object type ZREISEANTR is created.

In the "Wait for event"-block of my workflow this means that I would need to wait for exactly this event. However, when creating a "Wait for event"-block in the workflow definition (SWDD), I need to specify the container element to which the event is related. I specify the container element of the trip in my workflow, but it belongs to the object type ZREISEANTR, not BUS2089, even though it has exactly the same elements, seeing that BUS2089 is the superclass of ZREISEANTR. As the consequence, my workflow waits for the event DELETED of object type ZREISEANTR, which never occurs. What occurs is the event DELETED of object type BUS2089. Is there any chance that I can catch this event in my workflow?

Re: Workflow reaction to the key object instance being deleted

PostPosted: Thu Feb 28, 2013 9:39 am
by Gothmog
I assume you use delegation from BUS2089 to ZREISEANTR.
How do you start your workflow? By event Created of BUS2089 or ZREISEANTR?
Have you activated the instance linkage for this event in SWEINST?

Re: Workflow reaction to the key object instance being deleted

PostPosted: Thu Feb 28, 2013 10:28 am
by DeathAndPain
I start the workflow using a ZREISEANTR-event, but that does not mean much, seeing that I create this event manually using a FM in my coding.

However, when it comes to a deleted trip, it is not my own coding that triggers the event, but the coding of transaction PR05, which is SAP standard code and triggers an BUS2089 event "DELETED". Instance linkage for both BUS2089-DELETED and ZREISEANTR-DELETED is active in SWEINST, even though it was not me who did it. I believe the workflow itself activated this, seeing it had a corresponding event. This also complies to SAP documentation which states that you never need to care for instance linkage manually (unlike type linkage which is used to launch workflows).

What I tried now is declaring another container of type BUS2089 in the workflow, copying the content of the ZREISEANTR container into BUS2089, and then wait for the BUS2089-DELETED event.

Wait a minute! This works! To a certain extent at least. Event trace (transaction SWEL) indicates the event has been passed to my waiting step, and the step has in turn changed to state "COMPLETED". Since the fork is defined as needing 1 out of 2 branches to complete, and the branch with the waiting step has completed, the workflow should now be bypassed. Indeed the branch in the graphical diagram that bypasses the workflow is green.

However, in the other branch, the one with the regular workflow (which should normally be processed when no moron shows up and deletes the trip that is being approved) there is another fork (i.e. a sub-fork of the first fork) that contains another waiting step in one of its branches and the approval task in the other. Theoretically, that sub-fork and all of its branches should become obsolete once the other branch of the main fork completes (seeing that the main fork is set to 1/2). However, this is not the case. The system still waits for one branch of the sub-fork to complete. The corresponding workitems remain in status "READY". Do you have any idea why this is the case and how I can prevent it?

Things are getting a little complicated, so here is a diagram of the workflow structure so you can understand better what I am talking about.

Re: Workflow reaction to the key object instance being deleted

PostPosted: Thu Feb 28, 2013 11:41 am
by Gothmog
I still think delegation should let ZREISEANTR manage events of BUS2089, but anyway...
It's weird that your item stay in READY status - they should be logically deleted.
Maybe the double fork is the culprit (I haven't one in a workflow here to test it easily) but that's the expected behaviour.

I tested it on a trip approval workflow, and when the event is received, the WI in the other branch of the fork is logically deleted.

Re: Workflow reaction to the key object instance being deleted

PostPosted: Fri Mar 01, 2013 8:01 am
by DeathAndPain
Well, what I have done now is that I added a flow control block after the waiting block. This flow control block logically cancels the whole workflow when the event "DELETED" has been triggered. Works nicely.

Thank you for your help! I do not think I would have got this far without it.