Friday, October 31, 2014

Pre-requisite for SAP GUI Protocol scripting in Loadrunner

The fundamental requirement of Loadrunner to record and run SAP GUI scripts requires few settings at client and server side. Here are the main settings you need to incorporate:
1. Enable scripting at client side:
  • Install SAP GUI client on Vugen
  • 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.
  • Once you have script SAP GUI complete package installed, configure all the required systems in SAP GUI, You will require the details of servers like server name, system number etc.
  • Ensure you have connectivity between SAP GUI and SAP server, if not then request for necessary ports to be opened.
  • You need to enable Scripting as circled in the red colour in the screen shot below and disable all check boxes as shown in the screen shot shown below. In order to do this, log on to SAP server, select the “Rainbow” Icon and select “Options”. And you must disable the remaining two check boxes
    - Notify When a Script attaches to a Running GUI
    - Notify When a Script Opens a Connection

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2. Enable scripting at server side:
  • Logon to SAP with a user with required privileges, User ID need to have proper privilege to enable scripting at server side. Basis should be able to provide you administrative privilege to do the same.
  • Logon to SAP using SAP GUI, run the transaction rz11, and enter parameter name sapgui/user_script.
  • Enable the parameter with the Current value changed to TRUE.  Save it and enable the changes on all the servers and scripting will be enabled the next time you log on.  

Thursday, October 30, 2014

SAP Performance/Volume testing

Its is always recommended to performance/volume test your SAP applications as SAP systems has specifically configured to the critical business processes. A successful performance testing confirms that underlying hardware and infrastructure is able to support the required transaction volume and able to generate desired response time for the critical processes.
SAP provides a wide range of products:
  • Customer Relationship Management (CRM)
  • Enterprise Resource Planning (ERP)
  • Product Lifecycle Management (PLM)
  • Supply Chain Management (SCM)
  • Supplier Relationship Management (SRM)
SAP's products focus on Enterprise Resource Planning (ERP). The company has no main product as different products serve to meet the different needs of businesses. Now a days businesses are looking for a software product that handle all the companies needs, from inventory management, invoicing customers, sales and distribution and controlling the whole business planning in one module. This need from businesses lead to the development of SAP Enterprise Central Component [ECC] system. SAP ECC offers the opportunity to integrate all software data programs by all departments by using one single database.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Following diagram depicts the 3-tier architecture of a typical SAP system
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Effective performance test planning plays a vital role in the success of a SAP performance/volume test project. Outcome of the performance test planning phase should indicate the things and order of activities need to be performed. Typical outputs of a planning phase are performance test strategy/ test plan, critical business scenarios, Targeted transaction volume and response time, SLAs, Test data requirements, Risks and mitigation plan etc.
Non functional requirement (NFR) documents is one of the key documents which may provide next level of details while planning, NFR should state all performance/volume testing related requirements very specifically like Expected transaction response time or Dialog response time or work process response time. Different architects may use different terminologies while referring to response time in the world of SAP projects, So it is recommended to understand the requirement very specifically.
 
Effective and realistic performance/volume testing requires to test the SAP systems with two main processes which is Online users and Batches/reports. Batches plays an important role while we are doing performance test to identify the capabilities of underlying hardware and infrastructure. Its is recommended to understand the 24Hrs round the clock load profile of the system and to identify the points where there is overlap between peak online user load and batches running in parallel. Along with this standalone batch jobs performance testing is also critical for the daily/weekly/monthly and yearly batches which are business critical or resource intensive. NFR document should explicitly mention the expectation and SLAs for the batches.
Based on the identifies business scenarios/batches, performance test could be conducted with three possible combinations
1. Standalone peak online user load test.
2. Peak Online+ Batches performance test
3. Standalone batch performance test
 
Batches and the interfaces with the legacy/External and third party systems also plays a key role in the performance of the SAP system, we should identify the times where we may received significant load coming from these systems and SAP system has to process the scheduled and ad-hoc requests arriving from these systems.
Successful testing of batches will give us indication of the records or data processed within a given period of time, batches are more prone to have performance deficiency and highly vulnerable to the poor SQL queries, work process consumption, high number of enque and lock entries etc.
 
Another important factor in planning the performance and volume test in test data, You should have a clear understanding of the load profile you are going to simulate as part of performance testing. Its is must recommended that test environment should have the data similar to production and volume test results will impact a lot if these are performance with lesser data in test environments compared to production. For newly built system you may have zero or very few records in the database which is expected to grow over the time, in such cases there will be a difference in the response time in production and the one you received during performance testing when testing was conducted on empty or with very few records on database.
Expectation should be set clearly with the stakeholders and project management like who is going to create the data and how data will be populated into the test environment and the efforts required to create test data.
There also should be a clear understanding of who is going to create the user IDs with appropriate role and number of user IDs required. User IDs with improper role may not be able to perform the required operation. Role based testing should also be discussed with stakeholders very specifically.
Following diagrams depicts a typical performance test lab setup
 
 
Please note that load generators running SAP GUI users should have SAP GUI installed on the machines. System resource requirement to run a single SAP GUI user is much higher than a typical web user, based on the specifications of your load generators machines you should calculate the footprint of the system resource utilization by a single SAP GUI user and accordingly you van calculate the Load generator machines required to accommodate your needs.
 

