Skip to Content

Master Data will always bite you

As a workflow developer you get used to certain things just being easy. Yes, I said it, easy. Sending mail to your users is one easy thing. All you have to do in your workflow definition is include a send mail task. It’s beautiful. You can include all kinds of attributes of the business object and it’s an email that actually makes sense.

So my heart sank as I realized that the next task I had to complete was to generate a PDF and send it to the document creator. I mean why do they need a PDF in their email anyway? Sometimes I feel that our users are so hung up on paper copies… that they should just learn to trust the system. A PDF in your email is a convenience though. And it’s not always up to me to question what the users are asking for. Still, this task involved working with Smartforms, converting the Smartform to PDF, and using the function SO_DOCUMENT_SEND_API1. I have worked with Smartforms but I found it painful and believe it or not I had never worked with that particular document send function.

I started out writing a simple function to call the Smartform and convert the output to a PDF format. I didn’t bother was trying to print – I was happy just to see the table entries as output from the function. Then I included the call to SO_DOCUMENT_SEND_API1. It took some fussing around but I was able to get the PDF document to show up in transaction SOST.

From here on out it should be all icing on the cake. For workflow developer this is usually the hardest thing… to get the core functionality to work. I incorporated my function into a method and created a task that call that method. I included the new task in my workflow template. Checked the bindings, checked all the container elements, everything should be good to go. But that’s not really real life.

The workflow task would fail with an error message that made absolutely no sense to me. SSFCOMPOSER A 010 was the our message and if you look this error message up it says maintain the default printer. I wasn’t going to print, I was sending email. I had checked the SOST transaction and it showed outbound documents. What the hell did I care about a default printer? I switched the workflow task to dialog, and after painstakingly setting up a boatload of transactional data to work with I proceeded to test with the task in dialog mode. The funny thing was, every time this task ended up in my inbox I could debug and step and execute all the way to the very end and the document would always be created successfully.

But as soon as I switch that dialog task back to a background task and executed the business transactions, the workflow would go into error again. I searched SCN  for notes and there are about 943 discussions on smart forms. There’s probably twice that on generating PDFs. I wasn’t having a problem generating the PDF!  I could do that, I just had to be a dialog user.

Finally, light dawned on Marblehead. I had been assuming that the error message was incorrect -it happens sometimes. I had checked my default printer and everything was fine. I had never looked at the default printer for the user WF-BATCH. Of course there was no default printer set up, so as soon as I added one and executed the business transactions, Poof! There was a new PDF in the outbound queue.

People sometimes laugh at me or shake their heads in disbelief when I say that most of our problems in the workflow world will come from configuration or master data. A configuration change, by definition, will impact a business process. And if config changes go up to production without consideration of the workflow world you can be sure that trouble will follow. Master data is another issue. Normally we think of it in terms of reorganizations, cost center or WBS begin and end dates, vendors changing, etc.  So we think in terms of larger master data. But there’s no doubt that the default printer for the background user WF-BATCH is master data. And that bit of master data is now correctly assigned.

Moral of the story? Pay attention to the error messages, on the off chance that they will save you from beating your head against your desk.

You must be Logged on to comment or reply to a post.
  • Nicely explained. In purchasing we get dumps if the printer is not assigned in the user profile, even we do not make use of it as all gets determined via message determination.. And it is a recurring problem with any new hired buyer, because of the distributed activities.  The team who creates the user master does not know the printer name and just leaves the field empty, and the buyer himself … he is instructed to create a purchase orders, making his life easier with user defaults is usually done later. And as this error often hits an user just once it is seldom mentioned when the new buyer gets his instructions.

    • Hi Jürgen, thanks for your comment.  If anything else, it certainly validates that simple pieces of data (often thought to be insignificant) are not really insignificant. 


    • Thank you very much! If I had started blogging about all my mishaps (and subsequent learnings) over the past years, I would have a pretty good collection.

      How about you?

  • I was attracted to this blog because of a nice caption. But I don’t know much on workflows πŸ™ .

    – Midhun VP

  • Nicely written and captioned Susan Keohan

    It actually explains the detailed steps and analytical thinking a workflow person should have for approaching the problem/situation and work accordingly.



    • Thank you, Naveen.  I should have written the blog as I went along (with screen shots) but maybe next time.

      How about you?  Have you got a little debugging ‘master data bites back’ story?  (I am sure everybody does!)

  • Susan, Its really nice idea to get-in screenshots for the whole process. I usually do the same in blogs on my tutorial website, really helps to understand quick and better.

    Sure will try to rope in few articles here too.

    Cheers 😳 , Naveen

  • Sue,

    Master Data frequently bites us in GRC, too. For example, if the request approver does not have an email address in her/his user master record, s/he will not receive the configured workflow notifications.

    Thanks for a good reminder to us all!



      • Hi Sue,

        That’s a good reason! (about the only one I know of  … I was only wondering if there were another, in this instance  …)

        Your blog is a good reminder about error messages. I can particularly relate to your closing photo … although at this time it is not Workflow that is doing that, but the need to convert a bunch of old Visual Composer models to the latest VC version. Aaaaarrrgh … is not just a castle in Monty Python and the Holy Grail. πŸ˜†