LoadRunner 9.52 – Latest Features and Bugs

LoadRunner 9.52 is mostly bug fixes, but I wanted to key in what’s new with it:

• Flex Protocol Enhancements. Improved support of externalizable objects and general protocol usability. Updated user interface for Recording Options and Run-Time Settings (Flex > Externalizable Objects node). Added Code Generation Errors dialog box that displays details about errors, as well as recommended actions.
• Web Services protocol enhancements. The Web Services protocol now supports JMS messages based on JMS topics and Windows authentication for a user other than the one currently logged-in. It also contains enhancements in the security scenarios, WS-addressing, and the signing and encrypting of SOAP headers.

Check out the Readme file for 9.52 here. There are a few bugs that have been reported recently:

KM823684 – After installing SP2, a similar entry to the one below may be seen in the replay log:

“Web Turbo Replay of LoadRunner 9.50 SP1 for WINXP; WebReplay96 build 7049 (Sep 23 2009 17:14:02)”

About HP Virtual User Generator displays 9.52.0.0 for all componenets.

Answer: The entry in the replay log (Web Turbo Replay of LoadRunner 9.50 SP1 for WINXP; WebReplay96 build 7049 (Sep 23 2009 17:14:02) ) may be seen because SP2 was developed as a patch to be applied on top of SP1 and because of this there may be cases where LR 9.50 SP1 is shown in the replay log. This can be ignored as SP2 was successfully installed.

KM825596 – When recording a script using the Flex protocol, occasionally the RTMP calls may be recorded in the incorrect order in the script.

Answer:

The following is the order of the events as LoadRunner records them:

HTTP requestt (amf) ->
TCP recv (RTMP) <-
TCP send (RTMP) ->
HTTP response (amf) <-

The problem is that in HTTP level (amf call) LoadRunner refers to the request+response as 1 item (since it generates one step for both), while in TCP level (RTMP) recv and send are independent steps. You can refer to it as a different level of resolution, different levels of API. Since HTTP resolution is lower, LoadRunner has to create one web step in one of the possible locations – before the recv or after the send. The policy is to generate according to the timing of the last event (which is the timing of the response) and not according to the timing of the first event (request sent). Of course neither of the two policies is perfect, and each one of them may fail in different cases. This is considered a LoadRunner limitation.

KM829038 – ‘Error -27717: Invalid NTLM type 2 message: “NTLM”‘ is displayed when trying to replay a script against an HTTPS web site using the “Use automatic configuration script” option. Answer: This is a known LoadRunner limitation. Vusers cannot access HTTPS resources through NTLM proxy, obtained from the proxy auto-configuration file (pac). This defect has been on the R&D list since 2006. Specify the proxy server details in the Run-time settings instead of the pac file.

KM823684 – When recording a script using the Flex protocol, occasionally the RTMP calls may be recorded in the incorrect order in the script.

Answer: This issue has been identified as a bug by R&D in LR 9.51 adn LR 9.52. R&D issued a new flexreplay.dll which resolved the issue and will be included in the next Service Pack.