With the flexibility, you will also find complexity.
In some cases, details about certain settings might be irrelevant, because the process you are implementing does not require them. For instance, if you don't use 'event queueing', you will not need to bother about the event queue background job.Some setting might seem irrelevant, but can actually be quite important. One of these I found out is the 'Behaviour on Error Feedback'.
Symptoms
I noticed that sometimes, on rare occasions, a certain workflow was 'unsubscribing' itself from an event.So, let's say I have created a workflow that listenes to the event CREATED of object type BUS2000110. I have customized (in the development system in transaction SWDD) that the linkage is activated. If I don't do this, the workflow will not be triggered.
After a few weeks of working fine in production, suddenly, workflows are no longer triggered. This can of course be a big deal. So, let's see what happened.
Cause
You notice in SWDD, or in transaction SWETYPV, that the linkage is not active. This is strange, because you are sure that you have customized that the linkage is active. You check in your development system, to prove to yourself that you are not insane.
Then you notice in transaction SWETYPV, that the receiver status has been set to 'Errors'. Interesting stuff! Obviously, errors have occured, and the system has decided that to prevent further errors, the workflow should be deactivated.To analyse the errors, you can check transaction SWF_GMP, the 'Administrator Overview'. This transaction shows the pending items (no further processing due to blocking tasks) and errors (no further processing due to errors).
What to do?
So, two things have actually happened. First, errors occured in your workflow. You should of course prevent errors, so check the root cause of the errors and prevent from happening by for instance changing custom coding in your workflow, or change the agent determination rule.As well as solving the problems leading to the error, you can also question if the linkage deactivation is useful in your case.
The setting of the 'Behaviour on Error Feedback' is both a system-wide setting (not recommended to change this unless you have thought this through thoroughly) in transaction SWEADM as well as a workflow-specific setting. If you feel that the errors occuring in this workflow will not be able to 'overkill' the SAP system, you could decide to change the 'Behaviour on Error Feedback' in your workflow to 'do nothing'. All other (non-erroneous) workflows will keep on running.
Make sure you keep watching, analysing and fixing workflow errors on a frequent basis to make sure all is running fine, despite the settings you have made.
