Workflow Troubleshooting and DebuggingWorkflow Troubleshooting and Debugging

Introduction:-

As business requirement are mapped into a Workflow process definition. DEBUGGING becomes an essential tool to

expedite the implementation of WF process.

But before that user should be familiar with basic WF configuration and development.

Like what is WF type :  'TS' for Single step task  and  'WS' for Multistep task

Since WF has many different elements, starting the debugger is not as straight forward as with a standalone ABAP program.

Each WF consists of several components: Event, Task, Method, Rule.

*When should WF starts?   

*What TASKS need to occur?     

*Who performs the Tasks?

We have to pass the data from one container to another. If we are having problem in any of the container then it will give you

wrong result.

So we have to be careful while doing binding.

EVENT    <> Workflow <>           TASK   <->            METHOD

As we proceed we will review Debugging techniques used in each of the Components.

 EVENTS DEBUGGING:

WFs are primarily triggered based on events generated by applications. Event are used to trigger/terminate our

workflow/task.

Once the basic Configuration setting is done like prefix numbers and RFC destination is done by BASIS people.

Then we expect that our application to trigger events that will start WF.

Application Program -> Event -> Workflow

First we have to find out the transaction linked with our business application.Like:

For Purchase Order Change -à Tn Me22n

For Material Change à Tn MM02Then we have to find out the Business Object and Event name corresponding to

the application program.

There are two ways:

1. Tx BAPI---It will give the business Object name. Like

For Purchase Order à BO - Bus2012

For Material Chnge à BO - Bus1001

2. Use txs: SWELS , Application Program , SWEL

a.> Turn ON the event Log with Tx SWELS

b.> Re-execute your application program or transaction.

c.> Display the event trace by using Tx SWEL.

Then (SWEL) Event Trace will show you the Business Object name and Event name.If you are not having any trace for your

event then there can be many problems like:

Problem1: Event linkage

When we go to Tx SWI1 and notice no WF exists at all. That means no workflow is triggered.So we will see some standard

sap Txs

before we start going through the Program in debug mode.

Solution to Problem1:

By executing above steps 2. , if there is a standard event then it will tell you the name of business object and event.

 Otherwise create your own object and events and trigger it .

There are number of ways by which we can trigger an event.

Using SE38 editor program and use FM "SWE_EVENT_CREATE.

Use change document to trigger a Event. For change document you can use SCDO Tx.

Here we can create and easily find out the required Change document for our application.

After triggering your event if Event trace shows 'no event receiver found'.

This error is typical if the event linkage is not set up or not active in tx SWE2/SWETYPV . By Reviewing SWE2 we notice

that the type linkage was not set to active.

To resolve the issue activate the event linkage and be sure to save the entries.

Or

Click on new entries tab in SWE2/SWETYPV. And fill all the details:

Object type, Event, Receiver type(Workflow no.),Receiver function Module. And mark the check box Linkage Activated.

Now the created entries would come in SWE2.

If you execute transcation SWEL , after your application program execution then it will show the event trace in SWEL.

NOTE:

1. In Production, you can have the event log(SWELS) turned ON. But you are advised not to leave it ON for an extended

period of time,

as every event that occurs in the system, whether linked to a workflow or not, is logged in this file, and this can overburden

the database system.

2. Ideally in Production environment if WF did not start when it should have ,we would want to manually start it.

We can do this by using tn SWUE (create event) or SWUS (start WF).

Event Triggering With SWUE :- CREATE EVENT

You will probably need to test whether a workflow will be triggered by the event without always having to go through the

business process of creating a new object instance every time.

 For these purposes, you can use the test tool SWUE to create the event.

After that you fill all the details in SWUE like BO, Event name. Then enter the object key, and click on the 'Trigger Receiver

FM Synchr' flag, then push the 'Create Event' button.   

 This screen shows you the event and the receiver when a breakpoint has not been set. It can be a quick test to see that the

workflow will be triggered.

