SilkPerformer

From the TCodes, it does a reasonable job of monitoring the SAP system on the overall performance.  The TCodes should cover (a) SAP Buffer performance, (b) Dialog Step performance (response time), (c) database performance at the database buffer cache and shared pool level and (d) operating system performance such as processor and memory.

Through this setup, SP Controller merely make a normal connection like a typical SAPGUI Front-end.  Therefore, typical ports used by the SAPGUI Front-end such as TCP32## and TCP33## are required.  Furthermore, the user account used for the monitoring should have sufficient privileges to access the mentioned TCodes.

In LoadRunner SAP monitor, it requires the SAP CCMS (Computer Center Management System) for monitoring to be effective.  This is unlike the typical monitoring mechanism that is used for Windows or Oracle (refer to “How does the monitoring work in LoadRunner?”), which is directly querying the monitor data from Windows Perfmon or Oracle V$ dynamic views.  LoadRunner SAP monitor requires an additional component, SiteScope (refer to “What’s SiteScope”) to act as an intermediary between SAP CCMS and LoadRunner.

LoadRunner itself does not have the capability to monitor SAP directly and solely depends on SiteScope to query/monitor SAP CCMS.  SAP CCMS is already a powerful component in SAP as it is able to monitor anything in the SAP system. This ranges from server resources (e.g. processor or memory utilization) to oracle databases (e.g. buffer efficiency).  You may not even require other tools to do monitoring in the first place!  No additional configuration needed for monitoring Windows resources (Windows Resources) as SAP CCMS handles it by a single channel through SiteScope.

For SiteScope to communicate to SAP CCMS, it will require SAP Java Connector (JCO) to be installed on the SiteScope box with some configurations to access the SAP system.  The detailed configuration can be found in Configuring Sitescope Monitors documentation (instead of LoadRunner).  To download SAP Java Connector, you can go to Connectors in SAP site.  You will need a valid SAP account to access the download page.

On the ports portion, you will need to have TCP32## between the SiteScope and the SAP system and TCP8888 between SiteScope and LoadRunner (Refer to “Implementing SiteScope with LoadRunner”).  TCP32## is the typical port number used by SAPGUI Front-end to talk to the SAP application servers while TCP8888 is used by LoadRunner to query the monitoring data displayed on the XML page of SiteScope.  Both port numbers are to be opened on a two-way traffic communication.
As SiteScope is querying monitoring data just like a normal user running the CCMS transaction from SAPGUI Front-end, a SAP account on the SAP system required.  The following information must be ready prior the setup of the monitoring.

• SAP Client
• System Number
• Authorization User Name
• Authorization Password
• SAP Router String (Optional)

Do take note on this!  With all things mentioned about SAP CCMS with LoadRunner-Sitescope, there’s a catch (at least to me).  SiteScope requires an optional license to monitor SAP CCMS.  Which means, that if you are just having LoadRunner, it’s not sufficient to setup the monitoring environment.

Performance testing recording and execution for SAPGUI relies on the SAP Scripting API and ActiveX the SAP R/3 application server and on all SAP GUI clients that are participating in the load test. As of date of this article, LoadRunner documentation does not have updated details on configuring SAPGUI for scripting such as supported versions.  However, the configurations are somewhat similar to other performance testing product which in this article, we refered to IBM instead.

The basic requirements for LoadRunner (or performance testing tools) to record SAPGUI is on two things: (a) the client machines to have the entire SAPGUI Client installed and (b) the SAP server to have scripting enabled.  (c) Other than the configurations, you may have to take note of the ports used by the SAPGUI, namely, TCP32## where ## represent the System Number.  This is especially important if the environment you are in is tight on opening of ports.

[1] Ensure client scripting enabled

• To ensure that scripting is available on the client-end, check that there is a Scripting directory located in the SAP GUI installation directory.  If this directory does not exist, then the SAP Scripting API is not installed and you must reinstall SAP GUI with the SAP Scripting API option.

[2] Ensure server scripting enabled

• Logon to SAP with a user with administrator privileges.  Administrator privileges is required to enable scripting on the server.
• In SAP, run the transaction rz11, and enter parameter name sapgui/user_scripting.
• If the parameter is not found, ensure that you have the correct support package level from SAP and contact SAP should you require further guidance on this.
• If the parameter exists, enable the parameter with the Current value changed to TRUE.  Save it and scripting will be enabled the next time you log on.

(Source: IBM, Configuring SAP R/3 for performance testing)

[3] Ensure communication between SAPGUI with SAP servers

Ensure that you have connectivity on TCP32##.  This is the port number used by SAPGUI to communicate to the dispatcher.

Also, before starting the scripting, for newbies, you may like to gather the following information as they will be used for the scripting work.  The user account used in the scripting (accessing the SAP system) should have sufficient privileges to the transactions.

• SAP Client
• System Number
• Authorization User Name
• Authorization Password
• SAP Router String (Optional)

In summary,

• Ensure client scripting enabled
• Ensure server scripting enabled
• Ensure communication between SAPGUI with SAP servers