Micro Focus LoadRunner – Tips and Tricks

Table of Contents

4. LoadRunner – Tips and Tricks – Feb 2021

1. Copying Runtime Settings from one script to another causes the test to fail when starting

When you copy Runtime Settings from one script to another, the test fails at the beginning of the run. When the Run Logic is copied the Runtime Settings from one script to another, causes the script validation to fail at the start of the run. The problem you face is because of the inability to start a run after copying Runtime Settings from one script to another. 

How to be duplicated: 

  1. Log on to Enterprise LoadRunner. 
  2. Going for a trial/check. 
  3. Attach at least two scripts that are distinct. 
  4. Copy the Runtime Settings from one to another script.

The problem can be corrected as follows: 

  1. Install the hotfix and remove the contents 
  2. Build a PC.Internal.WebA.dll backup file from the folder <LoadRunner ENterprise Server>\PCWEB\bin. 
  3. Copy and replace a file called PC.Internal.WebA.dll in the file above. 
  4. Go to a test in LoadRunner Enterprise in which you have copied the Runtime Settings. 
  5. Delete any scripts that you have copied to the Runtime Settings from the evaluation. 
  6. Add the scripts previously removed. 
  7. Copy back the Runtime Settings from phase 5 to the scripts. 
  8. Get the run program started.

2. System Temp folder runs out of space during project migration

Some scripts could not be copied correctly during project migration if the system’s Temp folder runs out of space. The issue is that if the system’s Temp folder runs out of space, the scripts may have not been copied correctly. The justification is because LoadRunner Enterprise uses the system’s Temp folder to transfer scripts from the ALM repository to its own repository as an intermediate folder. The scripts will not be copied if there is insufficient space available in the Temp folder.

 How to be duplicated :

  1. Sign on to Enterprise Management for LoadRunner. 
  2. Go to the tab on Ventures. 
  3. Migrate a project with a collection of very broad files. 
  4. You can see in the LoadRunner Enterprise Program that it is difficult to reach some of the scripts.

 The problem can be corrected as follows:

  1. Install the hotfix and remove the contents 
  2. Stop the Backend LoadRunner Service. 
  3. Build a backup from the <LoadRunner Enterprise Server>\LRE BACKEND folder of the AlmUpgradeEngine.dll file. 
  4. Copy and update the file with AlmUpgradeEngine.dll in the folder mentioned above. 
  5. Reboot the Backend Service LoadRunner.

3. Facing the following error when installing LG

You will face errors when you try to install the LG program. Adding a Linux LG designed to run on a custom port via a MI Listener

The problem can be corrected as follows:

1.Since in this case MiL is requested to run on port 8443 for example, instead of port 443, these are the changes that need to be done on the MiListener server.

  1. Edit the file in MiL C:\Program Files (x86)\Micro Focus\MI Listener\launch_service\dat\channel_configure.dat and add the line below in the section

  [General] OFWPort=8443

  1. Edit the file in MiL C:\Program Files (x86)\Micro Focus\MI Listener\launch_service\dat\mdrv.dat and add the line below in the section

[Launcher] OFWPort=8443

2. On the Linux LG machine here are the changes:

  1. In the below file you can change the parameter from 0 to 1

cd /opt/MF/MF_LoadGenerator/bin ./m_daemon_setup stop vi /opt/MF/MF_LoadGenerator/dat/br_lnch_server.cfg [FireWall] FireWallServiceActive=1

  1. Save the file. > vi /opt/MF/MF_LoadGenerator/config/.mercury/m_agent_attribs_$HOSTNAME$.cfg
  1. Edit the file by making the changes mentioned below: 

•ServerPort=”8443″

ServerMachine=”IP_of_MiListener”

HostSymbol=”LG_Key_to_use_In_LRE”

•Adapt the IP of the hostname, and the LG key. The new MiL 8443 port should be sent via the parameter ServerPort=8443.

3. Save the file and start the daemon.

4. Finally add the LG in LR or LRE and it should connect.

