This POST is what ab should send to the server. Ĭonclusion: That POST triggers the server side event and returns the right content. As you can see, WDJ return the table content as HTML. The returned content is an XML file containing the data for the table. Replaying the POST in the browser gives me the content WDJ returns to the browser: Clicking this button I can record the POST action with Firebug: 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. 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. 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. 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. You cannot test the flow of an action (load page, press button, get result). The intent is to see how fast your web server can serve a HTML page and test how different configuration parameters affect the performance. Now, is it possible to test a user action with ab? To remind you, ab is used to test a single resource. And that is the part where you can improve the performance of the application. 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. 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. Note: 1 st published on SCN on With ab, for Web Dynpro applications