LoadRunner support For Microsoft Sync Framework (MSF)

LoadRunner support For Microsoft Sync Framework (MSF)

"Microsoft Sync Framework" (MSF) is a platform that provides access/interaction with clients and peers using many different communication methods.

In order to determine if LoadRunner supports a specific MSF environment, it will be necessary to determine which technology and communication protocol is used in that specific environment. This will allow you to determine what Vuser type will be required for testing.

If a client is available for recording, begin by using the Protocol Advisor in Vugen ( File->Protocol Advisor -> Analyze Application )

Additional information is available from Microsoft at:

MSF Developer Center:

MSF Overview: http://msdn.microsoft.com/en-us/sync/bb821992

MSF Library (technet): http://technet.microsoft.com/en-us/library/cc281959.aspx

http://msdn.microsoft.com/en-us/sync/default

Advertisements

Recording using Citrix clients over 10.x

Recording using Citrix clients over 10.x

Installation of the registry patch is required for the support of all version of Citrix clients over 10.x.. Install the patch Enable_Citrix_API.reg from the <LoadRunner installation> \dat folder on Vugen and Load generator machines. The patch must be applied after each Citrix Client installation\reinstallation.

Error -205177: Failed to startup RRE due to a timeoutfunction xlrCReplayEngineStartupNotifier::WaitForStartupNotification

Error -205177: Failed to startup RRE due to a timeoutfunction xlrCReplayEngineStartupNotifier::WaitForStartupNotification

Problem

During the replay of an Ajax TruClient script in Vugen or the Controller the following error was observed:

Error -205177: Failed to startup RRE due to a timeoutfunction xlrCReplayEngineStartupNotifier::WaitForStartupNotification in .\xlrReplayEngineStartupNotifier.cpp(82), modified Sun Sep 5 16:57:31 2010, compiled Sep 14 2010 08:22:14 [MsgId: MERR-205177]
Error -205177: Internal Error – Failed on Wait for Startup [MsgId: MERR-205177]

Cause

The script was saved in a UNC path location (network drive) and is missing files from the RRE folder where the script is saved.

Solution

Two workarounds are available to resolve this issue as follows:

Option A:
First save the script locally and then save it in the UNC path.

Option B:

  1. Save the script in the UNC path
  2. Open the script directory
  3. Rename the RRE folder
  4. Reopen the script

Installation of LoadRunner’s patch get stuck

Installation of LoadRunner’s patch get stuck

The installation of LoadRunner’s patch (version 11 and above) using the HP Update the installation get stuck before 100% (see image) and doesn’t finish for a long duration.

Solution

Verify that the download process has finished:

  1. Go to the %temp% folder.
  2. Open "iHP Runtime CustomActions HP_LoadRunner_<version number>.lo0"
  3. Check if the download has finished by searching of the following format:
    process terminated (dwExitCode=0, pi.dwProcessId=<number>, szCommandLine="C:Program FilesHPLoadRunnerrun_before_modify.bat" "3" "<time>" "C:DOCUME~1<current user>LOCALS~1TempHpUpdate23095qfe.msp" "" "" "LoadRunner" "" "")

If any of the above steps fails, try downloading the patch again.

Manually Install the the patch:

  1. Abort installation
  2. Go to the folder specified as download folder. For example: C:DOCUME~1<current user>LOCALS~1TempHpUpdate23095
  3. Run the qfe.msp

Error: “Error (pp_init): Failed to load data file MsgId: MERR0” when replaying a Windows Sockets multi-protocol script

Error: "Error (pp_init): Failed to load data file [MsgId: MERR0]" when replaying a Windows Sockets multi-protocol script

Problem

When a multi-protocol script that includes the Windows Sockets protocol is created and saved using VuGen, a subsequent attempt to replay the script may result in the following error message being displayed:

Error (pp_init): Failed to load data file [MsgId: MERR0]

Warning: Extension wsrun32.dll reports error -1 on call to function ExtPerProcessInitialize [MsgId: MWAR-10485]

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

A Windows Sockets single protocol script can be created, saved and then replayed successfully.

Cause

The multi-protocol script fails to replay as a script file required by the Windows Socket protocol is missing from the script directory. The missing script file that is required for the script to replay successfully is the file "data.ws".

Solution

This file is present in a Windows Sockets single protocol script. To workaround this issue in a multi-protocol script that includes the Windows Sockets protocol follow these steps:

  1. Open VuGen and create an empty Windows Sockets single protocol script. Save the script,
  2. Select (or create) the multi-protocol script that includes the Windows Sockets protocol in VuGen,
  3. Right click in the scripts pane in the Script View and select "Add Files to Script",
  4. Browse to the folder containing the Windows Sockets single protocol script and open the "data.ws" file to add it to the multi-protocol script,
  5. Save the multi-protocol script and confirm it now replays correctly.

How can a trusted URL be specified when developing an AJAX TruClient script to prevent the NTLM “Authentication Required” popup appearing?

How can a trusted URL be specified when developing an AJAX TruClient script to prevent the NTLM "Authentication Required" popup appearing?

When developing an AJAX TruClient protocol script that accesses a URL that requires NTLM authentication, the FireFox browser displays a popup dialog titled "Authentication Required" that requests a user name and password. While this data may be specified during script recording, it is not retained and as a result the script will not replay.

It is possible to specify the URL as a trusted NTLM resource using the "about:config" preference setting tool in a standalone FireFox instance as follows:

  1. Open FireFox, type "about:config" in the address bar and press Enter,
  2. Click the I’ll be careful, I promise! button,
  3. Specify the string "network.a" in the Filter,
  4. Double-click on "network.automatic-ntlm-auth.trusted.uris",
  5. Specify the URL of the trusted resource and click "OK".

However performing these same steps in the AJAX TruClient FireFox browser does not result in the trusted resource URL being retained. How can the trusted resource be specified so that it applies during both script recording and replay?

Solution

To specify the trusted NTLM resource when developing an AJAX TruClient protocol script, do the following:

  1. Open the file "user.js" located in "%lr_path%\dat\LrWeb2MasterProfile",
  2. Locate the preference setting "network.automatic-ntlm-auth.trusted.uris",
  3. Specify the URL of the trusted resource as the value of this setting,
  4. Save the file "user.js".

The trusted NTLM resource specified will now apply during AJAX TruClient script recording and replay. This specification is only necessary on the system where VuGen is used to develop the script. It is saved with the script and applies during any subsequent load test.