But, if you can't tell why your workflow is not triggered, you will need to go a little deeper.

Go to SE37 and set a breakpoint in the receiverFM, checkFM, or receiver type FM that is being called.

Back out and go into SWUE and fill out the prerequisite key. Remember to check 'trigger receiver FM synchr'. When you

push 'Create Event',

you get into your function module at your breakpoint, and you will have the necessary parameters and object elements to

proceed with debugging your FM.

Tips:

What is Check FM or Receiver Type FM ?

• A check function module can be used to simply abend if the object does not meet the

criteria for your workflow (i.e.: It's not the correct document type)

• A receiver type FM can be used to dynamically determine which of a number

of workflows should be called based on object attributes (much more efficient than

many check FMs!)

This function module will determine which of several workflows will be called when this event is triggered.

If you drill down on the event, and you see the receiver FM SWW_WI_CREATE_VIA_EVENT, and no receiver TYPE FM,

 then it is reasonable to assume that the workflow (identified by 'receiver') is going to be triggered by this event.

3. SWU0 Tx: EVENT SIMULATION

The Event simulator is a quick way to tell if your workflow is a candidate for

starting. It can also tell you what other workflows may (or may not) be linked

to the event.

You must examine the individual statuses of the workflows to determine the

cause for the problem. This tool is a very informative overview of what could

happen if this event were to be triggered.

  

Problem 2: Event Parameters

In events , we have Event Parameters that are required in WF that are not being passed from the event trigger.

In addition , we expect values that we are not seeing in WF.

So we want to review the code to determine what parameters are actually getting passed from the application to the WF.

Solution to Problem2:

Review the event binding in the Work item. Use Work Item display tx-SWI1.Simply execute this tn.

Consider entering date/time to reduce selection to specific WF.                                    

Also select checkbox in output options tab to get additional information like Workflow no. and agent.

Display the WF log for selected item by clicking on the 'Scroll' icon.

click on 'Matrix or display entries' icon. It will show the technical details.

This will show you that your WF is started or in which step we are getting error.                                                        

 Click on the WF container icon. The container displays the event parameters passed through application to WF.

NOTE :

Ø  If u expect additional event parameters to be passed..check the WF Definition via tx PFTC or SWDD.

Make sure that Binding b/w WF and EVENT has been set up correctly.                       

 Most of the time error comes just because of incorrect binding.

Ø  If you want to send a mail when a particular event has been raised?

1.Go to SWETYPV -> Create New Entries.    

 2.Enter BO, Event name.               

 3.Enter SAP UserID in "Receiver Type" and SWE_EVENT_MAIL as "Receiver FM".  

 4.Set type linkage to ACTIVE.

Whenever the event is raised, an SAP office mail is sent to SAP UserID. From this  mail u can check the container element

of that particular event.

AGENT RESOLUTION DEBUGGING

Role Resolution - Who's Got the Workitem

There is a need to determine the agents for a workitem via a standard role.

And often this will mean that you need to have a custom ABAP function module to fill that role.

Once you have defined your role and your role resolution function module, you can debug the role, including the parameters

which it must pass to your function module.

This is a quick way to see if your role resolution is returning any agents.

However, for more detailed debugging (when your role uses a Function Module) you will have to use the test bed from

SE37.

Debugging the Role Resolution FM

• Go to SE37 and enter your function module name

• Choose the wrench ('test/execute') tool

• On the next screen, push 'debugging'

• You will be taken into the ABAP debugger

• Note: you will not have the 'workflow context'

Programming Tip:

Do not classify task as general task. Define the task assignment in organization model concretely. Every user should only be

a possible agent of very few task.

WORKFLOW TASK(METHOD) DEBUGGING

In every workflow project , we have to add attributes or methods to extended business objects. Here term 'Delegation'

comes in picture.

https://wiki.sdn.sap.com/wiki/display/BOBJ/Business+Object+Delegation

This link is having the whole procedure for delegation.

The Business Object Builder used to be called the Business Object Repository (BOR) and is accessed via transaction

SWO1.

It is from this point that you will create a subtype of an existing SAP object type, and give it your own specific attributes and

methods.

Usually there is a need to add attributes or methods to business objects.

These enhancements will reflect your organization's view of the business object being worked on. 

 For example, it may not be relevant to the rest of the SAP world that there is any customized method which can be linked to

a standard BO,

but in our project, we can't live without it. It controls the entire flow of business process.

At any rate, once you have defined your attribute, or method, it is helpful to step through it in the BOB before you try to add it

into a workflow.

Locate the portion of your attribute or method that you want to test, and set the breakpoint there.

 Then, use the wrench tool to start the debugging process.

From this screen, you will need to enter an object key for the BOB debugger.

Just push 'Instance' and fill in the values with a document you have already created. 

After you push 'instance' you should get a pop-up screen where you can enter the key values for the object.

The BOB will display all the attributes for that object. This enables you to quickly view whether the values are as you

expected.

The circling arrows icon will indicate which attributes are virtual attributes.

The pretty green and yellow ring indicates that this attribute is also an object reference in its own right.

If you scroll down on this page, you will also see all the methods which are linked to that object.

Testing methods - push the go button for the method you are interested in. Remember, at this point,

you would have set the breakpoint in the method code, turned the debugger on, and filled in the object key for an

instance to be worked on.

Don't forget to push the Debugging Button. You will be brought into the ABAP code behind the method.

From here, you can step through the code, much as you would any other ABAP program. There are some

differences though.

Suppose You executed this Method Zmam which is used for addition of two numbers num1 and num2.

The result is being stored in num3.Then after debugging the final screen will show you the result.

  

You may need to fill in some elements manually. Watch to see if you get a Sy-SUBRC =8 after any macro call. Some of

them, for instance,

SWC_GET_ELEMENT CONTAINER 'ReleaseCode' PRELEASECODE.

Will not be able to get the value, as the BOB does not have the context of the workflow to derive container values from.

Simply fill these in as you go along.

TIPS: Debugging a background Workflow Process:

 In  method write the following code:

Data: exit.

Do.

If exit = 'X'.

Exit.

Endif.

Enddo.

Run the Workflow,causing an infinite loop on that step.And then go to SM50. Here you can debug the process.

SWUD-Diagnosis Transaction

SWUD is the very powerful tool provided by SAP which allows you to perform a variety of tests from one transaction.This will

guide you through the fault finding process.

It allows you to access the tasks , subflows, object types, delegated object types and agent assignment directly, without

going through the workflow builder first.

Using the Diagnostic Tool, SWUD

The options from here are:

• Verify workflow customizing (SWU3,SWUB)

• Problem: task does not start

• Problem: workflow is hanging

• Test environment

1. Verify workflow customizing

Verify Workflow Customizing will take you to the screen where the most basic (and often most crucial) parts of workflow

customizing are done,

 such as maintaining the workflow administrator, and ensuring that the RFC destinations are configured correctly.

2.  Problem: task does not start

Task does not start takes you to another screen from which you can find all instances for a task, refresh the org

environment, and run a consistency check on your tasks.

3. Problem: workflow is hanging

Workflow is hanging checks for all instances of the task, checks the RFC logs,checks the ABAP dump analysis, and

provides a consistency check for the workflow components.

4. Test environment

The test environment is where I end up going the most.

       It will show the all the task and Business Object we are using.

       It will show all the instances executed till now for given WF.

Secondary Diagnosis Transaction:

SWU3---verify Workflow customizing

SWE2/SWETYPV - Event type linkage

SWEL - Event Log

SWELS - To On/Off Event log

SWU0 - Event Simulation

SWI1 - Work Item list

SWUE - Event Trigger

SWUS - Workflow Trigger

PFTC/SWDD - Task editor/Workflow Builder