source:http://wiki.sdn.sap.com/wiki/display/ABAP/Debugging+workflows+and+generating++sub-workflows
[b]Workflow Debugging[/b]
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.
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.
[b]Generating Sub Workflow[/b]
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", or use Tcode SWUE.
[b]Workflow Debugging[/b]
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.
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.
[b]Generating Sub Workflow[/b]
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", or use Tcode SWUE.
15万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
