Did you ever wish you had X-Ray vision? So you could see into your boss’s office and see who she was talking to? Or find out what was in your Christmas gift days ahead of time? Well, with the Workflow Container Monitor, it’s almost that good.
Let's pretend you’ve been doing SAP Workflow for a few years (or many) and you know the drill. Someone comes to you with a requirement, and it’s a perfect fit for Workflow, and besides that, it’s something you can do with your eyes shut and both hands tied behind your back. I mean, it’s a piece of cake.
So you spend your hour adding some attributes, copying an old template, tweaking some bits and pieces here and there. At last, you have everything generated. You test the new code from your trusty BOR testbed, SWo1 (please don’t get on my case about ABAP OO). The results are just what you expect. Good to go.
You incorporate the new method into a task, and from there into a workflow. You check your bindings. Really, this is so simple, you barely need to have your eyes on the monitor. Ho hum.
Then you start the workflow using SWUS.
Wait, WHAT?
Oh, that’s not good. Your cute re-use of code was supposed to fill some attributes which would control the new workflow. Only. It doesn’t.
Back to SWo1, test, it’s all good. The attributes are there, man, they are really there!
Double-check the data types. Are they all consistent? Yup. Double-check the container elements – are they import or export when they should be? No need to debug the BOR method, because that works.
Breaking out the big guns now… you go to SWUD, and choose Test Environment.
You switch the container monitor on.
I just love the container monitor - it gives a real time view into what is being passed back and forth in your workflow. I think maybe it is only beaten out by the Workflow Trace, but that's another blog. Yep, there’s the invoice, going into that new task, hit continue, expect another container monitor to pop up and show you the values coming out of your method.
Whoa, didn’t we used to get more container goodness? Just one lousy snapshot of the container operations? Waaaaah.
What’s the missing piece?
When you start the workflow, if you want to see more of the container operations that are taking place after the initial binding, you need to use the Start Options. So choose GOTO > Options. You’ll get a nice little pop-up with some pretty inscrutable options.
To be honest, I have not ever started a workflow ‘transient’ so I can’t tell you what this is about. Starting a workflow Asynchronously? Nope, haven’t done that either. But since we need to see what is happening inside the workflow, in the bindings of the background tasks, I will check off ‘Simulating background processing’. The next time I start the workflow, I get pop-up windows for each background task that has any container impact. This is a beautiful thing (to us workflow people) because we can now see what the source container is, what the target container is, and we can determine what values are missing.
As it turned out, in this case I had forgotten to bind from my new method into my new task. (Insert picture of Homer Simpson say D'OH!) But without double-checking in the container monitor, I might not have found that.
I have not been consciously binding from a BOR method to a task (previously) because normally it is something that is done for you ‘automagically’. So whether it is due to support packs, or just my imagination, this will be re-added to my debug arsenal.
At any rate, it was a relief to see (via container debugging) that my BOR method parameters were now being filled correctly in the workflow.
But I will tell you that being able to use your X-Ray vision, and see into a workflow container can be critical to debugging.
You may like to bypass using SWUD, and simply execute the function SWA_CONT_BIND_DEBUG_FLAG, and pass an ‘X’ in for NEW_STATUS, and from there go to SWUS. That’s your call.
One caveat though – if you are using SRM (for example) and delivering tasks to a user via web browser, you will get an error (SM58) saying: 'DYNPRO_SEND_IN_BACKGROUND' ( Screen output without connection to user. This is because as a result of an dialog task in the browser, the backend system is attempting to display what has happened to the container. But since the execution takes place in the browser, there is no connection for the backend system to use when trying to display the container.
OK, so maybe I misled you just a little bit by claiming this was as good as having X-Ray vision. But if you've read this far, then maybe you have learned a little trick or two. I hope so!
- SAP Managed Tags:
19 Comments
