Page tree
Skip to end of metadata
Go to start of metadata

This page is part of:


Tiny link (useful for e-mail):

Performance aspects

This information should help you to analyze performance problems with ITSmobile services. Performance problems are always difficult to analyze but you should at least be able to verify if the performance gap is related to your sap system, your application, your network or your mobile device. We will not exactly measure response times and the data traffic of ITSmobile services, neither will we dive into the performance analysis of the sap system, but instead we will try a couple of simple basic tests to figure out where the performance comes from and whether it makes sense to invest more time to get a better overall response time.
Please keep in mind, that mobile services are ABAP based. Always call the services you are going to analyze a first time to let the SAP system compile the ABAP sources and fill the buffers. The ITS also needs this first call to pre-parse the templates and store them into its template cache. The ICMAN has to read the mimes out of the database into his HTTP-Plugin server cache. All this has to be done during the first access, so in general the first call of a service is not of interest for performance analysis.

1) Performance checklist

First step is analyzing and understanding the performance problem. That means we have to check the performance of each involved component. In rare cases, you additionally have to check if the problem is related to a specific SAP server, to a single location, to a specific application or to distinct screens of an application.

Involved components:

  • SAP system 
  • Application
  • Mobile Device

SAP system

To check the system's performance, start the SAPGUI for Windows and call a couple of SAP basis transactions like SE38, RZ11, SM50 or SM04 to get an idea of the application servers performance. If the performance of these transactions is already poor it does not make sense to continue with performance analysis of the mobile services. Use the SAP basic tools to find the reason for the poor system performance.


ITSmobile Services are ABAP based, that means the mobile transactions can be called with the SAPGUI for Windows. Logon to the system and call the mobile transactions with the SAPGUI for Windows. You will find the transaction of the mobile service within the ICF service tree (transaction SICF), in the GUI settings, parameter name ~transaction. Sometimes, if you start this transaction within the SAPGUI you will get an error message, that the transaction could not be started. Simply terminate the easy access menu ( enter "/n" in the okcode field until you get the "Start Easy Access Menu" screen.). Now the transaction can be started in the SAPGUI for Windows.
Input exactly the same data as on your mobile device and you will get an idea of the performance of the transaction. It doesn't matter if you call the transaction using SAPGUI for Windows or via Browser using HTTP, in both cases the same application code is running and will need the same execution time to reproduce the same results. If the performance of the transaction is bad, use ABAP tools to find out the reason. In that case it does not make sense to continue with the analysis of the performance of the mobile service.


Next step is to check the response time of the HTML/HTTP related components in the backend. Start your favorite browser on your desktop PC and call the ping service ( URL: http://<server>:<port>/sap/public/ping?sap-client=000 ) to get an idea how long the access of an HTTP service in the backend takes. After testing the ping service, start the ITSmobile service "itsmobile00" (URL: http://<server>:<port>/sap/bc/gui/sap/its/test/mobile/itsmobile00?sap-client=000 ). On your desktop PC you probably will not experience a big difference between both services, despite the fact that the service "itsmobile00" has to run a small piece of application coding, the ITS has to convert the data stream to HTML and the browser has to draw the HTLM page. If possible repeat the test with your desktop PC connected using the same WLAN as your mobile devices, that gives you an idea if the wireless network has any effect on the response time.

Mobile device

Test on your mobile device:
Do the same test calling service "ping" and calling service "itsmobile00" on your mobile device. If there is a big difference between the response times on your desktop PC  and your mobile device the performance problem is related to the mobile device. The performance problem is NOT backend related.

2) Known performance issues with mobile devices

If you run the tests described in 1) "Performance checklist" you usually end up with the insight, that as long as no mobile device is involved the performance is perfect. The ping test from above is the only test case which is pretty fast on mobile devices too. The reason is, that the transferred data rate is pretty small and there is not much to paint for the browser. If you start the "itsmobile00" test service on your mobile device you probably already recognize a much longer response time. This longer response time is the result of the limited CPU power and the poor rendering performance of the browser on many mobile devices. Let us now look closer to these limitations and discuss how we can get around them to improve the performance on mobile devices.

Configuration: battery lifetime versus CPU speed/RAM retention

On many mobile devices you will find a menu path like "Settings->System->Power->Battery" that leads to a slider where you can configure the mobile device to increase battery lifetime by decreasing RAM retension/performance.
Check this setting on your mobile device.

Mobile browsers without cache (obsolate)

Nowadays this issue can be ignored; the devices on the market support caching.

The HTTP data stream of ITSmobile services can be divided into mimes and template data. The template data contains application values and is changing with every application screen. Mime data is very stable, the content of mime files usually changes only during the developing phase of a service or if you implement bugfixes. If a mobile device has no browser cache, the mime data is requested and send again and again from the server with every submit even if the content does not change.
You can use the ITS publish service to store the mime data directly on each mobile device and avoid unnecessary network traffic. To access the local stored mime data you have to set the ITS parameter ~urlmime to the local storage location. That's it. At runtime the ITS will read the ~urlmime parameter and use its content to generate the mime links in your html templates referring to the local storage location. The mimes will not longer be sent over the network, the mimes will be read from the local file system instead. The disadvantage is the administrative overhead. You have to copy the mimes onto every mobile device. If a mime file changes, you have to get the changed file to every mobile device. By the way, many mobile devices already has software available which helps you to automate the distribution of files to many single devices.

Mobile browsers, not supporting table-layout style (slow table rendering) [only valid for old ITSmobile generator]

Some mobile browsers do not support absolute positioning in HTML pages therefore the ITS template generator has to use HTML tables for the page layout. The table layout is done with a character table spanning the complete screen using the character positions from the dynpro for the single fields. This produces an HTML layout pretty close to the dynro screens. To help the browser to render this pages faster the style "table-layout:fixed" is set. Mobile browser which do not support this attribute need much more time for rendering because they have to calculate each single cell and column size based on the content. Tables are also used for rendering subscreens, frames and step loops. Having a dynpro screen, containing a subscreen with a step loop on it leads to HTML pages containing 3 nested tables. The result is a poor rendering performance on browsers not supporting fixed table layouts.

For the old ITSmobile template generator (which creates templates with HTML tables) the following information applies:
If possible, avoid such constructions on mobile screens. Anyway it's always a good idea to keep mobile screens simple. If you don't like to change the dynpro layout, you have to manually change the generated template to speed up the rendering. The ITS template generator can not do this, because of its generic way creating the templates.
If you manually change the generated template, try to replace the <table> with a <div> tag, convert the table lines (<tr></tr>) to line breaks (<br>) and use the <span> tag for cells (<td>). This could reduce the rendering time to less than 50% of the original, generated page if nested tables occur on the page. You may optimize the HTLM for a single screen only, or create your own template generator to optimize all screens for your specific browser. Please keep in mind, optimizing the generated HTML is a consulting issue. You need detailed HTML knowledge.

For the new ITSmobile template generator (which creates templates with HTML DIVs) the "slow table rendering perfromance information" is not valid anymore.
However - here it is sometimes required to optimize the screen using an own CSS stylesheet (consulting issue). From consulting point of view (where performance plays an important role) the recomendation is to use the new DIV HTMLB ITSmobile template generator. The new generator cannot ensure that all screens look the same as in the SAP Gui but the performance is better compared to the old ITSmobile generator.

3) Conclusion

The performance of ITSmobile services mainly depends on the used mobile devices. Saving money here has to be paid for effort to optimize the generated html or to admistrate local mime files on each device to improve the performance.