Why Is My Workflow Not Triggered - Through Event?

Posted on Mar. 13, 2009 06:28 AM, Kuala Lumpur, Malaysia

This question is commonly asked in the forum. Why is my workflow not triggered? What might be the issue? Where should I start looking into this issue? And how do I fix it? This blog is going to provide you clues to those questions.

In general, there are 2 ways of triggering a workflow from an application, those are

1. Through event, which can be subdivided again into without queue and with queue, or

2. Through API call.

In this blog, only event without queue (1a) will be discussed.

Event triggering mechanism

Event is normally used in a loosely couple scenario as a means of communication between event creator (the application that triggers the event) and event subscriber (workflow that subscribe the event).

This event triggering mechanism is normally configurable and unique to a specific module. One example is change document in MM (transaction SWEC) which is used to link the application to the event. Another example is HCM customizing tables (transaction SWEHR*) which link the infotype operations and the event. However sometime, it may require collaboration between workflow and functional consultant to customize it. One example is output determination used in SD application to trigger the event.

We are not going to discuss this configuration in detail as it's a big topic by itself, but rather we will focus more toward the event delivery mechanism.

Non standard event triggering mechanism

Normally developer will need to find an exit, like user exit, customer exit, BTE, BADI, enhancement point or section to add in his own code to trigger the event. FM like SWE_EVENT_CREATE_FOR_UPD_TASK is normally used in this case. If the application is a custom built one, then we can use FM SWE_EVENT_CREATE to trigger the event.

Event delivery mechanism

Let say the event is already triggered by the application, which can be seen by switching on the event trace (SWELS) and looking at the event trace report (SWEL), but some how it still does not trigger the workflow. What might be the issue? Let's try to understand event delivery mechanism first before we start looking into the issue.

1. Application triggers the event, for example using FM SWE_EVENT_CREATE

2. Event manager (a program called from within the FM SWE_EVENT_CREATE) will evaluate event type linkage table SWETYPV.

a. If there is no active linkage in the table that suits the event, it will NOT be delivered

b. If there is active linkage for the event, event manager will do the followings:

c. If the receiver type FM is populated, then the event manager will execute it. If it does not find any receiver or it raise any exception, then the event will NOT be delivered. Note: This FM is only required if we want to determine the receiver dynamically, like which workflow to trigger for a particular scenario.

d. If receiver type FM is not populated or it is executed and does find a receiver, then the event manager will execute the check FM. If check FM raises an exception, then the event will NOT be delivered. Note: This FM is only required if we want to add additional check prior to calling the receiver.

e. If the check FM is not populated or it is executed and does not raise any exception, then the event manager will execute receiver FM in the background as a tRFC call. This call will be executed only if the application triggers the commit work. If any exception is raised in this call, the event will NOT be delivered. Note: This FM is always required.

f. If there is no exception raised in any of these 3 FMs, then the event will be delivered and workflow is triggered.

Looking into the issue

Event trace report is the good starting place to understand the cause of the issue.

Over here we can see:

a. Whether the application does indeed trigger the event

b. Whether there is receiver for the event

c. If there is NO receiver found for the event, then check whether the event linkage table has been properly maintained and the linkage is activated. Note: You can add the entry into this table just by adding the start events to your workflow.

d. Whether there is any exception raised in the receiver type and check FMs

e. If there is exception raised, place a debug point in those FMs and check which condition that raised the exceptions.

If there is no error found in the event trace report, the next thing is to check the receiver FM call. Since this is a tRFC call, we can not debug this FM directly as in the case for the first 2 FMs. However, we can check any error happened in this tRFC call using SM58 report and fix it accordingly.

Workflow start condition

The event delivery mechanism remains the same, regardless whether there is start condition in the workflow or not. The only difference is that check FM SWB_2_CHECK_FB_START_COND_EVAL will be used and inserted in the event type linkage table. If there is any exception happened in the start condition of the workflow, it will also be shown in the event trace report, as discussed above. So you can also put a break point in this FM and check which condition fails the event delivery.

Ruslim Chang Senior Process Integrator

Life is beautiful! Let's make it meaningful and colorful!