Mistakes of Workflow Beginner

Generated by Jive on 2015-05-20+02:001

SAP Business Workflow: The Top 10Mistakes made by Workflow Beginners

Posted by Paul Bakker Feb 7, 2013This SAP workflow blog the third in an overly-ambitious series spotlights the top 10 mistakesmade by workflow beginners (aka noobs). I can truly call myself an expert in this area, becauseIve 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 implementationgo-live.

I confidently volunteered to take over, expecting to use my ABAP skills to debug the workflowlog 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 PaulBatey. 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 tomess 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 canonly be sent to SAP system users.

In contrast, emails are typically flat information items. Multiple copies are made and sentseparately to inboxes. They remain in each persons 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 understandingof how buffering works. But don't worry: you only need to remember to run transaction SWU_OBUF beforeexecuting a workflow that has been changed.

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

4. Flooding users' inboxes with hundreds of workitems

SAP Business Workflow: The Top 10 Mistakes made by Workflow Beginners


Ive learnt the hard way that not all approval / decision processes are suited to workflow. Ifhundreds of items are generated per day for one process, it's probably better to handle them viaa report instead.

It may just be a psychological thing, but users react violently to inboxes that they can't possibly clear (oftencompounded by a torrent of reminder emails). They either stop using their inboxes completely or clamour toget 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), thedefault 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 realisewhat happened. Then you have to scramble to fix the problem, transport it to Production, and reactivate thelinkage.



In SWEQADM, the setting should instead be 'Mark linkage as having errors'. This means that the linkage willnot 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 toSAP_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 ofthem, and dozens (re)occurring every day! Transaction SWI2_DIAG should not be considered a tool for errorhandling, 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 bemessing with internal SAP function modules or tables. These could be changed on the next release, whichmeans your code may stop working.

Instead, use a WAPI. These are the SAP workflow equivalent of BAPIs: function modules thatprovide 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 Rs 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, theircurrent 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 shouldnt need to goanywhere or click anything. (Tip: using webdynpros to render workitems makes rich displays a loteasier).

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. Thismeans the information is only one click away.



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

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 mainproblem 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? Howlong 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 andupdate 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 forreporting 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-workflow-beginners14160 Views Tags: beginner, sap_business_workflow, workflow_basics, workflow_starters,basics_of_workflow, starting_with_workflow

Miguel PeaAug 28, 2014 11:28 PMHi Paul,

A very useful post. Nice Post

TY

Paul Bakker in response to Erik Gouw on page 7



Jul 30, 2014 1:09 AMErik,

Thank you for your thoughtful feedback, however I must violently disagree with you. I have never found anyneed to replicate workflow data in Z tables, for the purposes of reporting. The amount of work (and risk) is toogreat to justify any increase in speed.

cheersPaul

Rick Bakker in response to Erik Gouw on page 7Jul 29, 2014 7:33 AMHi Erik,

I agree with Paul on point 10 but I do see your point about end users not wanting to use complicated SAPtransactions. However, the use of Z tables in this situation is something I completely disagree with. I have seenpeople spend 6 months trying to get something like that to work and then having to rip it all out again. Thereis a basic principle in database management: don't store the same information twice (aka "The man with twowatches never knows what time it is"). If reports are too slow then the problem lies with the report, not with theunderlying tables.

IMHO, of course.

regardsRick Bakker

Erik GouwJul 3, 2014 3:21 PMHello Paul,

Nice to read your both blogs on this and I agree on most items. However I totally disagree with point 10, assomeone said earlier also. Of course you must sometimes say 'no' to the business, but in a lot of cases acustom report, (prefferably based on a z-table, which is filled from the workflow, so that it is faster) is definitelyof added value. You don't want end-users messing around with these technical transactions. They need simplereports to monitor the status of a workflow or get an overview of the total situation. Sometimes it can be of extraadded vaue to add buttons in the report which trigger events that can influence the workflow.

I just wanted to say that, my of course compliments for the blog!

Kind regards,

Erik Gouw

Suseelan HariFeb 17, 2014 1:23 PM



Hi Paul,

Very interesting about 10 mistakes made by workflow beginners. I liked it very much and pics are awesome.

Keep it up!

Regards,Hari Suseelan

Partha SarathiFeb 17, 2014 1:12 PM

Nice work.. flow ..

M SantosoFeb 14, 2014 6:56 AMI have seen too many workflows developed with too many ABAP codes. And points mentioned in this blog arevalid.And turn ugly at the end with very high cost of ownership.Few more points:- Missing the whole point of SAP workflow in business (part of business process reengineering)- Missing information from workflow log- Missing the purpose of workflow-subworkflow (hard to read from workflow log)- Missing daily check and health check

Jazib TariqNov 29, 2013 8:44 AM

NIce Document

Paul Bakker in response to Tejas Joshi on page 8Nov 13, 2013 6:26 AMThank you very much. Blogging is fun.

Tejas JoshiNov 13, 2013 12:10 AMExcellent Blog ...

SAP ABAPAug 16, 2013 7:15 AMThanks a lot for sharing your knowledge. Appreciate it !!

Reginaldo MoraesJul 31, 2013 2:03 PMFantastic post ... we could use this blog as a library and continue to contribute to the group .....

Murali Krishna



Jul 25, 2013 1:55 PMNice blog Paul Bakker.

Very useful points to every workflow beginner. Your points will be solution for some queries.

It is very good to heard about SWEQADM.

Thanks for sharing knowledge. Keep posting the good blogs.

Regards,Murali Krishna.

Mohammed JafferJun 26, 2013 9:38 AMNice Blog .This is very useful for workflow beginners.Especially it is very important to note point 6 & 8 whichhelps us in workflow analysis or in case of enhancement.

Thank you so much for sharing the knowledge.

