workflow_debugging[1]

(1)

1

Testing and Debugging Workflows

Susan Keohan

Massachusetts Institute of Technology October 21, 2001

Workflow/WebFlow Track

“Where making your work flow is our business”

My name is Susan Keohan. I am the primary workflow developer and administrator at the Massachusetts Institute of Technology. We have had workflow up and running for several applications since 1997.

I am also the ‘owner’ and administrator of the SAP-WUG listserv, and the Workflow Track Leader.

My experience with workflow began with implementing a Req Release workflow. Then MIT developed several types of FI release workflows, and some single step background tasks. We have used workflow as the delivery mechanism for notifying our customers that they have workitems, by sending notification emails. This is not the most sophisticated method of notifying users, but one which fit our culture and infrastructure.

Since implementing our workflows, we have upgraded from 3.1 to 4.5, and from 4.5 to 4.6. I have also converted our WFs to WSs.

(2)

Testing and Debugging workflow can be a very challenging task. My goal here is to help you identify

(3)

3

Testing and Debugging Workflows

• Business object builder

- Attributes - Methods

• Events

– Event linkage - Event test tools

- Event check FMs, receiver type FMs

• Roles

• Workflow analysis

– Diagnostic tool

My intent is to use a bottom-up approach here. I have found that one of the first things you do as a workflow developer is to look at the business object to see if it has what you need in the way of attributes and methods. In every workflow project I have worked on at MIT, I have had to add attributes or methods to extended business objects, so that seems like a good place to start. Once you have debugged your attributes and methods, (assuming you then build your workflow) you will need to know about linking it to an event (this is the most commonly used means of triggering a workflow)

Then you will want to know why your workflow didn’t get to the right person. At the end of it all, there is the very powerful tool provided by SAP which allows you to perform a variety of tests from one transaction.

(4)

Debugging With BOB

Pick the attribute or method you need to debug, and push the ‘Program’ button to get

to the ABAP code…

The Business Object Builder (as it is called in 4.6c) 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.

It is inevitable that you will 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 a Fund Center which can be linked to a requisition, but at MIT, we can’t live without it. It controls the entire flow of requisition release, even as far as determining which req release workflow will be called.

You may find that you need to create an attribute of an object which uses the object key to derive a value from another object, or document. Or, you may have customized tables which hold values that you want in your workitem text.

(5)

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

breakpoint there.

I have found it helpful to have any macro calls (SWC…) early in the code, and set my breakpoint after the macro call.

(6)

Debugging With BOB

Set the debugger on and use the

wrench

BOB comes with a test bed from which you can execute the ABAP code that underlies your attributes and methods.

After you have set your breakpoint in the ABAP code, go to

Settings>Debugger On/Off and switch the debugger on. This turns on the ABAP debugger.

(7)

7

Debugging With BOB

Push ‘Instance’

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.

(8)

Debugging With BOB

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

(9)

9

Debugging With BOB

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.

(10)

Debugging With BOB

Just push the ‘go’ icon for the method you

need

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.

(11)

11

Debugging With BOB

Don’t forget to push the Debugging Button

This screen shows the input elements that are required for the method, and the exceptions. You don’t necessarily need to fill these in, but you can.

(12)

Debugging With BOB

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.

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.

(13)

13

Debugging With BOB

• Set a breakpoint in the code of attribute (or method), before things really get ‘interesting’

• If you have calls to macros (swc_get_element, etc) you *may* need to set the values of the result elements inside the debugger (for example, when getting an element from the workflow container) • You can then step through debugging the attribute or method as you would any other ABAP code

• You probably want to step OVER the macro calls. They can be mildly disturbing, and it serves no purpose to go there.

(14)

Debugging Events

• Event linkage in the workflow

• Event linkage (SWETYPV)

• Event creation (SWUE)

• Simulate event (SWU0)

• Check the event log (SWEL)

• RFC queue (SM58)

There are multiple ways to trigger and control the flow of a workflow, but the most commonly used is via events. They can be used to start and end

workflows and workflow tasks.

You need to know how to look at the event linkage to the workflow from both sides, that is, from the workflow to the event, and from the event to the

workflow.

You also need to know how to check that the event is actually being triggered (just because an event is listed, does not necessarily mean it will be triggered. It could be linked to some obscure customizing!)

You will want to be able to simulate the event, to check what happens if you know the event has been triggered but for some reason your workflow did not start, and to see if your workflow did start, but failed immediately.

(15)

15

Event Linkage in the Workflow Definition

This is the event you want this workflow to

start with

Always check your binding to

the event

Go into the workflow builder (PFTC_CHG in 4.6c) and check the Triggering Events’ tab.

The panel should show you all the events that your workflow is linked to. A workflow CAN be linked to more than 1 event.

A green light to the left of the event means that your linkage is active. When you press the gray button (i.e.: it’s not green yet) you will be given some binding messages. Always check your binding to the event.

(16)

Event Linkage With SWETYPV

The checkbox tells you this event is linked to a workflow, well, sort of…

In SWETYPV you get to look at the event/workflow linkage from the event side. You will be able to see the object, event, and the receiver, as well as if the linkage is active.

However, you cannot rely on this table alone to tell you what workflows are linked to an event. You must have

(17)

17

Event Linkage With SWETYPV

Workflow Name

Note that this is ACTIVE

