Final Update: Ok I know I'm a serial blog updater... but this time it's for the kind of news that leads soccer afficionados to pull t-shirts over their head! Thanks to the diligent offices our own workflow goddess susan.keohanand the able support of the Customer Connection team (thanks Daniel-Alexander, thanks Alan) and Product Management teams (thanks Ralf, thanks Joerg) we at last have a good answer to this gnarly old problem.
For more details make sure you take a look at the following SAP Notes to fix this for good (with a couple of manual steps) no matter what release you are on:
https://service.sap.com/sap/support/notes/1906769 - Event Linkage: Error Handling
https://service.sap.com/sap/support/notes/1906823 - Event: Default for Error Handling
https://service.sap.com/sap/support/notes/1905199 - Event: System log written for Deactivation of Event Linkage
Enjoy!
Latest Update: You wouldn't credit it - and I'm seriously considering buying a lottery ticket - but the day after I spent 2 hours explaining this setting to my current customer who has the infamous "deactivation of linkage" setting and why they needed to change it, we had one of these event linkage deactivations occur overnight. Only because I was still there that day were we able to track down the problem quickly and call out all the emergency procedures to get the event linkage turned on again pronto!
Even so it was another 4 hours of investigation, discussion and experiments to work out how to identify the affected objects and retrigger the lost events (remember evidence of the events themselves is lost), and then a a fun, fun, fun day (NOT) for the workflow support guy who had to retrigger almost 600 events manually. We were lucky - we identified the problem and got the event working before the main peak period. It could easily have been far worse - another few hours and we would have been talking thousands of events to retrigger. Needless to say they are now quite keen to change that infamous setting...
I like ice cream. I like ice cream so much I even enjoy making ice cream. It’s easy, it’s fun and it’s delicious. I love the pure, natural taste of homemade ice cream made from fresh eggs, milk, cream and sugar. I love the creativity of mashing together wonderful flavours into ice cream: lavender and rosewater; saffron and apricot; rhubarb and ginger wine; chocolate and rosemary. Delicious, and the possibilities are endless!
But I have a confession to make. I *hate* vanilla ice cream. Vanilla ice cream to me is ice cream with all the joy sucked out of it. Vanilla ice cream is the 40 cent cheap-as-chips soft-serve McDonald’s or Mr. Whippy cone full of artificial flavourings, nasty additives, unwelcome preservatives and with about as much taste as the plastic cones on the front of the Mr Whippy van. 
[Image courtesy of Stuart Miles / FreeDigitalPhotos.net]
[Image courtesy of Stuart Miles / FreeDigitalPhotos.net]A travesty of what ice cream should be.
I also like SAP Business Workflow. I like workflow so much I even enjoy implementing workflows whenever I get the chance. It’s certainly not easy, but it is very creative, and the challenge of designing a workflow that really meets the needs of the business can even be a special kind of fun. In fact, I like finding out about the business process as much if not more than the workflow. Working out why things are done a certain way and what benefit that really brings to that business. Separating out and then mixing together the various design ingredients of deep-seated needs, aspirational wants, tried and trusted habits, and unforeseen opportunities into a hopefully elegant workflow solution. Fascinating, and the possibilities are endless!
But I have a confession to make. I *hate* it when customers tell me they want a “vanilla” implementation. To me a vanilla implementation is the very antithesis of what a good SAP implementation should be. To be given all the power of those near infinite variety of options and not to take advantage of them, or to compromise real business requirements for fear of using a provided enhancement spot, is to me a tragedy in the making.
Of course I recognise that budgets and projects are not unlimited, and that scope creep is a perennial problem of most SAP projects, so there is a certain amount of balance needed, but sometimes the “vanilla” approach can really hurt. Especially when “vanilla” is translated as:
“Don’t touch any of the SAP default settings that we don’t absolutely need to change. After all the default settings must be the best practice settings too, right?”
Well, no, not always.
Take workflow events...
For those who aren’t familiar with them, a workflow event is basically just a little alert an application, program, transaction, report, or other workflow can raise to let workflow know that something has happened. It’s the way the rest of the SAP system communicates with workflow to let workflow knows something has changed. Workflow can then respond by starting, stopping or resuming workflows, or of course by doing nothing. One of the main ways events are used is to start workflows, e.g.
- Event “Invoice 52000132849 has been blocked”… so let’s start a workflow to get someone to review the reason for the block and sort it out;
- Event “Purchase order 4500923830 is waiting at release code level S2 to be released” … so let’s start a workflow to get it in front of the designated “S2” approvers
- Event “New cost centre 10923ABC created” … so let’s start a workflow to notify the interested parties
Most of the time, the linkage between the event and the workflow works beautifully, and the relevant workflows get started, or stopped, or resumed or whatever is supposed to happen when the event is raised. Every so often, usually when someone introduces a new version of the workflow, or an event gets raised from a new place, or someone does something that didn’t get covered in testing, something goes wrong.
And that’s when you really DON’T want to be on the “vanilla” setting for what happens next.
Once upon a time a very long time ago (prior to R/3 4.6C – yes that long ago) the default “vanilla” behaviour was that if for some reason the workflow couldn’t be started the default behaviour was “deactivate that event linkage immediately”. It was assumed something dire had happened that affected every single instance of the event linkage, say the workflow definition hadn’t been activated properly. But actually the same behaviour occurred if it was simply that occasionally some of the data being passed from the event to the workflow was missing or in the wrong format.
What’s the problem with the event linkage being deactivated? Well that meant:
- Any subsequent events would NEVER trigger the relevant workflow
- And worse, all the events that were raised after the deactivation were lost – unless you were lucky enough to have the event log on (which is discouraged in production for performance reasons) you had NO record of which events had occurred, when or with what data; and NO way toredeliver the events once the problem with the linkage was fixed (even if you did have the event log on).
In a production system this behaviour can be a disaster. Imagine having trying to track down all the purchase orders that are awaiting approval but don’t have an approval workflow; or track down all the blocked invoices waiting for release but with no-one aware that they need to be released; or track down all the new cost centres that have been created but no-one has been told that they are there and ready to go. Not fun. 😞
This behaviour was so undesirable most workflow people I know (and that’s quite a number now) classified it as “would be a bug if it wasn’t a documented feature”.
Now this *was* fixed a very long time ago, so why I am writing this blog now? Because as a workflow advisory consultant I am still going from site to site to site, and finding the old undesirable behaviour is still in place. Even today as I write this blog I have been at yet another site where the old undesirable behaviour is still unwittingly in place. More often than not, the excuse I am given for this is the “vanilla” implementation excuse.
Why is the old behaviour still showing up from site to site? The way this behaviour was changed was to provide a mechanism for controlling the event behaviour in the event of an error. This control could be set centrally in transaction SWEQADM on the Basic Data tab in the "Receiver error feedback" field (as shown). 
If desired the control could also be overridden in specific event linkages in transaction SWETYPV.
Choice is great but there’s a small snag here. Because it was implemented as a choice, each site could choose to implement one of the new, improved behaviours or stay on the old undesirable behaviour. Which choice was set as the default? Look again at the screenshot and note the value for the "Receiver error feedback" field… yes, the old undesirable “Deactivation of Linkage” behaviour! Why was this done? Time for a quote from the SAP Library Help itself:
This setting is in accordance with the classic runtime behavior.http://help.sap.com/saphelp_46c/helpdata/en/7c/ae4d2eb988d3118f340060b03ca38c/content.htm
In other words, the intention was to try to minimize the disruption as you upgrade from one release to the next, one enhancement pack to the next. All of which sounds quite reasonable; except when no one liked the old behaviour.
So what are the new options and how do you avoid falling in the same trap?
There are 2 alternatives to “Deactivation of linkage”:
- “Mark linkage as having errors” - This deactivates the event linkage but captures the failed events and all subsequent events until the event linkage is reactivated.
- It also provides an easy way to reactivate the event linkage on the Linkages in Error tab of transaction SWEQADM.
- Not everyone will agree, but personally these days I prefer this option especially in quality assurance systems, as it tends
to make you notice design faults in the workflow or the application raising the event much more quickly. - Note that it does require someone to be monitoring SWEQADM regularly to see if events have gone into error.
- “Do not change linkage” – For most sites this is the safest option. Just don’t deactivate the linkage, but capture all the failed events so they can be redelivered.
- This is a best of both worlds option, especially if your workflow administration is a little lax.
- At worst, only failed events will be impacted, and even then the failed events can be easily redelivered once the cause has been identified and the problem resolved.
Frankly either setting is a vast improvement on the default setting.
So if you do nothing else as a result of this blog, check what setting is in your system, and if it’s on “Deactivation of Linkage” go and change it to something else.
How do you redeliver failed events?
The Linkages in Error tab of transaction SWEQADM was also provided to show all the failed event linkages, from there you can review and redeliver failed events via the “Deliver again” button. You can also redeliver events using the Event Browser utility also accessed from transaction SWEQADM to delve into the depths of the events and examine the contents of the event container, which is an invaluable help in diagnosing why the event linkage failed in the first place.
For more information try these references:
SAP Note: 1509503: Deactivation of event linkage
Last time someone asked me to make vanilla ice cream I couldn’t bring myself to do it. We ending up compromising on lemon-scented vanilla – and even then it was real vanilla with all those tiny black seeds in it.
So maybe next time someone suggests your site should be "vanilla" implementation, perhaps you could point them to this blog and suggest instead lemon-scented vanilla, or at least vanilla with a few chocolate chips...
[Image courtesy of piyato / FreeDigitalPhotos.net]
- SAP Managed Tags:
40 Comments