Thanks,M M Jaffer.

Hafizul MollahJun 13, 2013 9:58 AMHi Paul,this is a very good and useful blog and I think we should all keep all these points in mind while doingthe workflow related work.

Just want to share one thing from my experience is that for example the event delivery job is scheduled inevery 3 minutes and the testers do submit the request in the portal like Transfer/Comp. change and get thenotification number and open the workflow for that from tcode IQS23 immediately to see from the workflow logthat whom the worktiem has been sent.

But as the event delivery job runs in every 3 minutes immediately the event does not get deliver(gap is 3mins)some time immediately so they do contact us saying why the workflow is not initiated in IQS23 so we haveexplained this thing to them and told them to go to the tcode SWEQBROWSER and deliver the event manually.

A lot of testers do contact us specially the new joinee.

And also for our case sometimes after doing some complex workflow development when we do the testing andfound the workflow did not trigger then we do a lot of checking.

So in this case first thing we need to go to the tcode SWEQBROWSER to check has the event got delivered ornot.If no then deliver the event manually instead of checking other details.It may save time.



ThanksHafizul

Anand PippallaMay 22, 2013 7:14 PMNice blog. Webdynpros for work item display to show all information was a good one. Gives flexibility to pullmore info into the workflow, instead of writing logic or using editor to insert &variables&

Sunit SamudreMay 20, 2013 4:59 AMThis blog is worth a print!!! Many many thanks.

Kumud Singh in response to Susan Keohan on page 11May 15, 2013 2:56 PMSue,

Perhaps what I experienced sometime back sounds well with your reply above: I was asked to look into ascenario wherein a mail was triggered to the SAP Inbox of the user in case of a warning message in thetransaction and I had to find out how a similar mail could be triggered in case of an error message. Just bylooking at the triggering of an email it was assumed that a workflow is involved! As I had expected, there wasno workflow and it was our pretty familiar FM SO_NEW_DOCUMENT_ATT_SEND_API1 doing the job.

I also had a good time ( ) when 'mail' and 'workitems' were used interchangably while explaining therequirements. But I think, I succeeded in getting that rectified.

Regards,Kumud

Ragavendran KanagarajMay 15, 2013 11:56 AMHi,

Very nice post.So many mistakes in this i did while starting in workflow works.It surly helps to some one who isgiving fresh beginning in workflows.

Keep rocking dude.

Warm Regards,Ragav

Florin WachApr 30, 2013 11:12 AM

I like that ... including the follow-up post

Benjamin Krger



Apr 29, 2013 10:34 AMUnfortunately, I've found this article after I've almost finished work with my first Workflow project. Nonetheless,there are some good advices for the next projects.

May I please say something to point 10:Yes, there are many standard reports for the workflow environment, and yes, you should prefer standardtransactions to customer's reports, but mostly, standard reporting transactions are designed for heavy userwho are familiar with the system and internal objects. So imho, a Z-Report may be useful because you canmake the monitoring and administration of workflows (not of the workflow system) easier. Of course you haveto use some more tables, but on the other hand, you can combine functions in one report or one transaction,which are normally scattered over several transactions.

Sreekanth KrishnanFeb 15, 2013 4:45 PMAwesome post Paul.I have done most of these mistakes myself, in my early days.As an ABAP consultant, you tend to do these mistakes very frequently.Am sure this will be a very nice document for beginners.

Thanks,Sreekanth

Ashish SachdevaFeb 15, 2013 11:19 AMHi Paul ,

A Great Bolg For a Novice in workflow and 6th point is really useful , from my current project i will also advice

my workflow consultant about same .Thanks,Ashish

Himanshu AgrawalFeb 7, 2013 4:20 PMGreat post Paul. Glad to reading it out and in sharing to others..

Susan KeohanFeb 7, 2013 2:06 PMHi Paul,I couldn't have said it better myself! One of my (STILL) pet peeves is when people say they got 'mail' fromSAP and executed it, and then blabbity-blah happened. It is not mail. Mail comes to your Outlook inbox. Workflow delivers (not just mail, cause we can do that!) but executable tasks.

ST22, SM58, SWi2_DIAG, even SLG1 can help keep the system purring - like a non-dissected cat And customer workflow reports - oh, the pain! I have had some modest success in pushing the standard WFreporting tools, but only modest.



Thanks for #3 out of #73!Sue

Paul Bakker in response to Jocelyn Dart on page 12Feb 7, 2013 8:10 AMJocelyn - thanks for getting the ball rolling. I'm hoping for lots of comments/tips like yours.

Paul

Jocelyn DartFeb 7, 2013 5:13 AMGreat post Paul!May I humbly add:For point 7 - Include transaction SWPR to your list and also SWF_GMP.SWPR shows by default any errors happened in the last couple of days. Yes you can adjust the timeframe butall too often everyone forgets. SWF_GMP shows the count of ALL workflows in error plus a couple of othertidbits, so you can quickly see if your workflow environment is healthy or being neglected. If SWF_GMP timesout when you go into it....

REALLY BAD SIGN!

For point 9 - It's a good idea to:

a) Do decent texts up front especially subject texts. Remember that when a user is looking at an inbox this iswhat they are using to filter and sort the list of work they have to do.

b) Follow a standard for the subject text at least across all your tasks - so that people who work with more thanone workflow get some consistency - and getting business sign off on the actual texts up front can save youhaving to rework your workflow later to add 3 more variables they want in there.

For point 10. For expert users, SWI14 is an option. They need to be given their object types or classes ina handy cut and paste list, but after that it's much the same as GOS but gives you everything that's beenhappening with an object type, say Purchase Orders, over the specified period.

A fantastic list Paul and I see these all the time on sites!

Mistakes of Workflow Beginner

Documents

Transcript of Mistakes of Workflow Beginner