for example, in this case, you would need to double-click on this event to see that in reality, there is a receiver type function module which will determine which of several workflows will be called when this event is triggered. In effect, this is a dummy entry.

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.

(18)

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!)

(19)

19

Event Triggering With SWUE

Use this flag to start the ABAP debugger

Fill in the Object Key of the object you are working with

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. (However, you will have to know this, so don’t think you are getting off scot-free). For these purposes, you can use the test tool SWUE to create the event.

After you fill in the object key, and click on the ‘Trigger Receiver FM Synchr’ flag, then push the ‘Create Event’ button

(20)

Event Triggering With SWUE

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.

(21)

21

Event Triggering With SWUE

Set the breakpoint in your receiver FM first,

then when you check ‘Trigger FM synch’, you

will get to your breakpoint

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.

(22)

Event Simulation With SWU0

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

(23)

23

Event Simulation With SWU0

Check the statuses of the workflows.

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.

(24)

Using the Event Log SWEL

Workflow Object Key

Not necessarily!

In the development system, I have always found the event log to be helpful. Once you get your workflow to start once or twice from the event, and you want to just let that puppy run, you will need to have the event log switched on (swels) for a while. This way, if your workflow fails to start, you have this report on the event log to go back to, and perhaps, find out why.

When a new workflow goes into production, you can have the event log 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.

(25)

25

Errors in the Event Log (SWEL)

Here is an example of what errors look like in SWEL. But please note: not all of the red indicators are errors from a workflow perpective. Sometimes they will be indicative of other types of errors, such as errors in configuration.

(26)

Errors in the Event Log (Drill Down)

Now, at least I know where to begin debugging again

I guess from here, I would go back to SE37, set a breakpoint in my FM, and use SWU0 to create the event again.

(27)

27

SM58 (or Program RSARFCRD)

Another reason your workflow may not have triggered, could be an error in the Remote Function Call processing.

You could check this transaction if your event log merely shows an exception as the receiver type.

(28)

Errors in the RFC Queue

By running SM58, you should get a better idea of why the receiver did not start. In this case, the user had changed a four year old requisition, and there was no master data in the PD Org structure to support the req release

(29)

29

What Is the Event Passing ?

Specify your username

Specify SWE_EVENT

_MAIL

I only just learned about this neat trick, and I hope you will enjoy it. If you know the event is being triggered, but cannot tell what is being passed to your workflow, create an entry in via SWETYPV, and specify your username as the RECEIVERTYPE and the Receiver FM as SWE_EVENT_MAIL.

(30)

Mail…

(31)

31

What Is the Event Passing ?

These are the container elements passed by the event

And it includes all the information that the event passes!

(32)

Workflow Did Not Start

• If the event was triggered, but the workflow

still did not start, it is likely the object does

not yet exist in the database. In this case,

you may need to use other methods to get

the object information into your workflow

(while the database commit gets

performed).

• Use the event simulation transaction

(SWU0) to see which workflows are linked

to the event, and what their statuses are.

(33)

33

Role Resolution – Who’s Got the Workitem ?

Function Module to be executed to determine

who the agent of this workitem is I like this, because I’d rather get an error, then

have the whole world get the workitem! This icon will simulate

the role

While you can specify the job, position, or org unit that is supposed to get the work item, more often, 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

(34)

Simulating the Role Resolution

Fill in your object attributes (required import parameters)

Then push the wrench to see if your role returns

any agents

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

(35)

35

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

(36)

Debugging the Role Resolution FM

You will need to set these values after control returns from

(37)

37

The Diagnostic Tool, SWUD

The current workflow to be analyzed

List of test options

Last 10 workflows

At last we come to one of the most powerful testing tools available.

SWUD is your single point of contact for performing diagnostics from the most basic (is the workflow customizing set up correctly) to more complex (‘Task does not start’, ‘Workflow is hanging’)

(38)

Using the Diagnostic Tool, SWUD

The options from here are:

• Verify workflow customizing

• Problem: task does not start

• Problem: workflow is hanging

• Test environment

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.

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.

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.

(39)

39

Using the Diagnostic Tool, SWUD

From ‘Text Environment’ you have a wealth of diagnostic options, including enabling the workflow trace, and turning on the container monitors.

(40)

SWUD- Consistency Check for Components

Even experienced workflow developers make binding errors

This is just an example of one of the tests that you can get from SWUD. This consistency check for components (including sub-workflows) can even show you binding errors..

(41)

41

The Container Monitor

The container monitor can be switched on from SWUD, and then you can start the workflow. When a task is executed, the contents of the container are shown in a dialog box. This is useful if you can’t determine exactly what is being passed from one task to the next.

(42)

The Workflow Trace

The workflow trace can be turned on from SWUD, or from SWU8 (you would use SWU9 to display the trace.)

This trace gives you a very detailed picture of what is going on inside your workflow, from workflow to task, and so forth.

Double-clicking on a CONTBINDEXECUTE step will show you the details of the binding.

(43)

43

Workflow Trace

Here is another view of the workflow trace. Again, you can drill down for details on the binding, and you will see information similar to that of the Container Monitor. The difference is, the Workflow Trace will track all steps, dialog or background, and will live for the duration of the workflow.

It is advised that you do NOT have the workflow trace turned on (or leave it turned on for any length of time) in a production system.