4. Release information for LoadRunner Enterprise 2020 SP3 Hotfix 1

All relevant information on how to download and update the LoadRunner Enterprise 2020 SP3 Hotfix 1 policy and related information is offered.

 We have some common questions like:

  1. Where to download LoadRunner Enterprise 2020 SP3 Hotfix1?
  2. Upgrade Policy
  3. List of hotfixes

Fixation of problem and answers to your  questions are as follows:

  1. Where to download LoadRunner Enterprise 2020 SP3 Hotfix1?

Ans: Download the below link:LRE2020_SP3_Hotfix1.zip to your LRE server(s).

This file contains several important hotfixes which appear in the list.

  1. Upgrade Policy 
  • The LRE 2020 SP3 Hotfix 1 kit is included in the patch installation package which should be used in addition to the LRE 2020 SP3 package. 
  • For LRE servers only, the LRE 2020 SP3 Hotfix 1 Package is appropriate. 
  • When installing the hotfix, you don’t need to interrupt the IIS/Backend operation. 
  • Even if it doesn’t include updates that are directly important to you, we suggest downloading this hotfix. 
  • Download a package from LRE2020 SP3 Hotfix1.zip to your LRE server (s). 
  • Extract the contents and use the ‘Run as administrator’ option to run PC 00379.exe. 
  • To download the hotfix kit, follow the instructions on the screen.
  1. List of hotfixes included in the LRE SP3 Hotfix 1. 

Ans: All the things are mentioned in the below box: 

  1. Efficiency and accessibility problems with Timeslot. 
  2. There are no TruClient scripts shown in the Script Viewer. 
  3. Instead of overriding the exit script, uploading a UFT One script produces a newly renamed script. 
  4. If there were strong tests in the last 10 runs, performance issues on the project’s dashboard. 
  5. SSO problems are case-sensitive when LRE is equipped with a load balancer and email login. 
  6. Install script problems when a load balancer is equipped with LRE. 
  7. The LRE Administration user page shows only the first 1000 users. 
  8. Unable to import users that start with a digit and have a username. 
  9. In the LRE Administration, uploading reports in CSV file format is not available.
  10. “Connect to the existing session” does not function in the Load Generator Management dialogue box when activating terminal services. 
  11. The monitor times out when collecting counters from AppDynamics. 
  12. LRE 2020 SP3 update from earlier LRE versions fails on seeding users for Admin schema. 
  13. LRE server problems with the clean up job for LoadRunner Enterprise\scripts\ and \LoadRunner Enterprise\orchidtmp\Repository\ directories. 
  14. The password reset redirect is incorrect for the multi-tenancy URL. 
  15. Multi-tenancy: In LRE Administration, the Hosts tab reveals errors when editing hosts if private load generators are running actively on the tenant.

5. Hotfix for Vugen integration issues with LoadRunner Enterprise 2020SP3

In the Test Lab, the folder tree can not extend properly if there are multiple files under separate paths of the same name. For a longer time, VUGEN’s LRE connection is not alive. For example, if a user tries to open an LRE script and make changes to the script, the connection will be disconnected and not saved to the LRE server until the script has been successfully opened. If the USER wants to open a second project script, the USER must re-authenticate with the username, password, and then pick the project. Any of the old scripts are not saved back to the LRE registry under “Save” action.

