HCM Processes & Forms: “Work item 000000000000 cannot be read”…or the Case of the Phantom SLG1 Application Log Entry
I generally like things to be “nice and clean”…..code, application execution, documentation, log files, my office….ok, ok…maybe not the last one (haha). This blog will cover a nagging “oddity” of HCM Processes and Forms that has “bugged” me for quite a while. I came across this one a good while back and thought it would be fixed by now, but it seems SAP has other things going on (hey, have you heard about this new thing they got called S4/HANA? haha). Since SAP seems content with it (for now?), I figured I would at least put it down in a blog in case it “bugs” other people who might be wondering what the “heck” is going on.
In a nutshell, what happens is that if you happen to take a look at the Application Log (transaction SLG1), which I do quite often it developing HCM P&F processes, you are going to see a lot of entries in there as errors with the message text:
Work item 000000000000 cannot be read
But fear not!!!! These are really errors themselves…er uh…I mean bad entries…..entries that should not even be there. But why? Why would they get written to the application log at all? Ahhhh…..here is where our detective work begins!
When I first wanted to find how this entry is written, I started with the obvious. I had often used the Application Log functions before (app logging is cool!), so I looked first at the functions:
I did a good old “where used” on them and was looking particularly for anything “ASR” related. Two classes caught my eye right off (and are VERY useful for you to remember/note/use!):
- CL_HRASR00_APPLICATION_LOG (used for writing to the app log from theHCM P&F runtime/process execution)
- CL_HRASR00_DT_APPLICATION_LOG (used for writing to the app log from the HCM P&F Design Time/design/config view)
I took a look at the class CL_HRASR00_APPLICATION_LOG and placed a breakpoint in the most obvious place….the method ADD_MESSAGE which is what writes to the application log.
I started up my process and right away before my form even displayed, my breakpoint hit and the debugger popped up. Looking at the call stack, I could see class CL_HRASR00_FPM_UTILITIES method GET_STEP_PROPERTIES_WIID calls function HR_ASR_GET_STEP_PROPERTIES ….and here is our culprit!
Looking here, you can see it first attempts to read the work item….but we just started our process, so we do not have one!!! (and might not at all if our process does not use workflow)
So of course, the function call fails and our “sy-subrc” is not zero. This cause it to go into error handling…which includes guess what? Writing to the application log!
Here, we can see the values it passes to the “write to application log” method (does that work item ID seem odd? haha).
And if we look at the actual message class WL and message number 803, we can see…
Look familiar? haha
So yes….every time we start a process, SAP writes an error to the application log. Why? I have no idea! Sure seems like a “bug” to me, but to look at it from a positive side, we can see every time someone does “attempt” to start a process whether they carried through with it or not, so maybe that can help with auditing if nothing else. I just think there could be a “nicer” way of handling it.
Well, this was a rather short one, but just wanted to cover this in case anyone else ran into it and was wondering why their application log was so “messy”. I hope it helps, and as always, I will keep blogging if you keep reading them! Till next time….
this is funny because we just had to deal with this "nagging oddity" yesterday 🙂
Wish you had posted this a day earlier 😉
Love your Blogs - keep blogging.
Thanks & Cheers,
Did you hunt it down yesterday and find the same thing? 😆 Sorry I was slow getting it out, but maybe it will help others like us who find it very VERY annoying. 😉 Thanks for reading and the compliment! I will keep them coming!
So you could (b)log about it!
Good one as always.. have fun!