A workflow has stoppen because of an error on one of it's tasks. The workflow log shows an error and the flow is no longer processed. What is happening and how can the error be resolved?
What happened?
A workflow in error has stumbled across a problem for which no error handling was put in place. An unforeseen error, which can not be ignired and for which no processing has been defined. The task which stumbles across the issue will be stopped and gets the "in error" status. The workflow for which the task was called autimatically inherits the "in error" status and also stops. Hence a workflow with multiple processing branches will stop processing all it's branches if a task ends in "in error". Workflows in error are stopped. It is a basis task to check workflows in error, irrespective of the type of workflow. Transaction SWI2_DIAG Diagnosis of Workflows with Errors.
Restarting errors
There is an enormous and growing variety of errors possible. Some of these can be restarted, other errors can not be resolved that easily. If you are looking to resolve the problem, the first thing to attempt is "restart after error". First of all please realize that this is a basis or administrator task. Via transaction SWIA work item administration report, the work item can be restarted. Tracsaction SWW_WI_ADMIN_ERROR_RESTART Administrator Activates Repaired Work Item - is also available.
There is no guarantee this restart will change anything. Before restarting the actual problem would need to be resolved and even if it was resolved, reprocessing the task would need to be able to reprocess it. Hence: restart after error can result in the same workitem in the same error status.
Restarting the workflow
A workflow is essentially based on a business object such as an order. The order is a document on your system and the workflow is set up for this document. If a workflow would be lost, the business object is not affected. The only risk in a restart is with larger workflows is that the steps that were already done by the errored flow are done again. Approvals or a status change could be attempted again, potentially involving reappearing inbox items.
Once you are happy with the fact that resolving the issue means restarting the whole workflow, there are multiple ways to realize a restart:
- Via transaction
SWUEthe event that triggered the errored workflow can be restarted (assuming such triggering event is available onthe workflow, check the workflow log andPFTC). To do this, the business object for the workflow needs to be initiated (inSWUE) and optional parameters need to be set. The workflow log should reveal all needed information. - With transaction
SWUS_WITH_REFERENCEan existing (errored) workflow can be mimiced. A new workflow is started with the startup settings of the errored flow. A workflow will be started for the business object (e.g. an order) instance (e.g. nr 103421) including whatever triggering event parameters were passed to the original workflow.
Solved or not solved
After restarting the workflow, there are 2 possible outcomes: the issue was resolved or the same error shows up again. In either case, you need to do an additional action: there are effectively 2 workflows on air for the same task. One errored and one that was restarted (potentially in error agai). To avoid the problem fro being resolved again (errored workflows are listed in standard reports, until they are removed) - it should be removed. SWWL can be used to delete the workflow (beware, remove the flow, not the task).If the restart did not solve the problem, I would suggest deleting the restarted flow and leaving the original one in tact.