The Top 10 Mistakes made by Workflow Beginners

[paul_bakker2]

This SAP workflow blog – the third in an overly-ambitious series – spotlights the top 10 mistakes made by workflow beginners (aka ‘noobs’).  I can truly call myself an expert in this area, because I’ve probably done them all!

 

1. Trying to muddle through workflow using just your ABAP skills

 

I got my start in workflow back in 2004 when our 'workflow guy' left suddenly, just before an R/3 implementation go-live.

 

I confidently volunteered to take over, expecting to use my ABAP skills to ‘debug’ the workflow log and figure out how it all fit together. Ridiculous of course - I'd have more luck dissecting a cat. Within 2 weeks I had booked myself on an (excellent)  1-week SAP workflow course run by Paul Batey.  And then the scales lifted from my eyes.

 

I realised that workflow is more about 'concepts' and 'configuration' than it is about 'code'. Do not attempt to mess with it if you haven't done the SAP course (or at least partly digested the Workflow Book).

 

2. Confusing workitems with emails

 

A very common conceptual  error. Put simply, a workitem is a single piece of work - typically a decision task - that can be viewed from multiple inboxes, and disappears as soon as one agent processes it. Workitems can only be sent to SAP system users.

 

In contrast, emails are typically flat information items. Multiple copies are made and sent separately to inboxes. They remain in each person’s inbox until individually read or deleted. Emails can be sent to anyone.

 

3. Not executing SWU_OBUF before testing your workflow changes

 

I sometimes hear that workflow is 'flaky' or 'unpredictable'. And it certainly is - if you have no understanding of how buffering works.  But don't worry: you only need to remember to run transaction SWU_OBUF before executing a workflow that has been changed.

 

This applies during development, but also in Test or Production systems after a workflow has been transported in. The whole buffer is refreshed at midnight.

 

4. Flooding users' inboxes with hundreds of workitems

 

I’ve learnt the hard way that not all approval / decision processes are suited to workflow.  If hundreds of items are generated per day for one process, it's probably better to handle them via a report instead.

 

It may just be a psychological thing, but users react violently to inboxes that they can't possibly clear (often compounded by a torrent of reminder emails).  They either stop using their inboxes completely or clamour to get the workflow switched off.  No news is better than a tsunami of bad news.

 



 

Copyright (c) 123RF Stock Photos

 

 

 

5. Not changing the default 'Receiver error feedback' setting in SWEQADM

 

If you start a workflow via an event, and something goes wrong  (e.g.  a mandatory parameter is missing), the default  SAP response is to deactivate the linkage between the event and workflow.

 

Yes, you read that right; and yes, it is DISASTROUS. Any subsequent events are lost forever, until you realise what happened. Then you have to scramble to fix the problem, transport it to Production, and reactivate the linkage.

 

In SWEQADM, the setting should instead be 'Mark linkage as having errors'. This means that the linkage will not be cut, and the events will be stored until they can be safely delivered later.

 



Jocelyn D. explains it all perfectly here .

 

6. Starting workflows directly from a program, instead of using events

 

I have visited many sites where WS* workflows (and even TS* standard tasks!) are started directly by a call to SAP_WAPI_START_WORKFLOW. Bzzzt. It is far better to trigger workflows using events.

 

There are millions of reasons for this, but at the moment I can only think of five:
- you can easily switch a workflow on/off (even in Production) by (de)activating the event linkage
- you can easily switch from an old workflow to a new one, by manipulating the event linkage
- you can choose new workflows to be started by the same event
- if a workflow doesn't start for some reason, you can examine the event log (SWEL)
- there are no authorization issues with starting workflows

 

7. Falling behind in the housekeeping

 

It is wrong to assume that if users are not reporting any problems, then the workflows must be humming along. You have to be proactive and go out looking for errors, especially when a new workflow goes live.

 

We reckon there should be zero tolerance for SWI2_DIAG errors. At some sites we have found hundreds of them, and dozens (re)occurring every day! Transaction SWI2_DIAG should not be considered a tool for error handling, but a bucket of last resort.

 

 



 

Copyright (c) 123RF Stock Photos

 

Go ahead now: check SM58, SWI2_ADM1, SWI2_DIAG, SWEQADM and SWEL.

 

 

8. Using internal function modules (and tables) instead of SAP_WAPI*s

 

A common question posed on SCN runs along the lines of: what table holds the workflow container values? Who has sample code for function SWE_EVENT_CREATE?  Bzzzt  (again). Developers should not be messing with internal SAP function modules or tables. These could be changed on the next release, which means your code may stop working.

 

Instead, use a WAPI. These are the SAP workflow equivalent of BAPIs: function modules that provide a documented service, with an interface that is guaranteed not to change. For example: SAP_WAPI_CREATE_EVENT, SAP_WAPI_READ_CONTAINER, SAP_WAPI_GET_WI_AGENTS.

 

9. Not putting enough information in the workitem text

 

The three ‘R’s of workflow are that work lands on the desk of the ‘right’ person at the ‘right’ time, and that all the information they need to make a decision, is ‘right’ there at their fingertips.

 

For example, when approving a leave request, the supervisor might need to know the employee details, their current leave balance, team leave requests for the same period, and so on.

 

A good workitem text contains all – yes all - of this information.  The user shouldn’t need to go anywhere or click anything. (Tip: using webdynpros to render workitems makes rich displays a lot easier).

 



A comprehensive leave approval workitem

 

If that all seems a bridge too far, at the very least provide hyperlinks to all the relevant business objects.  This means the information is only one click away.

Too often I see workitems with telegraph-style texts like: ‘Please approve leave request #45 for USRICKB’. The poor users are left to track down the details on their own, causing frustration and delay.

 

10. Agreeing to develop custom workflow reports

 

This is one of my pet hates.  We get called in to ‘fix the workflows’ and it turns out that the main problem is actually with a dodgy workflow report .

 

In almost every project, managers request a ‘Z’ report so that they can track the progress of (say) a PO through the approval process. They want to know: Who has it in their inbox now? How long is it taking?

 

If you, as a workflow developer, cave in to these requests, you will soon be up to your armpits in Z tables and update BADIs. But all this pain adds no value at all.

 

I try to push back and demonstrate that all the reporting they need is covered by GOS, SWLO, SWI1, SWI2_FREQ and (for more detailed analyses), BI. Once familiar with these tools, they can use them for reporting on any workflow.

 

 

I probably have a few more of these and will put them in a blog later. Please share some of your own pet hates.

 

Happy workflowing!
Paul Bakker
Hanabi Technology

 

PS Here's a followup blog, listing another 10 common mistakes:

http://scn.sap.com/community/bpm/business-workflow/blog/2013/02/25/more-common-mistakes-made-by-work...