Modify the run-time value of workflow containers

By Anirban Bhattacharjee, KPIT Cummins and Infosystems from Link

Purpose: The purpose of this document is to demonstrate how to modify the values of workflow containers from the workflow logs running instance. This means, you can actually modify and manipulate the workflow runtime values after the workflow has triggered and the work items are created. This will help you restore stuck workflow instances even when the SWPR transaction cannot restore

Business Scenario: This manipulation has a number of uses, but for our demo we will consider the following scenario. In the workflow to send e-mails to outlook we use the send-mail step in the workflow. The e-mail ID is generally retrieved via a background task prior to calling the send mail step. This e-mail ID is retrieved from SU01 (User Master) or Info-Type 105 (Communication Info Type) Subtype 10. Many times it happens that the business forgets to maintain the e-mail ID. The e-mail ID is not retrieved thus and the e-mail step in the workflow goes into error putting the whole workflow into ERROR status. Simply running SWPR (Restart Workflow after ERROR) T-Code after maintaining the e-mail ID will also not help since the e-mail retrieving step has already executed and workflow is stuck at the e-mail sending step. Restarting the complete workflow will not be acceptable to the business since it will start the approval process again from the start, thus wasting precious business time.

It is at this difficult scenario, this container manipulation technique will come to your rescue.

Process: To set up a demo for this we will have the following steps

·         Build a custom workflow with just a send e-mail step with the e-mail field as importing. (Simplified for demo purpose)

·         Test-run this demo workflow via SWUS T-Code but do not pass the e-mail ID. This will put the workflow in ERROR status.

·         We will simply use SWPR T-Code first to try and restart the workflow instance. This will fail.

·         We will then modify the workflow runtime container and pass the e-mail ID.

·         We will restart the workflow via SWPR again. It will work this time.

·         We can check in SOST to see that e-mail is sent via SAP-Connect.

Pre-requisites: To follow and set up this demo, following are the pre-requisites

·         You should know how to build a basic workflow with the send e-mail step.

·         SCOT and SAP Connect must be configured for e-mail sending.

·         All other workflow configurations via SWU3 are already done.

Building the Custom Workflow with the send e-mail step

The e-mail ID container created is as shown below. It is marked as importing, but not mandatory

The e-mail step will contain this container EMAILID as the e-mail ID variable

After building the custom workflow with the send e-mail step, it will look as shown below

Testing the demo workflow

Now run SWUS T-Code and enter this workflow template ID to test. Test run the workflow without passing the e-mail ID (simulates missing e-mail ID).

It will look as shown below

Now we will check the workflow log. We can see that the workflow is in error

The Step History of the work item will tell us that the method to send mail could not execute

The container shows that there is no e-mail ID in the Address Strings field

Now we will run SWPR to attempt to restart this workflow instance. The work item ID is 2733489 for the e-mail step.

The work item ID of the workflow (Parent ID) is 2733488. Enter that in SWPR

<iframe id="aswift_2" style="position: absolute; top: 0px; left: 0px;" name="aswift_2" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" width="728" height="90"></iframe>

Now select the above row and click on “Restart Workflow” push button on the application tool bar

The application confirms that the restart has been carried out. Press REFERSH button to see if the restart was a success

We can see the item is still there. Looking at the workflow log and step history, we see that the workflow went into ERROR even after the restart  

Note that the restart operation is shown, but still it went into error after that.

So simply running SWPR transaction will not work in this case.

Modify the container value at run time:

To modify the workflow container value, we need to run the function module

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 of the e-mail step is 2733489

Pass this work item ID to the function module as shown. Do not pass anything to the DISPLAY parameter

Now on executing this function module, the complete container list of the work item step is shown in EDIT Mode!!

This is the Container Instance Editor

<iframe id="aswift_2" style="position: absolute; top: 0px; left: 0px;" name="aswift_2" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" width="728" height="90"></iframe>

Now select the container Recipient Name and pass a valid e-mail ID. In business scenario, you can get it from user master (SU01) or Info Type 105 Subtype 10.

Select the container and click on APPEND ROW

Enter the e-mail ID

Now press the ENTER key to accept the changes on the pop-up

Now go back to the workflow log and refresh to see if the e-mail ID shows up there.

BEFORE REFRESH: Address Strings is empty

AFTER REFRESH: Address Strings has the e-mail ID now (shows as “1 entry” and appears on the overview below)

The workflow is still in error. So we run SWPR again

We press the REFRESH to see if the restart was a success

The item has gone away, indicates a success. We will verify from the workflow log

<iframe id="aswift_2" style="position: absolute; top: 0px; left: 0px;" name="aswift_2" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" width="728" height="90"></iframe>

Note that the workflow has executed the step without errors. Note also that container value change operation is also captured in the logs.

Showing the graphical log to verify

The active-x log is also show

Running SOST T-Code, to see if the e-mail is out

Conclusion: Thus with this process, we were successfully able to modify and manipulate a workflow container value from the runtime instance and also successfully restart the workflow instance exactly from the point where it went into error.

Disclaimer: Use this function module with caution. Be very careful while changing the container values. Only workflow administrators should do it. Please remember, you activity is logged in the workflow logs, hence perform the activity only when the workflow is stuck in error and there is no option to restart from the very beginning.