Tuesday, October 28, 2014

5 tips by HP Partner to solve the most common problems seen in Web recording

This is a very useful link which lists down the 5 tips to solve the most common problems seen in web recording.
 
 
 (This post was written by Gennady Gorenshtein, from the LoadRunner R&D Team)

Recording a LoadRunner test script in Virtual User Generator (VuGen) is usually very simple - click the record button, do whatever needs to be done in the browser, and click the ‘Stop Recording’ button.  But occasionally, the results might not be what you expected.

Here are the five most common problems seen when recording a test using the Web (HTTP/HTML) protocol, and how to resolve them.

Problem 1: No events are being recorded
Here are the most common reasons why no events are showing in the script:

The events counter keeps increasing, while the generated script is empty
This may be because VuGen’s recording mechanism fails to identify HTTP data. To fix it, ensure that your application indeed uses HTTP Web traffic. If the application uses SSL connections, make sure you choose the correct SSL version (SSL 2, SSL 3, TLS) through the Port Mapping dialog, available by clicking the ‘Options…’ button on the Record > Recording Options… dialog:
p1.png

The Advanced Port Mapping Settings dialog opens when you click ‘Options…’:
p2.png

The events counter shows less than five events, while the application keeps getting data from the server
In this case, VuGen’s recording mechanism fails to capture any network activity at all. Ensure that your application really does provide some network traffic, ie. it sends and receives data through the IP network. If an antivirus program is running, turn it off during recording. Check the recording log for any clues about the recording failure. Messages such as “connection failure” or “connection not trapped” can be a sign of the wrongly configured Port Mapping settings.
In addition, if you are recording on a Chrome or Firefox browser, make sure that all the instances of the browser are closed prior to the recording.

Problem 2: Specific events are not recorded
This problem could be caused by the event being dropped as “uninteresting”. By default, VuGen’s Web (HTTP/HTML) protocol records client requests that return an HTTP response status of 2xx or 302, and discards all other requests. If a missing request returns a response that was discarded, such as 301, you can make a modification to the registry to instruct VuGen to generate a command for it:

  • Locate the following registry key:
    • [HKEY_CURRENT_USER\Software\Mercury Interactive\Networking\Multi Settings\QTWeb\Recording]
  • Add the following string value to it:
    • "GenerateApiFuncForCustomHttpStatus"="301"
Problem 3: The recorded application becomes unresponsive during the recording
This could be caused by VuGen’s recording mechanism not being able to connect to the application’s server. Network connection errors can be seen in the Recording Log:

[Net An. Warning  (1068:197c)] Request Connection: Remote Server @ 123.123.123.123 - 5222 (Service=) Failed attempt #1. Unable to connect to remote server: rc = -1 , le = 10060)
[Net An. Warning  (1068:197c)] Request Connection: Remote Server @ 123.123.123.123 - 5222 (Service=) Failed attempt #2. Unable to connect to remote server: rc = -1 , le = 10060)

Note: the Recording log is in the ‘Output’ pane.  Make sure ‘Recording’ is selected in the combo-box on the left:
p3.png

In order to fix this problem, the Port mapping for the specific IP and port should be added to the Port Mapping dialog (under the Record > Recording Options… menu), and the entry should be unchecked. That will ensure that the above IP and port are not recorded – that application simply connects to them without any LoadRunner involvement. For the messages above the correct setting would be:
p4.png

This workaround can be done in case the communication to 123.123.123.123:5222 is not important for the business process and can be omitted. If that’s not the case, the same entry should still be added, but left as checked. That will ensure correct traffic capture to this address.

Problem 4: During the recording the recorded application shows an error message about the wrong server certificate
The problem is caused by the inability of the client side to verify the validity of the server certificate. In order to fix this problem, the LoadRunner Certificate Authority (CA) file should be added to the machine’s “Trusted Root Certificate Authorities” certificate store (in case of a Java client application, LoadRunner’s CA should be added to Java’s trusted CA list using the keytool). This file is supplied with LoadRunner, and is called wplusCAOnly_Expiration_2022.crt. It’s located in the <LR_folder\bin\certs> folder.

To add it to the store, double-click on the file to open the certificate:
p5.png

Then click ‘Install Certificate…’ to open the Certificate Import Wizard’:
p6.png

Make sure you check ‘Place all certificates in the following store’ and select ‘Trusted Root Certification Authorities’.  When the wizard is completed, you should be able to record the application.

Problem 5: The browser crashes during recording when using the Ajax Click and Script protocol
This can happen when some of the Ajax controls inside the application are not recognized by VuGen. In order to fix it:

  • Go to the  <LR_folder\dat\protocols> folder and open the WebAjax.lrp file
  • Comment out the following: DllGetClassObject:jscript.dll=DllGetClassObjectHook:ajax_hooks.dll (simply put a semi-colon (‘;’) in front of the line)
You should now be able to record the application.