I had meant to write this blog a good while back after facing, fighting, and defeating this "monster" of a problem, but I thought "meh, who else cares about this?" (*side note: this happens to be the thinking of a lot of people who talk themselves out of blogging and sharing here....so GO BLOG!) . That all changed when I saw a recent forum post from someone facing this exact same pain in the a.....uhm....well, let's just say "pain". This "pain" occurs when using the Java version (EhP4 and lower) of the "Bank" ESS service.
For me, this happened on a normal ESS project a few years back. We were rolling out SAP standard services with little to no changes. Not much to see in DEV....but then in testing in QAS/TEST....*WHAM*....it hit us. When running the Bank service, test users were waiting for several minutes for it to load....and more often than not, time out. For some reason, those pesky end users just could not live with that....GAH! They're so demanding, right!!?!?! haha. So, I set off to figure out what was going on and why.
Setting up a user trace with my own employee/user ID on the backend and then running the Bank service via the portal on the frontend, I looked at the trace results and the issue was immediately recognizable....
Something was going on in this HRXSS_PER_GET_F4_VALUES function! My first and immediate thought was...."To the SAP Marketplace quickly....there must be an OSS note for this!!!". I searched on this function and on "ESS bank" and sure enough, I found:
SAP Note 1030890 - ESS Webdynpro:To disable F4 help for Bank key
It read as symptoms, "In ESS Webdynpro Bank scenario there is too much delay when the user tries to create/edit a Bank record. Too many values for the bank key causes a huge delay in displaying the webdynpro view.This is a performance issue."
YEA!!!!! This was it!!! I was so happy and releaved....and set to fly in like Superman and save the day with this wonderful fix I had found...I was already patting myself on the back and thinking about that lunch the project manager would be buying me that day...but then I read a little further and my stomach sank....I felt ill...from a massive high, I had dropped to a massive low.
The "fix" called for a change to the Java component itself....which we all know if you read between the lines this means the dreaded four letters....
N-W-D-I
....NO!!!!!!!!!
So here was my issue...(1) my client, like most I have encountered, does not have NWDI in place....nor ANY interest in EVER putting it in place (2) we were already rushed for time and under the gun as "go live" approached, so setting up NWDI from scratch...which meant getting the BASIS team up to speed on what it is, how to install it, getting developers up to speed on using it, etc...not to mention the actual cost of the physical space (servers and such) for it...just wasn't happening on even the BEST of conditions.
We played our next option....contact SAP for help....surely, they'd know what to do, right? This is where it got laughable. I helped create the request which mentioned everything above and our issue of not having NWDI, and then we waited. A few days later, we get a response from SAP..."Please refer to note 1030890"....WHAT?!??!...we replied again stating we knew of that note, but NWDI was not going to happen, and we waited. A few days later, SAP replies "To correct your issue, please install the NWDI environment and follow note 1030890"....WHAT?!?!?!?...again, we patiently replied back that we do not and will not have NWDI and could they provide an alternate solution. SAP responded again with simply what amounted to "Sorry, the fix we provided is the fix, and we have no alternative for you....have a nice day!". Argggggg!!!
Not one to give up, as we had gone in circles with SAP, I had been working on tracing the issue and looking for other possible fixes. I looked for ways using the Decoupled Infotype framework's input/output conversion classes.....nothing. I looked for possible ways to possibly even modify the Java component without NWDI and re-deploy it directly (tricky AND very dangerous!), but didn't find a "safe" way. I looked here and there...high and low...but then it dawned on me (which it should have before), why not look back at the function itself?!?!? I then ran a debug and had breakpoints right as execution entered the function HRXSS_PER_GET_F4_VALUES.
Right away, I noticed an interesting input parameter...."excluded_fields". Inspecting this, I saw other field names from the infotype that normally have "search helps" associated with them, however, it seemed this was a way to tell the function to not try to build those "help" values. Thinking back to the note from SAP, I recalled it mentioned to uncomment code to add BANKL to a method call..."uncomment the line fields.add("BANKL"); in the method addValueHelp()"...which I guessed (correctly too!) without looking at the Java code meant that they were simply adding "BANKL" to the "excluded_fields" table to then call the F4 "help" function. (*which means also they knew of this problem before since that code existed but had been commented out...haha). I figured I was on to something, so I thought "Instead of doing it on the frontend in the Java code, why not just do the SAME thing but on the backend?". I made an enhancement spot (thanks to graham.robinson and his wonderful TechEd session on this!) in the function and my code was:
FUNCTION hrxss_per_get_f4_values .
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(1) Function Module HRXSS_PER_GET_F4_VALUES,Start A
*$*$-Start: (1)---------------------------------------------------------------------------------$*$*
ENHANCEMENT 1 Z_IMP_ESS_BANK_FIX. "active version
data: wa_excluded_fields like line of excluded_fields.
wa_excluded_fields-FIELDNAME = 'BANKL'.
append wa_excluded_fields to excluded_fields.
ENDENHANCEMENT.
*$*$-End: (1)---------------------------------------------------------------------------------$*$*
*"----------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" VALUE(EXCLUDED_FIELDS) TYPE HRXSS_PER_FIELD_T OPTIONAL
*" EXPORTING
*" VALUE(MESSAGES) TYPE BAPIRETTAB
*" CHANGING
*" VALUE(F4_VALUES) TYPE HRXSS_PER_F4_T OPTIONAL
*"----------------------------------------------------------------------
*TRY.
CALL METHOD xss_adapter->get_f4_values
EXPORTING
excluded_fields = excluded_fields
CHANGING
f4table = f4_values.
* CATCH CX_HRPA_VIOLATED_ASSERTION .
*ENDTRY.
ENDFUNCTION.
After making the change, I re-tested and re-traced the run and the result was now:
It worked!!!!! The Bank service now responded almost instantly! In the end, I had figured it out on my own....but this time, I was not doing any patting on my back nor waiting on a free lunch. I was just happy it was working, and that was enough for me. Now if only SAP would update their note (or make a new one) that provides this information for others! I am not holding my breath for that, but I do hope others who face this problem find this blog. For me, this has been a good example of "You never know what you run across that might help others"......so get out there and BLOG IT!!!!!
- SAP Managed Tags:
14 Comments
