Modify the Run-Time Value of Workflow Containers. Part-2

I hope our previous article “Modify the run-time value of workflow containers Part 1” helped you understand the pros and cons of restarting a workflow when it goes into an error state due to the data issue. But what if the workflow went to the error state due to missing container value or workflow behaved wrongly due to wrong container data? 

Before we start let us just try to understand what is a Container in terms of workflow.

Container: For now just imagine Container as a bucket that holds the data and at runtime, workflow gets the required/operational data from this bucket. Easy right? See for yourself how the workflow container holds the data.

Now just take a look at a real time example that will show you how a missing container value forced the workflow to go into the error state.

In the below image, you can see that the workflow went to error and the workflow log reveals that workflow container is missing some data due to which the workflow failed.

If we debug the error work item, we will come to know which element/data is missing in the container. For this example, after debugging the work item we came to know that the release code was missing in the workflow container

To know how to debug a work item in sap workflow click here: How to Debug a Workitem in SAP

Let’s have a look at Some of the debugging snapshots :

Note: These snapshots are just giving you a glimpse of a real time scenario. 

Now here comes the best part. Let’s restart the workflow just like we did in the first scenario when the workflow went to error state due to a data issue.

Also Read: Did you check our first SAP Yard-athon Contest?

How do I Restart?

Find out more: How to Restart a Workflow

The first method will be using transaction SWUS to restart the whole workflow from the starting.

• Doing so will again execute the whole workflow steps from the starting and the previously completed task will again restart that needs to be completed by the agents of the respective workflow task.
• Using SWUS, restarting the workflow will not give you the guarantee that this time the missing/wrong values will be present in the workflow container. It may be possible that container values are not getting populated due to some database issue. If you are lucky enough then restarting the workflow can work but there is no guarantee that restarting the workflow will solve the issue.

 You can not do any thing here

• Restarting the workflow using SWUS will again generate a new work item in the user’s inbox. Previous step users will need to again perform the same work with the new work item. Previous step user can get frustrated doing the same job again and again. Believe me, I have seen how users get angry when they get the new work item for the same task. Creating a new ticket to delete the old work item from their inbox comes as additional job for them and what if restarting the workflow again not solved the issue and previous step user again gets the new work item to complete.

So, are you going to restart the workflow, again and again? Generating a new work item each time and what if the issue is not solved?

The second method will be Using transaction SWPR to restart the workflow from the point where it went to an error state.

       Thank God, Restarting the workflow using the transaction SWPR will not generate a new Workitem

Let us do that and see whether this method would populate the missing container value or not.

Steps: Run the transaction SWPR and enter the work item that needs to be restarted from the step where it got stuck and press restart.

Wait…What ? The SWPR transaction is not able to restart the workflow. 

But Why?

Because, this time too, the missing container value is not present in the workflow container.  

Now I guess you have understood the purpose of comparing both the scenarios where workflow went into error state due to data issue and workflow went to error due to missing /container value.

   I know you are curious to learn how to resolve this missing container value thing.

SAP has provided a standard function module named ” SWL_WI_CONTAINER_MANIPULATE”

This powerful function module allows you to pass the work item ID of the step whose container you want to modify. You can display and edit the containers. In our case, the work item ID is 123456 and the release code is not populated.

Steps for changing the container value :

• Run the transaction SE37 and execute the function module SWL_WI_CONTAINER_MANIPULATE

• Enter the work item number whose container value needs to be modified and remove the display constant value ‘X’ so that you will be able to modify the container value. Then Execute.

• Now you will be able to see the work item container values. Double click the container values whose data needs to be manipulated and modify the value.

• Once you are done. Restart the workflow using SWPR or SWUS based upon the business need.

Here we are restarting the workflow using SWPR transaction since we do not want to generate a new work item again.

You can see that now after restarting the workflow, it restarted perfectly without going into an error state.

Reason: Because this time the missing container value is present in the workflow container and the workflow has received the container value at run time.

Seeing is Believing…

Hope you enjoyed reading this post and understanding the basic difference between Restarting the workflow using transaction SWUS and SWPR and also you came to know how to modify the container values at run-time?

For more workflow related posts visit my blog The Sharp Turtles.