Do you know how to modify the content of workflow containers at run-time?
This means you can actually modify and manipulate the workflow runtime values after the workflow has triggered and the work items are created.
Ignore the previous lines 🙂
Before learning about how to modify the run-time value of workflow containers, we need to first understand the business requirements that force any one to manipulate the workflow container value at run-time. The manipulation can have a number of uses, in our post, we will learn about two simple scenarios that will help us to understand the concept.
Note: We have divided this tutorial into two parts, for the ease of the readers.
Business Requirement :
For example, we have a workflow that contains a total of 3 steps.
Please have a look.
Now let’s imagine that some how step 2 went to error state that caused the workflow to not complete.
Now if you are new to workflow, your first Question will be why it went to an error state?
There could be various reasons for that and let me point out 2 reasons that are related to this post.
- The Workflow was not able to get the desired data and it got terminated.
- The Values in the Workflow containers were not populated at run-time or wrongly populated and it got terminated.
We want to first show you the comparison between above two scenarios. Let’s discuss one by one both scenarios discussed above.
(A) The Workflow was not able to get the desired data and it got terminated.
Let us imagine that the step number 2 was fetching some data from the database and if data is not found, Step 2 is configured to want to be in an error state.
A real time example for you guys :
Let us take a purchase order workflow that is fetching the agent list from a ZTABLE and it is configured to fail when there is no agent/id found.
You can see in the below picture how workflow was not able to fetch any agent from the database and it went to an error state.
How to Solve this issue?
Now if you want to solve the issue you need to maintain the data and again need to restart the workflow using t-code SWUS. Let’s maintain the missing data and restart the workflow.
Want to learn how to restart the workflow? Please visit How To Restart a Workflow in SAP.
After restarting the workflow.
See for yourself, the workflow was restarted and it generated a new work item.
Note: When the workflow was restarted, it generated a new work item and the whole process restarted again from the beginning.
So, what if you want to restart the workflow that is in error status due to data issue and also you want that NO new work item should be generated ie. the workflow should restart from the point where it went in error.
Then you need to use the transaction SWPR.
Present Scenario :
Desired scenario :
Also Check: How to Debug any Work Item in SAP Workflow?
What have we understood till now?
If the workflow went to error state due to some data issue then,
- We can normally restart the workflow using transaction SWUS but doing so will generate a new work item and the whole process, Previous steps that were already completed will be again executed.
What if there are more than 10 steps in workflow and workflow went to error state at the 9th step?
Isn’t it frustrating that again the same users for step 1- 8 will receive the new work item for the same document and they will execute the same steps again to complete the same work and also in future, the user will need to delete the old work item from his workflow inbox because it is of no use.
Totally frustrating 🙁
- Now let us assume that workflow was restarted from the transaction SWPR, then no new work item is generated and the workflow is restarted from the point where it went to error.
Now please visit the next part of the post where we will see the scenario when the workflow went to error state because the values in the workflow containers were not populated at run-time or wrongly populated.
Please visit TheSharpTurtles for more Workflow Tutorials.