The problem can be corrected as follows:

  1. Using the hotfix to download and extract LR-2020-SP3-Hotfix-for-LRE.ZIP 
  2. Backup the original “VuGenToolkit.exe” with: percent vugen path %\bin\VuGenToolKit. 
  3. Backups the initial folder “lre-uploader” in: percent vugen path percent \binin 
  4. Backup the original “LR.VuGen.VuGenLRELRCIntegration.dll” in: percent vugen path percent \binin path percent. 
  5. Copy from Phase 1 VuGenToolkit.exe to: percent vugen path percent \bin\VuGenToolKit\VuGenToolkit.exe percent vugen path percent
  6. Copy from Phase 1 to the lre-uploader folder: percent vugen path percent \bin\lre-uploader 
  7. Copy the file LR.VuGen.VuGenLRELRCIntegration.dll from Phase 1 to percent vugen path % \bininLRELRCIntegration.dll 
  8. The initial “HP.LR.VuGen.DebuggerAddin.dll” backup is located at: percent vugen path % \Addins\VuGen\FrontEnd\VuGenDebugger\VuGenDebugger.dll 
  9. Copy HP.LR.VuGen.DebuggerAddin.dll to : percent vugen path percent \Addins\VuGen\FrontEnd\VuGenDebugger 
  10. If the proxy fails to link to LRE via VuGen, define the following device variables on the VuGen machine:

a.HTTPS_PROXY=http://<my-proxy>:<port> b.HTTP_PROXY=http://<my-proxy>:<port>/  c.Reboot the Vugen programme 

6. Is there a way to remove the license key ?

 There is a solution to every problem. Luckily, you can remove the license key. 

The problem can be corrected if you follow the below instructions :

  1. Go to the “programdata” folder (you can press the win + R keys to open the “RUN window” to write “percent programdata percentage” on it, click “OK”). 
  2. Micro Focus > LoadRunner > details. You can find the ‘LRKey.txt’ file there. 
  3. Open the following file: LRKey.txt from Notepad++. 
  4. Please check whether any LoadRunner processes are running, including Controller (Wlrun.exe), VuGen (VuGen.exe), Analysis (AnalysisUI.exe) or LoadRunner Agent Process/Service, then stop them. 
  5. Next, add LRkey.txt to the zip file for backup purposes. 
  6. LRKey.txt” –> click the right button –> edit.” Licenses are displayed in XML format. 
  7. Look for the xml block that has the licence name in order to delete the licence. 
  8. After removing the license, save the “LRKey.txt” file and close it.

7. Error -205177: Tab 2 heartbeat timeout. [MsgId: MERR-205177]”

Error -205177: Tab 2 heartbeat timeout. [MsgId: MERR-205177]”. (Truclient chrome). The problem is that when you run the load test for truClient chrome script:  you receive an error message: “Error -205177: Tab 2 heartbeat timeout. [MsgId: MERR-205177]”.  

Below are few reasons for this issue and also a further clarification on this workaround

1. What is JavaScript and what does it fix? 

Ans: This is part of the Truclient code for the Chromium browser. It stops testing whether or not the AUT is alive. 

2. What is the impact of this environmental shift? Is it confined to a specific protocol? (Chromium TC or all other browsers)? 

Ans: It’s just going to affect TC Chrome 

3. If this fix is only connected to the TC Protocol, why are any projects not facing these problems using TruClient protocol chrome? 

Ans: This is only connected to the TC Protocol. It depends on the web application is running (Application Under Evaluation, AUT) TC and the machine’s current load. This error is recorded by TC when we think the web application page is hanging

4.Are we just suppressing the error or fixing it?

Ans: We only suppress it, because often we find that it reports false results (the web page is still alive, but we are still reporting heartbeat error). There’s still no permanent remedy available. 

So, it should be OK to do it if all transactions look nice when we disable this function. A permanent fix is not implemented in LRE/LRP 2020 SP3, but the work remains the same. In TruClient, AUT reports to TC repeatedly once every few seconds saying “I’m alive” This is done by calling setTimeout() web API. 

TC will record this “heartbeat” error and stop the current running phase in the TC script if TC does not hear this report for a while.

In certain instances, it is also found that the timer set in the AUT will be cleared by the AUT. This will also cause TC not to hear “I’m alive” from AUT for a moment, so this timeout error will be raised. MF RnD re-alters the implementation to place the setTimeout in TC instead of AUT for this particular problem.

How to fix the problem?

•There is no permanent fix yet for this.

Suppressing the error message is the only thing you can work through. This has to go on ALL machines with load generators (wherever the truclient chrome with heartbeat problems scripts are being run)

