Another 10 Common Mistakes made by Workflow Beginners

Here are ten more common mistakes made by SAP workflow beginners. An earlier blog discussing the numbers #1 – #10 can be found here.

 

Have a laugh at my missteps, and make sure you don’t repeat them!

11. BOR: Referencing Z subtypes instead of the supertype

 

This has to be the most common beginners’ mistake, and yet is perfectly understandable.

 

If you delegate a BOR object (say BUS1006 – business partner) to a sub-object ZBUS1006, you should still always refer to ‘BUS1006’ in your workflows, tasks and event linkages.

 

That’s right: ‘ZBUS1006’ should ONLY be used while creating the BOR object and setting up a subtype.

 

Otherwise: nunca / never / nimmer / niemals / aldrig / jamais!

 

Don’t do this

 

Here are some of the reasons:

• when you search for workflow instances that use object BUS1006, you now have to also search for ZBUS1006
• when you see an explicit reference to a Z* object, you don’t know if it has been copied or subtyped
• it also presents difficulties when searching through an alphabetical list of events (Z* is a long way from B*)
• if you only ever refer to ‘BUS1006’, you can easily switch to a new subtyped object (e.g. ZBUS1006V2) and your workflows won’t miss a beat..

 

12. Not catering for all outside events

 

This is a blunder I have made many, many times. Just because you have built a great workflow for approving (say) leave requests, this doesn’t mean that users will instantly change their habits. No, they will still get desk visits, and they will still approve the leave request through the old SAP transaction.

 

If your workflow doesn’t recognize that this has happened, then you have a big problem. Users will ring, asking you why they have to approve something twice; or the workflow will go into error when it tries to change a request that is already approved.

 

So you need to consider all possible terminating events – ‘Approved’, ‘Withdrawn’, ‘Changed’, ‘Deleted’ etc.

 

Functional specifications rarely mention these scenarios, so it’s up to you to include them.

 

 

13. Not setting deadlines based on the factory calendar

 

When a business analyst specifies that they want a reminder sent after 5 days, they usually mean 5 working days – weekends and holidays don’t count. It seems obvious, but is often missed.

 

To implement this you need to specify the use of a factory calendar in your workitem deadlines.  The workflow book shows you how.

 

Copyright (c) 123RF Stock Photos

 

 

Even if your business runs 24/7, it still pays to use a factory calendar to cover all eventualities – e.g. future changes or Christmas shutdowns.

 

Be careful though – if you choose a custom factory calendar make sure it is correct and maintained well into the future. Otherwise – as reported in SCN – your workflows will stop dead when the calendar stops.

 

 

14. Over-complicated workflows

 

When I arrive at a new site, the first sign of trouble is a workflow definition that looks like a tangled ball of spaghetti.

 

 

Pasta Chikatetsu (source: www.tokyometro.jp)

 

It’s pretty rare that all this noise and fury is really needed to implement a mundane business process (such as PO approval).

 

Typically, such workflows contain:

1. A string of container operation steps, which serve as ersatz initializations
2. Numerous activity steps that do nothing more than call a method to ‘get’ a value (e.g. a user’s email address)
3. Unnecessary Sendmail steps
4. A long list of workflow container elements that, really, are just object attributes
5. A sprinkling of undefined steps (why oh why?)

 

Justify your existence

 

Does this sound like one of the workflows at your site? Here’s how to clean it up:

