After years, quite literally, of wishing we had Universal Worklist (UWL) at last my dream came true. We are implementing SRM7 and the Universal Worklist (UWL). I’ve been to many presentations – some given by Jocelyn Dart, Thomas Kosog, and Ginger Gatling. I’ve read ‘the book’. I even found Darren Hague‘s book on UWL.
Here are some of my top ‘likes’ in the UWL/XML area:
I had all the goodies I might possible need! I was READY.
Or so I thought.
The initial steps you need to take to set up the UWL are well documented and quite set. Your Basis team will do the initial configuration – setting up the connections and all that. What happens next is that you (presumably) the ‘workflow developer’ or maybe the ‘ABAP programmer’ are thrust into a world of text files, DTD files, little-to-no change management and a new language. Those of you who are more webby user-interface-y savvy should probably leave now. But for those of you who are new to Universal Worklist and XML, feel free to stick around.
I know some might say that XML is merely the markup language, and it’s not even a real programming language. I’ll say.
What you are confronted with is a baffling number of huge files with no easily discernable rhyme or reason. There’s no file management built in. There isn’t (really) a syntax check (although you’ll learn more about that later on). There are no RULES – except that the test cycles between ‘Upload new configuration’ and ‘run’ involve many steps.
Bearing in mind that we are implementing SRM7 (upgrading from SRM5) with our ‘old’ application-controlled Workflows added another level of uncertainty. So I hope that if you read this blog (series? We’ll see) it will help you as much as some of the community people have helped me.
Now you are now doing a lot of your work in a web interface. This means caches and cookies and browsers, oh my! It will help if you are allowed to run multiple browsers on your work systems. For some of us, certain <ahem> internet explorers are not welcome, so we are using Firefox and Chrome. I chose to do most of my ‘work’ in FF, but then was dismayed to see that some of the UWL/SRM rendering is not correct in Chrome. So simultaneously uploading changes to UWL in FF, and then logging in a user in Chrome is not the way to go. You can reverse that, or use that other browser too.
You will see, once you click on ‘Click to Manage Item Types and View Definitions’ a long list of configurations.
Each of these configurations represents a portion of XML delivered by SAP for specific functionality.
And what’s all that gunk below? That’s going to be your world for a while, my friend. So get yourself off to a good start and familiarize yourself with various XML editors as well. I am using Notepad++ and at first it made my eyes bleed, but now I am getting used to it, and I’ve found some good search and edit capabilities.
Now, of all these files (something like 20 of them) the ones you will want to pay attention to first are:
uwl.webflow – contains the definitions of some basic workflow actions, such as ‘forward’ and ‘upload attachments’
uwl.standard – also contains the definitions of various actions
com.sap.pct.srm.core – contains the XML for each workflow task and the actions that are applicable for each task
Did I just say ‘task’? Got it! Go edit that com.sap.pct.srm.core file then! That’s all I need to do!
So download the com.sap.pct.srm.core file. Save the original downloaded files in a directory where you will not be tempted to overwrite them. While you’re at it, create some folders – UWL-Sandbox, UWL-Dev, UWL-QA for example. Then open that downloaded file with the XML editor of your choice.
I have a few screen shots for you to peruse…
You can see that Wordpad offers the more ‘Word-like’ interface, while the Notepad interface is pretty black and white. Or just black and white. And in Notepad ++ as I said initially all the colors were baffling, but now I’ve adjusted.
At any rate, you will chose your XML editing tool, and set up folders to keep yourself organized. First, before you make ANY CHANGES (and we’re looking at com.sap.pct.srm.core now) save a copy in your ‘working’ folder. Depending on the tool you are using, familiarize yourself with ‘Save as’ and chose XML. Or, in Notepad++, chose file type of .TXT and add .XML onto the file name. Why? I don’t know! But it works.
If you’re the workflow developer, you’ll be a a little ahead of the game because you will already know about tasks. If you’re not the workflow person, become friends with them. Bring them cookies.
Look at the task you expect to deliver. If it’s an SAP standard task, say, TS10008126 (SC approval) then great! The com.sap.pct.srm.core file will contain a definition of that task and how it should be rendered.
Here is the delivered XML for that task:
Since I had already replaced our old SC Approval task with this task, TS10008126, in the workflow template, I launched a few SC approval workflows. Then I checked out their representation in the UWL. But this what what was shown. And you had to know enough to <gasp> right-click on the item.
This was not going to fly with my users. In SRM5, we had buttons. Yes, people can be trained and change is hard and all that. But I asked some friends who were also on SRM7, and they all had the buttons! Was this a complication because we were using Application-Controlled Workflow? Was I using the ‘wrong’ task? Would swapping to a different task (and creating more shopping carts and so on and so on) make the buttons show up?
The answer, as pointed out by George Credland (who graciously was volunteered to help me through our mutual contact, James Ibbotson) was to be found in OSS Note 1803438 “Showing UWL item action as a button – only in context menu” Wait, WHAT? I had been combing through OSS notes since January (when I got my sandbox environment). I know there were no notes related to buttons. But timing is everything. This note was published in May. So it never existed in January, and it took George’s fresh eyes to help me.
<Property name=”showButtonInPreviewArea” value=”yes”/>
This is where I enhanced the delivered XML to get the Approve Button. I saved this file (carefully, never overwriting the original) with a file name that identified it as my own, and uploaded it to UWL, re-registered, and cleared the cache (I’ll save all this for another blog).
You see, the task refers to one or more actions. The actions are defined (at least once, but perhaps multiple times) in other XML files. The trick is to match your task and the actions it performs with the action definitions. When we decided we needed the ‘Forward’ and the ‘Assign to Me’ actions as buttons too, the Property under each of those actions was added – to show the button in the preview area.
Now I could go on for quite a while about XML itself. It’s picky. It doesn’t like me. It is impossible to understand. But with a little help from my friends, I’ve overcome some of those hurdles.
There’s a lot more to do, and a lot more to blog about. If I have to close this blog with some tips, they are:
1) identify the tools you need (XML editor) and get them
2) set up your file management system
3) have a cup of tea
4) do not underestimate the value of friends, or a pair of fresh eyes
5) check SAP Notes early AND often
Stick around for Part 2, in which I will rant about something else.
What about you? Did you struggle with XML at first? What were your biggest hurdles? How did you overcome them?
<Action name=”Closing” value=”Cheers”/>