Skip to Content
Author's profile photo Viktor Misurak

OutView – Analyze output files of SAP NetWeaver Java application server


I was bored recenlty and decided to create a tool which helps to analyze output files of the SAP NetWeaver Java application server. In this very first release you can open multiple std_server* output files from the application server’s work folder (usr\sap\<SID>\<instance name>\work) even for multiple server nodes in the same time. For example: std_server0.out, std_server0.ou0, std_server1.out, std_server1.ou0 files can be opened and then you can choose which server node data you want to display once all data is parsed. It’s also possible to zoom into the diagrams. Displayed values can be heap memory usage before and after GC, average memory and GC frequency. As the tool is still under development, there are things to further develop, e.g. currently it cannot distinguish between minor and full GC, and things like this. Also, I plan to add more features like displaying data from other kind of files from the work folder, do some automated analysis, etc. 🙂


  • You can go to Help -> ‘Check for Updates’ to see if there is a more recent version published.

Download ‘OutView’ from OutView |


  • Java JRE 1.8 or above.

Here is a screenshot showing memory usage data visualized based on the content of the std_server*.out files:


Best regards,


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Iliya Kuznetsov
      Iliya Kuznetsov

      Why JRE 1.8?

      Author's profile photo Viktor Misurak
      Viktor Misurak
      Blog Post Author

      Hi Iliya,

      I was expecting this question. 🙂 The application sources can be compiled with Java 1.6 too, but during runtime I experienced strange rendering issues when painting the diagram when running the application with pre-1.8 JREs. Frankly spoken, I don't want to put too much effort on making it fully compatible with older Java releases in terms of runtime behaviour. I want to 'force exclude' those issues that's why I decided to restrict the platform to JRE 1.8 or above. Since we are talking about a desktop application, it should be less effort for the end-users to install JRE 1.8 so that I can concentrate on beer. 🙂

      Best regards,