Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
keohanster
Active Contributor

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.


26 Comments
Labels in this area