Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

Workflow Debugging

First of all, you cannot set breakpoints in a workflow, so I assume you mean that you have set a break-point in a method used in one of the task's used in your workflow?

If so, and if this task-method is a background method (i.e. a non-dialog task), debugging is not possible, since a background method, as the name states, is executed in another context in background.

With SAP Note 2197117 you can now debug background tasks:

  1. In the relevant background method, set an external breakpoint.
  2. Activate the workflow debugging with the new transaction SWW_BREAKPOINT.
    • The debugging of the workflow runtime system can be activated for a workflow. Enter the relevant top-level workflow in the field "Top Task". With this configuration, the debugging is activated for all background work items started from within the context of the current user. A simple case, for example, is the restart of an incorrect workflow.
    • If you also want to debug methods that are started from within the context of an event, enter the name of the object type as well. As a result, the debugging is activated for all use cases (such as start events, termination events, and so on).
    • The workflow breakpoint is active for half an hour.
  3. After you have executed the actions described, the workflow debugging is active. After the relevant workflow activity (such as restarting) is executed, the external debugging of the ABAP runtime is activated. In a new mode, the system displays the debugger in place of the source code at which you set the external breakpoint.

To see how the workflow passes values from/to the different container's, you can use transaction SWUD (to see if the values needed for your method, are binded correctly).

Other useful tools for workflow error search, are: SWEL (first turn on even trace with SWELS) or simply look at the workitems created to see what kind of errors they may have encountered: SWI2_FREQ f.x.

If background task, I recommend you use SWUS for the specific task in question to create a WorkItem. Find the workitem with SWI2_FREQ, then display it. From there, display Container, to see the outcome.

You can debug the method, from SWO1 for the Object Type owning the method. From SWO1 simply click the test button. Then click "create instance". Execute the method for the object instance and you will be able to debug the method.

Generating Sub Workflow

1. Add one of your subflows to the main workflow as an activity step and define the binding. This subflow is just a place-holder and will be replaced by another subflow when the workflow runs.

2. In the step definition specify "Task to be determined using an expression" and specify which container element (or expression) contains the subflow ID to be used.

At run time, the place-holder subflow will be replaced by the subflow that is specified by the expression. In other words this expression reads the table that you created to find the subworkflow to call and this subworkflow is called by the main workflow instead of the (static) place-holder subflow.

Finding out the Object Types involved

  • Switch the event trace ON (Tcode SWELS), carry out your transaction and view the event log (Tcode SWEL).
  • If there is a standard event then the trace will tell you the name of the object and the event raised.
  • Otherwise create your own object and events and trigger it (them) using FM "SWE_EVENT_CREATE".
  • No labels


  1. Great!!!

     And thanks.