While developing SAP WebDynpro for Java applications one of the item that one needs to be take care of is the application performance, especially the initial load time of the application and also the subsequent execution time of the application. Many a time, this becomes a bottleneck for applications developed and it becomes extremely difficult to retrofit changes to improve later on without having to revamp the design leading to a lot of re-work.
How can this be avoided?
While sifting through various sdn articles, post and blogs, one does come across various ways of addressing performance in WebDynpro Applications. This blog tries to enlist the possible best practices that can be used to avoid serious performance bottlenecks while designing and developing applications with WebDynpro for Java.
Outline of the various issues:
The following are possible issues one encounters:
1. Issues with context, views and methods (Poor programming skills)
2. Browser and J2EE engine issues (Infrastructure)
3. Executing BAPI’s/RFC’s using model nodes is an issue
(Poor performance by WebDynpro Application especially initial load time)
4. Backend calls are not optimal (Unacceptable performance by the WebDynpromodel or backend). Connection to Backend and getting data back to the Application is an issue (Issue with WebDynpro Framework, business layer issues with RFC’s, EJB’s)
Resolution steps for the issues:
For the first issue discussed above,
a. Always ensure that instead of using temporary storage for data, use contexts for the same.
b. Context memory should be optimized to not hold large datasets. Refresh of the large dataset leads to repeated database calls which in turn degrade performance.
c. Table pagination in Webdynpro for Java reduces the volume of data that is presented in the UI everytime.
d. Use the methods available in component controllers or in views.
For the second issue i.e. Browser and J2EE engine issue the following checks can be used.
For Standard browser clients, a simple check for the performance of WebDynpro Java Applications can be made by setting “sap.session.ssr.showInfo=true”.
Using this url extension above, one will be able to see performance values in the browser status line. The individual breakup of the application execution time can be viewed and analyzed as well i.e. the time consumption of the browser, the J2EE component time and the backend elapsed time can be seen and analyzed to see were the maximum time is being taken.
For the J2EE Engine being over loaded, one can analyze the HTTP log and check if the incoming requests per second is in the optimal range or not. To rule out any discrepancies ensure that one checks the performance of the J2EE engine with no traffic for the same application.
Regarding the third issue, if the initial load time of applications is an issue we may try to overcome the same by binding the model to the context as late as possible. As an example, one is using a BAPI to get data from the ABAP backend, then do the following, instantiate the BAPI, execute the request, get the response to the same and then get the response attributes set to the context.
The fourth issue deals with issues related to backend. Currently there is performance measurement technique that can be used for any RFC Model only. Here the measurement for the backend connections can be done using the WebDynpro Console. In the Performance > Model & Backend selection of the WebDynpro Console one can check and measure the performance. The WebDynpro Console does indicate how many times and with what response times the JCo calls to SAP system have been executed. For the ABAP backend, do the following to measure the backend responses. Start Transaction ST05 -> Start the Application to be measured -> Stop the RFC trace -> use ST05 or STAD Transaction to display the results. For the other backend types like EJB’s and WebServices one needs to instrument the code to indicate the processing time before and after the EJB’s/WebServices are called and used.
WebDynpro Application performance is a potential pitfall and a major irritant before the go live of the developed applications, but by following points described in this blog and numerous articles on this topic, one can design and develop a robust, scalable WebDynpro application with both good initial load time (first time load) as well as good execution times for subsequent requests.