Tag Archives: web dynpro java

Load test your web applications part 2 – with Apache jMeter

Posted on by

Note: 1st published at SCN on 19.8.2013

This blog is laying around on my hard drive for too much time. The previous version of this blog series was published over a year ago!. Originally named “Load test Web Dynpro Java with jMeter” this was actually the 1st blog of the 3 part series. During the last year, a few blogs about jMeter were published, but as I do not want to leave the series unfinished, I am publishing now (finally) the last part of my load test your web application blog.

To make it easier a jMeter test plan is attached to this blog. This plan can be used in conjunction with a
WDJ application. Both were used for the creation of this blog.

With jMeter

JMeter is a great tool for testing your web applications. And you can even use it to test Web Dynpro Java applications. To facilitate the work of creating the tests, jMeter comes with a proxy to intercept browser requests and add them to the test. This allows for easy and fast recording of tests.

jMeter test for sample WDJ application:


As by default a WDJ application is accessible as anonymous – or Guest – user, authentication is not needed and a test can be executed several times against the WDJ application. Pretty easy but in real life you’ll hit real soon a hard limit. By default ,the HTTP Cookie Manager controller does not delete cookies with each iteration, or: JSESSIONID is not deleted.

Simulating users

Running the test and checking the user sessions in NWA shows that the same Guest session is used.


With that you may be tempted to run the test and to see the load generated by just 1 user. But try to run the test 50 times. After some calls, jMeter shows an error when executing the open WDJ app step.


The error message returned from the server is:


HTTP 403? Yes, 403. Re-using the same session will ensure that you`ll hit a well known limitation. You can now opt to implement SAP note 1012065, but it is better to end the session after each iteration. While only one Guest session is open, the maximum number of application sessions is exceeded: 23


Now let jMeter create a new session with each iteration.

The new sessions are created because the HTTP Cookie Manager deletes the JSESSIONID cookie with each iteration. Run the test 5 times, the open sessions in NWA will show

To access the report, go to: Availability & Performance -> Resource Monitoring -> Session Monitoring

If now a test with 500 iterations is run, 500 Guest sessions will be created. This may not a problem, but won’t reflect your reality where sessions are ended after the user navigates away. Logging in and off creates additional load, something worth to test too. Besides this, each session occupies some memory. Depending on your test case, this amount of memory can consume quite some substantial part of the free memory, compromising your test results. 

The correct way to test WDJ applications is to end the user session after the test is executed, independently if Guest or named users are used. To end the session, all it takes is to delete the cookies each iteration and trigger a logout action: /irj/portal?logout_submit=1 [you have the portal installed in the same instance, right? If not, you’ll have to add your own logoff functionality to the application]


Add this step at the end of the test.


With a HTTP sampler as the last step, each iteration can be started with a new session without overloading the NetWeaver Java server with Guest or user sessions.

Let the world know

Load test your web applications part 1.5 – Apache ab

Posted on by

Note: 1st published on SCN on 11.6.2012

With ab, for Web Dynpro applications

In my blog about performance load testing with ab SAP Mentor Anton Wenzelhuemer raised a question if and how you can use ab to test a specific action/event in WD applications. That’s a good question as these events besides input validation normally trigger a connection to the backend and change the context node and attributes. And that is the part where you can improve the performance of the application.

Now, is it possible to test a user action with ab? To remind you, ab is used to test a single resource. The intent is to see how fast your web server can serve a HTML page and test how different configuration parameters affect the performance. You cannot test the flow of an action (load page, press button, get result). To find out if ab can be used to test a WD application, you have to find out what happens when you trigger the event.

Sample WDJ application

I build an example WDJ application using the steps outlined here: it’s and Web Dynpro Java application containing a table that shows the data of the get flight BAPI. For testing forms that require an input you cannot use ab (meaning: setting the input and call the form action), but you can use ab to simulate actually what happens after the input is set and the send button is clicked: the POST action of the browser.

[For testing the form from command line: to insert the airline Id and press the button, use curl, as curl allows interacting with forms. But curl is not a load testing tool (you may look at curl-loader).]

To make things easy for me I implemented a button (named: Generic) that sets the input of the airline to LH, triggers an event that causes the controller to call the BAPI and return the table content. Clicking this button I can record the POST action with Firebug:

http://nwce1:50000/webdynpro/resources/tobias.com/test~wdj~arfc/FlightListApp?SAPEVENTQUEUE=Button_Press%EE%80%82Id%EE%80%84MHDJ.New1CompView.Button1%EE%80%83%EE%80%82ClientAction%EE%80%84submit%EE%80%83%EE%80%82urEventName%EE%80%84BUTTONCLICK%EE%80%83%EE%80%81Form_Request%EE%80%82Id%EE%80%84…form%EE%80%85Async%EE%80%84false%EE%80%85FocusInfo%EE%80%84%40%7B%22sFocussedId%22%3A%20%22MHDJ.New1CompView.Button1%22%7D%EE%80%85Hash%EE%80%84%EE%80%85DomChanged%EE%80%84false%EE%80%85IsDirty%EE%80%84false%EE%80%83%EE%80%82EnqueueCardinality%EE%80%84single%EE%80%83%EE%80%82%EE%80%83&sap-wd-appwndid=ab98f4f2ae8f11e18027000c292b255f&sap-wd-cltwndid=ab98f4f1ae8f11e194f4000c292b255f&sap-wd-norefresh=X&sap-wd-secure-id=ab98f4f3ae8f11e18e55000c292b255f7276476579

Replaying the POST in the browser gives me the content WDJ returns to the browser:

Response in the browser

Response in firebug

The returned content is an XML file containing the data for the table. As you can see, WDJ return the table content as HTML. [Note: Whoever at SAP was or is or will be responsible for this: why? And please stop doing this. This should be done via AJAX and JSON / XML, and definitely you should not transfer HTML. That makes me wonder if the HTML transferred back changes between browsers.]

Conclusion: That POST triggers the server side event and returns the right content. This POST is what ab should send to the server.

How to get ab to send the exact same POST? For this ab offers 2 parameters that have to be used together: -p and –T. The parameter –p defines a file that contains the data to post and –T the content type. Saving the POST data in a file named postwdj.txt and set –T to application/x-www-form-urlencoded; charset=UTF-8.

Using only these two parameters won’t work with WD applications as WD checks the header for the user agent. The browser has to send a user agent that is supported by WD. To set the user agent for ab to IE (I use IE to be on the safe side as support for other browsers heavily depends on your SPS):

-H “User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”.

The next step is to authenticate the session if the application needs an authenticated user. How exactly you do authentication depends on your server configuration, you can enable basic authentication with ab or send the JSESSION (or MYSAPSSO2) cookie to the WD app: -C JSESSION=<value>

Setting the parameters:

ab -v 4 -n 1 -p postwdj.txt -T “application/x-www-form-urlencoded; charset=UTF-8”

-H “User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”

-C JSESSIONID=abc123

http://nwce1:50000/webdynpro/resources/tobias.com/test~wdj~arfc/FlightListApp

[Reminder: all these parameters I retrieved from what firebug recorded.]

Returns:

Did it worked? No. Why? “Request referes to an unkown session”. Unkown session? Yes, even with JSESSIONID as the AS Java session identifier, WD is more complex. Take a look at the complete POST data:

sap-wd-appwndid=09c61082af0811e1a8d7000c292b255f&sap-wd-cltwndid=09c61081af0811e1adf6000c292b255f&sap-wd-norefresh=X&sap-wd-secure-id=09c61083af0811e19571000c292b255f6987261425&SAPEVENTQUEUE=Button_Press…

There are several WD specific sessions involved. And these expire too. Make sure that the POST data you get from firebug is valid when you execute ab. With updated POST data:

Now, is that the result expected? Sometimes ab outputs the first lines of the response, sometimes not. To really know what the server returned I use Wireshark. Wireshark allows you to trace the TCP packages and to view the transmitted HTML. The image below shows the result of a not working POST, as the web page of the WD app is returned:

HTTP 200, but the POST was not triggered correctly, so the WD application returns the default view:

A Wireshark trace of a successful ab POST:

And the result at the command line when ab prints the returned message:

Running the test with 1 thread 100 times:

  • Worked fine

10 threads:

  • Worked

Running the test with 30 thread 100 times:

  • Worked

The problem is that too many connections to the application were made, and the session was never terminated, thus causing more and more memory consumption until my server crashed. There is a SAP note explaining this behavior and that in the end of the test run you should terminate the session. With ab this won’t work.

While ab allows you to test web and portal applications quite easily, it is not flexible enough for testing WD applications. Instead of being able to just run the test, you have to get the POST data and run the test shortly after. What ab is missing is to submit forms dynamically (like curl) or to build the POST data based on what the server expects. But for that you need to consider the flow of the application, something ab is not aware of. For testing complex web applications there is a handy tool also available from Apache: jMeter.

Let the world know

Portal Development – Why Web Dynpro Java is replaceable

Posted on by

Note: 1st published at SCN on 28.12.2011

You don’t need Web Dynpro Java for portal development. There are easier and more valuable alternatives available.

In the blog SAP NetWeaver Portal: Development Options the different alternatives for developing SAP Portal applications where outlined, including a small guidance when to use what and why. One thing that stands out it the fact that Web Dynpro Java (WDJ) is part of the Portal Developer training and certification. Why? You don’t need WDJ for portal development, and WDJ standalone rarely makes sense. So: why WDJ at all?

For those saying: Should Web Dynpro Java be preferred over portal and Visual Composer development because it is enterprise ready? No.

Of course there are some very specific scenarios where WDJ makes sense, but until today all of these scenarios stamped the proof of their existence in the comparison of WDJ against WDA; like: when you have a really high number of users. The problems you get with WDJ are endless and feared in IT organizations. Just the problems with transporting the application led companies to prefer WDA over WDJ.

The alternatives to WDJ SAP gives you are:

I won’t consider BSP or WDJ or anything other ABAP based here. If you want to run your (maybe even public) web applications on your productive ABAP instance is your decision.

J2EE applications or portal applications are made for small to big projects. Java standards were designed with this in mind. NW AS Java development allows you to use JCo and Web Services ootb to integrated backend systems. The portlet response can be fully controlled, making it possible to create JSON / AJAX applications while JSP gives you control over the layout. Applications can be created using the SAP design or your own using taglibs. It’s up to you how you want your application to look and behave. No need to wait for new Service Packs to get a new functionality regarding the layout or the Javascript as with WDJ: You can insert your own Javascript and layout.

Finding developers with the needed skill set is easy: JSP and web applications are standard, developers from Open Source and other venders like Oracle can reuse their skills.

Visual Composer on the other side allows easy and fast creation of web forms and to display backend data. At the same time when a WDJ developer is still creating the HTML table where the information retrieved from a BAPI will be shown the application is up and running with Visual Composer. You can easily create mockup services and start modeling the application without waiting for the backend system to be ready. Just enter some dummy data and you can start developing your application. It is not meant for highly customizable applications, but for normal applications where you want to expose backend data and write back. Sure, the first versions of VC (specially 7.0x) are not really what you expect, but starting with VC 7.2 it is a very powerful tool. The skills? VC is a modeling language. Every developer and even business users that have a basic understanding of NetWeaver and UI controls can develop their own applications. Training is easy and fast: in just a few hours people can already start using their first application.

A central web based access to information and application makes sense. J2EE and JSP applications can run on every device, something that WDJ cannot and never will. Visual Composer is more complicated. When you use the flash runtime, you get an application using flash – nothing someone really wants. But the application will work on Android devices with flash installed. When you use Web Dynpro as the runtime, you get the limitations of WDJ. What’s missing is a new runtime, one that enables the easy consumption of VC applications on every device. Like the new SAP UI5. With a HTML5 runtime VC applications can run on every device. This will also close the gap for Portal on Device (PoD) and the missing mobile compatible applications. If you agree with this, here is an Idea Place where you can vote for a HTML5 runtime for Visual Composer. https://cw.sdn.sap.com/cw/ideas/7510

A problem for JSP and VC is that SAP didn’t really paid intention or invested in the tools like they did for WDJ. Creating a JSP page using the SAP taglib for HTMLB UI elements means that there is no wizard available. You’ll have to create the layout manually. VC comes with a graphic modeling tool that helps you to not only create the model but also the UI of the application.

Let the world know