A few workflow stories

If you worked in workflow for a few years I’m sure something like this has happened to you, one day, usually a few mounts after starting to use a workflow, someone storms into your office all angry and shouting: “How could this have happened?!, the workflow system isn’t working! How did a temp worker sign a million dollars contact!”

Luckily there are workflow logs, and answer is usually somebody forwarded the approval decision workitem, worst case I have seen, and I didn’t believe this myself at first was: the CEO forward to a VP with the saying “have a look at this”, VP forwarded to a dep. Head, dep. Head to team leader, team leader to a temporary employee who looked at the contact and said “this looks fine to me” and approved the workflow task! And it was a million dollars contract…

Best suggestion, limit the forwarding options if possible by using the s_wf_wi  authorization object and leave the task general and not the forwarding not allowed classification option so you can easily forward the workitems if needed. And relax, the log usually are very detailed and useful. Only place where the logs fail is substitutions, which are not logged in the system…

A few months later in the same project I had this discussion:

“Workflow batch disassembled all the kits in the system!!!”

“What do you mean? It’s a system user; it doesn’t go around disassembling kits in the system for its amusement”

“Maybe there is an error in one of the workflows?”

“We don’t have a workflow for kits”

“But the change documents show WF-BATCH as the user!”

Now, after a bit of searching, we found that a function module that was connected to one of the events had an error that caused it to disassemble instead of the kit it was supposed to, all the kits in the system (forgetting to check if the table is not empty before calling a select ‘for all entries in’). Only way I can give to solve this: change the RFC used by non-workflow function modules in the event linkage, mistakes will still happen, but they will not come running for you when they do.

This was a forwarded reply mail for one of the decision task extended notification mails send by the system with the subject “Purchase requisition is awaiting your approval”:

“Who is this workflow guy? And how dare he give ME orders!”

Funny, right? Might have been funnier if it wasn’t the CEO 🙁 now he wasn’t supposed the receive the task but one of his department managers, well the department manager retired and the next level up the org structure is the CEO. We removed the mail from his user and placed a block on the mail server… and if we’ll get the time we’ll also implement note 1865151 – WF notification: Subscription with SPA/GPA user parameter.

A friend of mine once told me that he didn’t consider a you to be a developer a until you caused a server to fall, well I did once (o.k. three times, but in the span of one hour and it was the same server… at least it was a development server), now you ask you can a workflow take down a server? Well surprisingly easily. Once you remember that a running workflow takes a dialog process from the server and most servers don’t have too many of those since they don’t usually need to have a lot – think about it, how many users are pressing ‘enter’ at the same time?

What I did was to use a raise event step to raise the starting event of the same workflow… in a loop… which caused the number of process taken by the workflow to increase exponentially with every workflow raising more and more workflows and never ending, guesses on how many second did it take the server to go down once I ran the workflow in a test mode?

Luckily I worked with a very understanding and capable basis admin and she raised the server up in no time and with no data lost (1-st time “This can’t be, workflow? cause the server to be stuck?” 2-nd time “o.k. it was the workflow” 3-rd “really, this time I fixed it”).

Now go, prove that you are also good workflow developers, take servers down!

Just kidding…

Use an IDES server 😉