The problem can be corrected as follows :

  1. But if the controller behaves like LG, then the controller still needs to make this adjustment. 
  2. Close all processes/services of the loadrunner or load generator where this adjustment needs to be made. 
  3. Find DRRECommunicationMain.js” under % lr path%dat\TCChrome\Extension\RRE\content\DRRECommunication” folder. 
  4. Then comment out the line “DRREHeartbeatMgr. onCheckTimerTimeout();”

Refer the example below:

_setCheckTimer: function ()
{DRREHeartbeatMgr._checkTimer = setInterval(function ()
{//DRREHeartbeatMgr._onCheckTimerTimeout(); }, DRREHeartbeatMgr._interval);}

Note:  For various versions, this js file can be different. You may also create a support ticket and provide them with the file above to make modifications.

8. VuGen integrations to LR Enterprise – Not able to expand folders that contain too many scripts saved on them

LR Enterprise VuGen Integrations – Unable to extend files with so many scripts saved on them. The issue is that most of the folders can be expanded when you open VuGen, link to LRE and try to expand the folders. If, however, the folder contains so many scripts inside it, nothing happens when you click on it to expand, they will not expand. If we try to extend certain directories that contain too many scripts directly from LRE UI, there are no problems.

The problem can be corrected by following the below steps :

  1. Install and decompress the attached LRE-uploader file. 
  2. Go to <Installation route for LoadRunner/VuGen>\bininin 
  3. Look for the lre-uploader folder and make sure to create a whole folder backup. 
  4. Change the existing folder for lre-uploader with the new folder downloaded from move

9. LRE 2020 SP2: Health check shows failed messages, even though the environment is working perfectly fine

LRE 2020 SP2: health check shows failed messages, even though the environment works perfectly fine. For example: check host and backend service connectivity check load test web service management. The environment works just fine. All of the services run on all the LRE modules. Failed messages listed above, however, are shown by health tests. Seems like the host maintenance job is keeping the LRE server busy. So failed messages are seen by a health search.

The problem may occur because of many reasons like: 

  1. Server tab
  2. Check load test management web service
  3. Check Load generators are accessible with DB credentials
  4. Check server user identity
  5. Check the time series Dbs on hosts are accessible from the server
  6. Hosts tab
  7. Check connectivity between host and backend service

The problem can be corrected by following the below steps : 

  1. Disable Task Host Maintenance 
  2. We may also minimise the frequency of host maintenance activities, but errors in health checks are seen occasionally. 
  3. It is better to disable it. 
  4. The problem does not exist with the LRE 2020 SP3.

10. NtityUnlocker fails to authenticate over HTTPS when TLS 1.0 and SSL 3.0 security protocols are disabled on the host machine

When TLS 1.0 and SSL 3.0 security protocols on the host machine are disabled, EntityUnlocker fails to authenticate over HTTPS. The issue was resolved in LRE 2021. The explanation may be that the version of the .NET System application was designed with is hard-coded to use TLS 1.0 or SSL 3.0 by default. When these protocols are disabled on the host and the LRE server uses HTTPS, EntityUnlocker would fail to authenticate because it will not be able to access a secure connection to the LRE server.

The problem can be corrected by following the below steps : 

  1. Install the modified EntityUnlocker.zip and remove its contents 
  2. In the <LoadRunner Enterprise Server>\PCWeb\Downloads folder, place EntityUnlocker.exeder

11. Error: “Couldn’t initialize the Detection library” when running Teradici PCoIP Vusers

If Teradici PCoIP Vusers are operating from the Controller on a remote load generator built by OneLG, Vusers will struggle with:’ Unable to initialise the detection library’

The problem can be corrected by following the below steps : 

  1. To find PCoIP replay.dll, install the Hotfix and remove its contents 
  2. Go to \bin to backup the original pcoip_replay.dll file. 
  3. Substitute the one downloaded from the first step

PS: The issue will be officially fixed in LRP and LRE  version 2020 SP3