Micro Focus introduces New Protocol : TruWeb

Micro Focus has introduced a brand-new protocol to its outstanding line up of protocols. TruWeb is created with a developer mindset. It is a protocol that focuses on the HTTP (transport) level, providing a lightweight, scalable and cross-platform solution for web protocol testing.

This protocol is available in version 12.60 of LoadRunner and Performance Center as well as StormRunner Load. You can start to take advantage of the capabilities that TruWeb has to offer. You can write a TruWeb script using Virtual User Generator (VuGen), Atom.io, JetBrains WebStorm (IntelliJ), or other IDEs and tools.

TruWeb allows performance engineers, testers and developers create scripts on any platform. It supports Windows, MacOS and Linux. You can record scripts via HAR files or the TruWeb Proxy Recorder. On top of this, TruWeb can also be ran as a standalone solution. You can run TruWeb in single mode, which runs a single iteration for a single Vuser, or in load mode, which runs the script use the scenario settings defined in the scripts scenario.yml file.

TruWeb is currently in Tech Preview. It is in its first phase of its release. The below links will allow you to read more of the current capabilities as well as download and give it a test drive.

TruWeb is currently in Tech Preview. Meaning you do not need a license to run it. However, this may change in future versions.

How to include header files in LoadRunner scripts

Using a header file

You can define the functions or variables in a header file so that you can share the information among different scripts. After you have created the header file, you need to use the #include directive in a LoadRunner script to refer to it via either of the following ways:

The following solution assumes the name of your header file is my_header_file.h.

1. If the header file is not in the script or the <LoadRunner>\include directory, you will have to specify the full path to it in the script:

#include “c:\\Application_A\\additional_include_files\\ my_header_file.h ”

You need include two two backslashes (\\). Make sure that the header exists on the remote LoadGenerator machine at the same location when running the test from Controller

2. If the header file is in the script folder, you need to add the following to the beginning of the script:

    #include <my_header_file.h>

From the script directory open .usr file with a notepad.
Then, add the file under the [ExtraFiles] section of the script’s .usr file and save it.Example:


This will show the header file listed in the Controller as the file to transfer to remote LoadGenerator. Right-click on the script and select Details -> More -> Files in the Controller Design view. If you still do not see the file, click on “Add” to add the header file.

3. If the header file is in the <LoadRunner>\include directory, you need to add the following to the beginning of the script:

#include <my_header_file.h>

Make sure that you copy it to the remote machine during the load test.

4. As you can see, LoadRunner only scans through the script or <LoadRunner>\include for header files by default. It will ignore the $INCLUDE environment variable as well. If you would like LoadRunner to scan a different directory, such as C:\Application_A\additional_include_files, you can do the following:

It is recommended that you back up your files before you modify them.

  1. Create a file with the following line:   -I<path to your additional include directory>

    1. Create file called include in C:\temp.
    2. Add the following line to the file:


  2. Add the following to the Vuser command line (could be through the MDRV.dat file):   -compile_flags <Full path to the file saved in step #1>

    1. Open <LoadRunner>\dat\MDRV.dat.
    2. Edit the [lrun_api] section, adding the line:

       ExtCmdLine=-compile_flags c:\temp\include

  3. In the script, include the header file.Example: 
    #include ” my_header_file.h”

    where my_header_file.h is in C:\Application_A\additional_include_files.

Note: If you want to run the script on a remote LoadGenerator, you need to make sure that the header file exists on the remote LoadGenerator

License Manager was not initialized

In the Controller when running a test if the following error is shown : Error Message "License Manager was not initialized"

The reason for this error to occur is because the user account doesn’t have the required permissions to initialize the LoadRunner libraries and interact with the operative system.

Be sure that you are using a full Administrator account over the machine where the Controller is installed. Any other permissions group will affect the load test.

Completely disable the DEP and reboot the machine.

Open an Elevated Command Prompt

i. Open the Start Menu

ii. Click All Programs and Accessories

iii. Right click on Command Prompt and click Run as Administrator

iv. Click on Continue

To Disable DEP

i. In the Elevated Command Prompt, type:

bcdedit.exe /set {current} nx AlwaysOff

ii. Restart the computer to apply

Correlation studio response time improvement

The Correlation Studio in LR 11.5.X might take some time for finish the correlation scanning process. To improve the time it takes to respond quickly try the below mentioned points.

1. In the recording options disabled the response based correlation and async scan options. And try one more time. If the error persist continue with the next steps.

2. Use the attached DefaultComponentSuite.xml. Please replace the file that is located under <LR_Installation>\config\, and restart the VuGen, restart VuGen. That will be much faster, 20 seconds for scanning. Make a backup file of the original before any modification.

3. Disable record scan. The user can also turn off the record scan by unselecting it in the Recording Options dialog.

Error: “smmdrv.exe access violation” when performing a load test using a SAPGUI protocol with LoadRunner

SAPGUI protocol load tests may fail if the "Show SAP client during replay" option is selected in the Runtime Settings.

While performing a load test with LoadRunner using a SAPGUI protocol script, the test fails after approximately 10 mins or 30+ iterations have been performed in either VuGen or in the Controller. The following error is reported:

smmdrv.exe access violation

The "Show SAP client during replay" option should not be selected. It is recommended that this options is only selected when debugging a SAPGUI protocol script in VuGen. If the "Show SAP client during replay" option is enabled, memory consumption increases dramatically, eventually causing the test run to fail.

In the Run-Time Settings -> General tab, ensure that both the "Show SAP client during replay" and "Take Active Screen snapshots during replay" checkboxes are not ticked.

Avoid high CPU usage while running SAPGUI Vusers

When running a load test with 10 SAPGUI Vusers on a remote generator, the smmdrv.exe file is found to be using up more than 80% CPU.

To reduce the amount of CPU used during a load test turn off the "Save Snapshot" option in the Run-Time Settings as follows:

1. Open the script in VuGen.

2. Open the Run-Time settings dialog:

· Clear the "Take active script snapshot during replay" checkbox.

Note: If this option is disabled, you need to first select the "Show SAP client during replay" option, then clear this option.

· Clear the "Show SAP client during replay" option.

3. Click <OK> and save the script.

4. Add the new script to the Controller.

5. Replay the script without changing the Run-Time Settings from the Controller.

Error “This script was generated with an outdated DFE engine”

If you encounter the following error when trying to replay a script created with previous versions of VuGen:

Fatal Error -26000: This script was generated with an outdated DFE engine, regenerate the script in order to successfully replay the DFE steps.

Warning: Extension lrwreplaymain.dll reports error -1 on call to function ExtPerProcessInitialize

Error: Thread Context: Call to service of the driver failed, reason – thread context wasn’t initialized on this thread.

This error occurs because the script is being replayed with a version of the DFE engine newer than the one it was generated by. It usually happens if new patches are installed after the script was recorded.

There are 2 possible workarounds for this issue

1st Workaround

The following 3 steps should fix the issue:

1. Navigate to the script folder

2. Delete the folder named DfeConfig

3. Regenerate the script in VuGen.

2nd Workaround

1. Open script folder

2. Delete DfeConfig folder

3. Replay script