From the very first day of my recent HCM Process & Forms project, I was given an absolute “deal breaker” requirement that gave me many a sleepless night. My client had implemented a very customized MSS solution based around custom Java applications. Their MSS really encompassed simply an “inbox” and the ability to initiate and process workflow around a handful of processes (termination, purchasing, hiring, etc). One of the key features of their solution, however, was the fact that their managers could process approvals for particular workflow steps using their company provided BlackBerry devices. With some 1000+ managers using this almost daily, I was told in no uncertain terms that we must be able to duplicate this same functionality with our HCM Processes & Forms solution. No matter how wonderful and great and easy to use whatever we came up with using SAP’s provided HCM Processes & Forms framework was, it would not matter if we did not provide that Blackberry functionality. I was not absolutely sure how we were going to do it, but I did know we were going to get it done. So the search began….
Of course, my first path of attack was to search for what was provided by SAP already. In my mind, we had two issues here: (1) we needed a UWL for the BlackBerry (2) even if we had a UWL solution on the BlackBerry, we would need to know if the BlackBerry could (a) run the HCM P&F ABAP Webdynpro (b) present Adobe Interactive Forms.
For the first issue, right away I found information on SDN about a UWL solution for the BlackBerry. Awesome!…..or at least, I thought. I followed all the related links, and in the end, it turned out to be a demo of the UWL for CRM related work over a BlackBerry. However, it did have contact information for the developer, so I sent out emails explaining our situation.
While awaiting a response from the SAP side, I scoured the RIM site looking for information and actually found a SAP related developers area. Again….awesome!….and again, upon further inspection, it turned out to be a bit less than what I needed. However, as before, I did find a contact link for SAP development for RIM(BlackBerry devices). Again, emails were sent out. For RIM, I asked for particular information on (1) can the BlackBerry run Webdynpros? (2) Can the BlackBerry present Adobe forms?
The response from both sides was both surprising and funny to me. Both sides said basically “sorry, we don’t have anything like that….but what you guys are doing sounds really cool!”. (ha-ha)
From the SAP side of things, as mentioned, they said the UWL prototype was really just that and built really specific to a project/customer need. They just wanted to show it is possible. The contact did provide some good information on SSO for the BlackBerry and such, but we didn’t really have an issue there. It was appreciated nonetheless.
From the RIM side, we heard back on both points. First, the BlackBerry “should” be able to run Webdynpro-based apps….but they had none to show us and couldn’t provide anything concrete on whether this meant Java Webdynpros only or ABAP Webdynpros as well……..we just couldn’t go off and running with “should be able to”. The second issue was the real killer though. The RIM contact said that their was no native support for Adobe forms….this was usually done by third-party solitions for the BlackBerry to render PDFs. Furthermore, even he said he found it kind of odd that they had not yet partnered with Adobe to come up with something given how mobile the workforce is these days, but he wasn’t sure why that partnership had not happened yet or ever been atttempted. He suggested using web forms instead….but alas, that was not going to help us. Like the SAP contact, he closed by saying he would love to hear what we come up with and please keep in touch.
So after running around for a few weeks exhausting our searches for ways to do what we needed using standard, available solutions, we were pretty much back to square one. It was looking more and more like a custom developed solution. Worse yet, not only would this take time away from our main project of implementing SAP’s HCM Processes and Forms and MSS which was on a tight timeline itself, but because we did not have a real feel of even what was going to be involved, we couldn’t even tell how much time that would be. Ugggg!We seemed to be at an impass. What to do? What to do? It went something like this…..
“We need a solution…..something to allow the BlackBerry to communicate with SAP, workflow and our process object…..something to send and receive internet information…..like…I dunno….something to process internet requests for services between the two….wait…what?…..internet service requests?…..ISR!!!!!…..Eureka!!!” (*fun fact! just FYI, “the term “ISR” was changed by SAP from “internet service request” to “internal service request” due to confusion with it’s HR-centric focus and CRM’s own “internet service requests” for customer service related requests.)
Seriously, the “lightbulb moment” really was about that involved. Why hadn’t we thought of that. The answer was right under our nose all along. Let the ISR do what it does best! Let it handle all that “heavy lifting” for us! So off we went….the detective work began…looking for which standard function modules (which were hopefully RFCs as well) were available for the ISR framework. Thankfully, we were blessed with one of the best debuggers I ever met, and within a day, she had solved the case.
We could have probably called the standard ISR functions directly, however, we wanted to build for our future needs. Knowing that we will only allow managers to do approve/reject kinds of tasks on the BlackBerry, we could handle a lot of the code internally. Therefore, we built a nice custom, wrapper function around the standard ISR function. In that way, our wrapper handled a lot of the pre-call work to collect the data needed to pass to the standard ISR function. First, we have to collect the work item details (call to standard function HR_ASR_GET_STEP_PROPERTIES). Next, we read the workflow container (call to SAP_WAPI_READ_CONTAINER as well as some other code). Then, depending on what the manager did (approve or reject), we fill in the data needed for the ISR function. Lastly, we call the standard ISR function to actually update our process object and other information. This function is the heart of our wrapper and is called ISR_PROCESS_EVENT. (*I suggest looking at “where used” to see examples of using this.) The really nice thing about the function is not only can we send the approve/reject status, but we can even send over comments just like working on the actual Adobe Interactive form. I am very sure we could handle form fields and attachments as well, but that’s a bit much for a BlackBerry.
First off, I should mention that our application is based on Java code running on the BES (BlackBerry Enterprise Server). Rather than build completely from scratch, we were able to modify the existing, custom “MSS Inbox” application (the one we were initially trying to replace…haha). This saved us a tremendous amount of development time. We simply added in the bits needed to handle our HCM P&F process. So now with our super-duper, handy-dandy, do-all, be-all, end-all, custom wrapper HCM P&F ISR function, here’s how the whole thing works.
The manager will first receive an email telling them they have a work item. There is a link in the email that when clicked, launches our custom “MSS Inbox” application. This link calls the BES server. Now, at this point you will have some SSO concerns. There is a nice SSO solution for the BlackBerry and SAP that uses the email address of the user, however, we have a custom solution that uses “device ID” instead. This was decided for security reasons to be a better design. I won’t go into “how” the device ID is used, but let’s just say there is some “translation” done and then mapped to a SAP Logon Ticket.
So now, the manager accesses their “MSS Inbox” on their BlackBerry. The application uses a variation of the standard function SAP_WAPI_CREATEWORKLIST. This will retrieve all work items for the user. However, keep in mind that for our requirements, we don’t want to allow the managers to be able to do everything on their BlackBerry. We only want them doing certain items. For example, for our HCM P&F process, we only want them processing work items that are simple “approve/reject” items. We don’t want them doing work items that require completing long forms and such which is not very practical on the BlackBerry. Therefore, our application then “filters” the list of work items we received based on their task IDs. Since we know exactly the tasks we allow, this is very easy to handle.
With the work items filtered to only the ones we allow on the BlackBerry, the Inbox is now presented to the manager. The manager will pull up the work item for our HCM P&F process step. The contents of this work item are “modified” by our application. Instead of building the regular URL to launch the “Start Application” which would pull up the Adobe Interactive form, we build a different URL that directs the manager to a custom JSP page which will mimic our form on the BlackBerry.
At this point, the manager launches our custom JSP page to actually “do work”. They will review the information on the page and either click the “approve” or “reject” button that will trigger the JSP page’s form “action”.
The “action” of the JSP page triggers a method in the controller that calls our custom wrapper ISR remote-function back over in SAP passing to it the work item ID, the “comments” from the form, and “code” from the button selected (APPR=approved, REJE=rejected). The custom function then makes the appropriate calls internally to update the Process Object for the form step and trigger the workflow to complete/close the work item. When control returns to our Java “MSS Controller”, it checks to see how the BAPI completed. If there were no errors, it will place the workitem ID number into a session (memory) so that if the custom MSS inbox does not clear it, it won’t be accidentally called again. If an error did occur however, the user can launch the workitem again. At this point, the controller “sleeps” for a bit so the backend can catch up (ie. close the workitem if necessary) and then it directs the user back to our custom “MSS Inbox” application.
I am sure all of this sounded great so far, but I know what you asking…..can we see it?!?! Sure! Here’s a couple of photos of our BlackBerry UWL and HCM P&F form in action (*sorry for the photo quality…..not so easy taking a cell phone picture of another cell phone….haha):
Well, that’s it. I hope you enjoyed this little walk-through of our solution, and it gives you an idea of how to accomplish the same in your own environment. I want to first say thanks to Ed Bourne (RIM) and Stefan Wawrzinek (SAP) for help, information and cheering us on from the sidelines. I could not end this blog without giving a very special thanks to the rest of the team…Walter Mercer, Roopa Prakash, Neeta Divekar, Sreedevi Agasthya, and Jeff Glynn…who were a large part of this solution as well. I am currently trying to convince them to co-present this solution at future TechEd and/or the HR 2009 conference. Hopefully, we will be able to really show it off a bit more and have a live demo of their specific solution! Please help me convince them as well!