1. Initializations: use the ‘initial’ tab on the workflow container element instead
2. Use object attributes (as explained further in #12)
3. Delete SendMail steps that simply warn the user of a workitem. Use Extended Notifications instead
4. Again, use object attributes
5. Delete delete delete!

 

And once you’ve done all that, consider trashing the whole thing. 😎

 

In my experience, workflows are often built ‘on the fly’, as requirements are drip-fed or regularly changed. Once you finish the build, it’s worth considering whether to redesign from scratch.

 

Why? I like to think of a workflow definition as a LEGO(tm) house, where the tasks/steps are LEGO(tm) blocks. It’s no problem breaking it all down again, just to see if you can design something sleek and elegant using the same steps.

 

Simplicity is so underrated.

My first workflow

 

Small, sleek & reliable

 

15. Using ‘get’methods instead of attributes

 

This item ties in with #14. It is a common mistake made by folks who are used to procedural programming and not so comfortable with OO concepts.

 

Does your workflow have a step called ‘Get User Name’, based on a method ‘GetUsername’, which fetches user data and stores it in a workflow container called ‘Username’? Which is then bound to a task container element ‘UserName’, just so that it can be used in the workitem text?

 

Sounds just like a traditional ABAP program 🙂

 

All this complexity can be avoided if you instead define a (virtual) attribute called ‘Username’ that is automatically populated when the (‘UserID’) object is instantiated. The workitem text can then just use ‘Userid.Username’.

 

 

Note: Of course, you have to use your judgement in this. If the determination of an attribute is very expensive, you may not want it executed every time an object is instantiated. In this case, a GET method might be the best approach.

 

 

 

16. Allowing multiple copies of the same workflow to be started for the same object/event

 

Very typical beginner’s error. I can’t believe we didn’t put this in the top 10.

 

You create a workflow for approving changes to a PO. It gets triggered when they change a field from ‘Ted’ to ‘Fred’. But should another 3 workflows be triggered if (before approval is granted) ‘Fred’ then becomes ‘Ned’, then ‘Ed’ and finally ‘Mildred’? Uh, no. Users hate this; which one should they approve?

 

You could set a ‘check function’ on your event linkage, so that no new workflow is started if an active workflow already exists for the same object. Or, when a change occurs, raise an event to terminate the existing workflow and start a new one.

 

 

17. Panicking when you see ‘No Agent Available’ in the workflow log

 

Don’t worry – it doesn’t mean that the workitem can’t find an agent. It just means that no one has started processing this dialog workitem yet.

 

Perhaps a better translation from the German would be ‘Not yet started’ or ‘Waiting to be processed’.

 

NOTE: In transaction SWIA (Process Work Item As Administrator) the text is displayed as ‘No Current Processor’.

Don’t worry about it, be happy.

 

18. Using dummy wait steps of arbitrary length

 

Some workflows are punctuated with wait steps – dummy steps that call a dummy method that has an ABAP statement like WAIT UP TO 100 SECONDS in it.

 

Apart from being inelegant, you should question why a ‘wait’ is required and whether 100 SECONDS is long enough. Or perhaps too long. Wouldn’t that depend on how busy the system is? And might it not change over time?

 

Typically a ‘wait’ step is inserted because you need a process to finish before you can continue – for example, the business partner has to be fully created before we can change it. In cases like this, a ‘wait for event’ step might be more appropriate.

 

Another option – e.g. in locking scenarios – is to use temporary exceptions.

 

 

19. Paying lip service to OO design

 

I sigh loudly when I see custom events with names like ‘StartApprovalWorkflow’.  That name does not describe a real ‘event’ in the life of a assessment document.  (And it leaves open the mystery of where this event might be raised…)

 

In contrast, here are some real-life object events: CREATED, CHANGED, REJECTED. If you want to start an approval workflow, you should figure out which event(s) should trigger it, not invent a bogus one purely for workflow purposes.

 

For example, if an assessment needs approval when it’s CREATED or CHANGED, then you can simply link the approval workflow to these two events (via SWE2).

 

Similarly, the methods of an object should represent ACTIONS on that object. Don’t shoehorn a ‘Sendmail’ method onto a SalesOrder object, just because you can!

 

 

20. Developing custom programs to change workflows / workflow containers

 

This chimera comes up fairly regularly in SCN – a misbegotten idea to write a report that will automatically approve / forward / obsolete some outstanding workitems. That’s bad enough, but much much worse are programs that seek to ‘pop the bonnet*’ and directly update container values from outside the workflow.

Good luck trying to understand your workflow log, once programs like that start messing with it!

 

If you feel you have to resort to such measures, then you probably need to study up on workflow features and design principles. Pretty much all of the above can be handled through modelled deadlines or terminating events.

 

geniet!

Paul Bakker

 

*North American readers might say ‘pop the hood’