It is said familiarity breeds contempt, but that is definitely not the case at least in the SAP world, it provides an opportunity to explore and innovate. Working on Adobe forms was fun and learning experience, the more you learn, the more is there to explore, but things were not going easy when the forms grew huge with more and more functionalities. There is always an cap on how much you can tune to improve the efficiency but after that we may need to rethink for a major overhaul.
Investigating performance bottle necks by checking ABAP and HTTP traces we found that most time was consumed in objects related to Adobe services and rendering. So the main guzzler was the form itself, the HCM P&F is truly amazing but the adobe forms especially huge ones are playing the showstoppers. We put our grey cells to work and came up with idea of “what if we can change the UI layer itself?”, though it might defeat the purpose of most vouched Adobe “paper like look and feel” proposition. We decided to compromise the UI for a better performance. May be this was not going to be easy, but anyways I started my research on this. You know the best place to get leads on anything in SAP is none other than SCN itself, it is a sea of knowledge, you can find an answer or a hint to all your possible questions. Did some juggling with keywords for searching in Google and SCN, and then bang on!, Some one has already tried that approach and has been successful, so that really added to my confidence, special thanks to this excellent blog “Web Dynpro Forms using HCM Processes and Forms“ by Brad Pokroy, I read and re-read his blog several times so that I don’t miss out anything. He has given a lots of hints and clues, but then it was like a puzzle that needs to be solved with lot of cryptic clues, this blog filled me with enough fuel to give me a good start.
The next few days my fingers were busy tapping these keys in my keyboard F5,F6,F7, and when I got tired F8. Going back, the main problem with Adobe forms was that it took awfully long times to render initially and every time there was a round trip due an event on the form. The drop downs were the heavy elements and this needed to repopulated after every round trip, so this played a big role in the speed, the lesser the drop downs the faster will be your form. After a few days of debugging I could relate to the main objects and web dynpro components involved. The web dynpro HRASR_PROCESS_EXECUTE is the actual component you interact with, but the called WD component QISR_UI is the one which is the core of the ISR framework, so I realized this is the one we should be looking at, the one that has to be enhanced to achieve results.
To play safe and not to get into the bad books of any, I planned for a switch framework between WDA forms and adobe form. The form i was planning to work on was in productive use and there was possibility of change requests, so incase of changes in form the developer can make changes and test the form in adobe mode. I planned my switch to be at process level, keeping switch at form scenario level can be dangerous as form scenarios can be reused across other processes. The switch was to just create a z-table with two fields in it, one is the process and other a switch flag.
This was my over all plan to get things working
1. Idenify the view which renders the form.
2. Remove the PDF rendering from the view and implant my custom web dynpro application.
3. Identify all the points in the QISR components where I can tap and fill the data.
4. Identify a way to communicate between my WD custom component and the ISR framework through the identified points.
In the next part of this blog, I will share the technical details of accomplishing this. Be tuned and thanks for reading.
Note : Configuring HCM P&F and creating generic services is out of scope of this blog. This blog concentrates only on switching the UI layers.