How to Resolve Object Identification Issues in Ajax Trueclient Script

In dynamic websites, objects which have been recorded can often move or
change content. This can cause the script to lose the ability to locate the
object. The following steps describe the ways to resolve these issues. When
identifying objects for applications that recorded in windows, make sure
that the correct window is selected using the Window tab.
 - "Highlighting an object"
 - "Improve Object Identification"
 - "Modify the Object Identification Method"
 - "Modify the script timing"
 - "Relating objects to other objects"
 - "Replacing an object"

1) Highlighting an object
Regardless of which method of object identification is used, you can use the
highlight button to check if an object is visible in the application at any
time. If the object cannot be found, an error message is displayed.

2) Improve Object Identification
Use this option first if the object was not found or if multiple objects were
found. Objects are identified using the objects properties. Some of these
properties may be dynamic and thus prevent object identification during
replay. The Improve Object Identification button next to the ID Method
field identifies the object a second time and uses the two definitions to
create a more accurate object definition.

3) Modify the Object Identification Method
You can modify the way TruClient identifies the object by modifying the
object identification method in the Object section of the step properties.
defined The following options are available:

a)Automatic. TruClient’s default object identification method. If this
method does not successfully find the object during replay, click the Improve Object Identification button and replay the script again.
b)XPath. Identifies the object based on an xpath expression that defines
the object in the DOM tree. You can manually modify the expression.
To regenerate the original expression generated by VuGen, click the
Regenerate Expression button.
c)JavaScript. JavaScript code that returns an object. For example:
document.getElementById("SearchButton") returns an element that
has a DOM ID attribute of "SearchButton".

4) Modify the script timing
Sometimes objects may not be found because of timing and
synchronization issues. For example, the script may be looking for an object
that was in the application, but the script replayed too quickly and already
progressed to another page. If you suspect that the object is not being found
because of a timing or synchronization issue, you can insert Wait steps.

5) Relating objects to other objects
If an object becomes difficult to identify on its own, you can label the object
based on a different, more stable object. For example, you can select an
object which is not dynamic and "relate it" to the target object. Relations are
defined visually, relating objects according to their distance in pixels from
other objects. Relations are defined per ID method, per object. If more than
one relation is defined for an ID method of a given object, both relations
must locate the same object for the step to pass. VuGen then uses this object
to help locate the target object. To use this function, expand the step, select
Object > Related Objects, and click the add button. Follow the directions to
create a relation. Verify that it has worked by highlighting both the object
and its related object.

6) Replacing an object
If you selected the wrong object during recording, or an object has
permanently changed you can replace it with a different object without
replacing the step. This effectively resets the step, deleting changes made to
the original step such as relations. Expand the step, select Object, and click
the Replace button. Select the new object and replay the script.

VuGen Parameterization

What is Parameterization

• Replacing hard coded values in the script is called Parameterization.
• Parameterization helps in :
• Reducing script size
• Avoiding cache effect

Type of Parameters

#1. Date/Time – Whenever we have to replace a date value with a parameter, Date/Time parameter is used. Any post with past date is not valid. To keep it updated, Date/Time parameter provides flexibility to get the current or future date. If past date is needed, it handles that too.

#2. Group Name -We can generate a parameter on the basis of group that we select on controller for the script while execution. This parameter will only work while running the script on controller.

#3. Iteration Number – This replaces the parameter with current iteration number. This is generally used to build some logic. For example- when we want some code in script to be executed alternatively. For this, we will use the iteration number to check whether it is even or odd number and for one of the condition we will execute the function.

#4. Load Generator Name – We can also generate parameter while executing the script on controller on the basis of load generator name on which that script is running. This parameter only works while running the script on controller.

#5. Vuser ID – When we run the script on controller, it assigns a unique id to each virtual user that emulate during the execution. This parameter type is used -

• To print the Vuser ID in an external file for script-debugging purpose.
• To segregate transaction volume based on Vuser ID

#6. File – Some time we want to pass the specific value in the script. In such cases, we use file and enter the values that want to use during execution. LR provides options to run the script with provided list sequentially or randomly on next iteration.

In few cases we want to use a set of values passed to the script. In such cases, we can use same file for the other parameter value as well.

#7. Random Number – As per need, Vugen also generates random value from the provided range.

#9. Unique value – In few situations, script is not allowed to pass any duplicate value. In such cases, unique parameter is used  to avoid failures due to duplicate value,.

#10. User Defined function – Such parameter calls a function whose return value replaces the parameter name.

#11. XML – XML Parameter Types are used for multiple valued data contained in an XML structure.  XML parameters are widely used with Web Service scripts and with SOA services.

RTE script functions

Below are some RTE script useful function with explanations:

TE_connect	Connects the terminal emulator to the specified host.
TE_find_text	Searches for text in a designated area of the screen.
TE_get_line_attribute	Returns information about text formatting.
TE_get_text_line	Reads text from a designated line on the screen.
TE_get_cursor_pos	Returns the current location of the cursor.
TE_set_cursor_pos	Sets the position of the cursor on the terminal screen.
TE_getvar	Returns the value of an RTE system variable.
TE_setvar	Sets the value of an RTE system variable.
TE_perror	Prints an error code to the LoadRunner output window or Business Process Monitor agent log.
TE_sperror	Translates an error code into a string.
TE_send_text	Sends a null-terminated string to a VT terminal emulator.
TE_type	Sends a formatted string to the client application.
TE_typing_style	Determines the way text is typed into the terminal emulator.
TE_unlock_keyboard	Unlocks the keyboard of a mainframe terminal
TE_wait_cursor	Waits for the cursor to appear at a specified location in the terminal window.
TE_wait_silent	Waits for the client application to be silent for a specified number of seconds.
TE_wait_sync	Waits for the system to return from X-SYSTEM or Input Inhibited mode.
TE_wait_sync_transaction	Records the time that the system remained in the most recent X SYSTEM mode.
TE_wait_text	Waits for a string to appear in a designated location.

Error No match found for the requested parameter 'ParameterName'

When replaying Web script with a correlation statement, the user receives the following error:

"No match found for the requested parameter 'ParameterName'. If the data you want to save exceeds xx bytes, use web_set_max_html_param_len to increase the parameter size."

Even though the user tries to increase the size for web_set_max_html_param_len, it does not help. What will be a good number for this parameter, and what is the maximum value?

Diagnosis:

When replaying a script with a correlated value, the replay engine will return the above error when there is no match found for the predefined boundaries on the correlation statement. The following information from the error message: If the data you want to save exceeds xx bytes, use web_set_max_html_param_len to increase the parameter size

The above is just a suggestion to try, it may not be a solution. This suggestion should be taken, only if the expected data is over xx bytes.


Solution:

Dealing with web_set_max_html_param_len

1. Find out the size of the data you are trying to retrieve. If it is over 256 bytes, increase this value. Correlation will fail if you try to retrieve a string whose length exceeds the maximum length specify by web_set_max_html_param_len.

Note:
The maximum length for web_set_max_html_param_len is maximum value of unsigned int, which is equal to 4294967295 bytes. If the data you want to save exceed this boundary, you will need to create multiple correlation statements for retrieving the entire dataset.However it is not recommended that such a big value be used and that a value closer to the maximum paramter length expected should be used.

2. If the data you want to save do not exceed the bytes specify in the function, you should focus on finding the correct boundaries or placing the correlation function on the correct place. 

Tracking Login Attempts and Logged In Users in HP BSM/BAC

We can always track the user activity in HP BSM/BAC very easily and it is very important too. Follow the below process for doing the same:

There are lots of log file in BSM root folder but below are the stuffs we are concerned here;

See \log\EJBContainer\UserActions.servlets.log.

The appender for this file is located in \conf\core\Tools\log4j\EJB\topaz.properties.

It can also be done by the JMX console as stated below;

To display a list of users currently logged in to the system:
1 Open the JMX console on this machine. For detailed instructions, see
"Using the JMX Console" in the Platform Administration guide.
2 Under the Topaz section, select service=Active Topaz Sessions.
3 Invoke the java.lang.String showActiveSessions() operation.

Load Runner 12 features

The roadmap for LoadRunner 12 was presented at HP Discover Barcelona in December last year. Since that time, I've been lucky enough to have a beta copy of LR12 for evaluation purposes. Now that the product has been released, I'm able to share some of the new features that I've found to a wider audience.


Key observations / new features are:
Cloud-based load generators. HP describes this feature as "cloud bursting". Users now have the ability to provision load generators on AWS(Amazon Web Service) cloud servers from within LoadRunner or Performance Center. As well as this, the ports used to communicate between LoadRunner components such as Load Generators, Controllers, MI Listeners are user configurable through the new "network security manager" tool. This simplifies the setup process and allows more flexibility in distributed test networks or cloud-based test environments. It is even possible to configure different ports/proxies for each Load Generator.

Licensing - 50 VUsers free

We in the user community have been asking for this for a long time. Providing fully-functional applications that allow small-scale testing allow prolonged evaluations and proof-of-concept exercises. This is great, because it allows more people e.g. developers to get hands-on experience and see the potential benefits of using LoadRunner.

This is likely to improve the adoption rate for LoadRunner and prevent the erosion of market share to low-cost / no-cost providers of performance testing software.

All protocols are included in the "community edition" license, with the exception of GUI (UFT) and COM/DCOM protocols as well as those protocols in the "template" bundle (i.e. those vUser types whose scripts are manually created (rather than record/replay) such as C# .Net, VB .Net vUsers).

VUGEN improvements:
There are a variety of improvements as you would expect. Key ones are:
The ability to review replay statistics for tests after each run.
Including details on total connections, disconnections and bytes downloaded.
The ability to edit common file types in the editor.
Support for recording in the Internet Explorer 11, Chrome v30 and Firefox v23 browsers.
The ability to create scripts from Wireshark or Fiddler files.
The ability to record HTML5 or SPDY protocols.

TruClient improvementsTruClient script converter. This basically replays your TruClient scripts and records the HTTP/HTML traffic allowing you to create these script typers from TruClient recordings. This is similar to recording GUI scripts and then converting to other script types.

The addition of support for Rendezvous points, IP spoofing, VTS2 and Shunra network virtualisation in TruClient scripts.

Linux Load Generator improvements
Building on the increased support for Linux Load Generators in 11.5x, LDAP, DNS, FTP, IMAP, ODBC, POP3, SMTP and Windows Sockets scripts can now be replayed through UNIX load generators.

CI/CD support
Better integration with Jenkins etc.

Platform support
Support for installation on Windows Server 2012.
(LoadRunner 11.x and PC 11.x only supported up to W2K8 which was a barrier to enterprise adoption).
LoadRunner components can now run in a "non-admin" user account with UAC and DEP enabled.

There are numerous other improvements which are well documented in the "About LoadRunner" section in LoadRunner help. Now that the community license is available, there's nothing stopping you from downloading it and giving it a go.

To get your own copy, navigate to www.hp.com/go/loadrunner and follow thre links to download LoadRunner.

Type of Logs in Load Runner Runtime settings

While creating and debugging the script which generated in LoadRunner always create various types of logs which appear in Virtual user generator screen. These logs are very useful when it’s come to debugging your script.

There are four types of log available in LoadRunner:
Recording Log
Generation Log
Replay Log
Co-relations Results



1. Recording Log: This log is generated when user records any script. This log mainly contains client server communication information which is nearly non-readable format. This is not very useful for us since we cannot map many things of this log with our script. This log contains all protocol communication information which used by application on which we are recording.
This Log is useful when we re-generate the script using “Regenerate Script” option of Vugen. Recording log is traces created during the recording Vugen
User cannot re-generate script if this log is not available.


2. Generation Log: The time user stop recording, recording log traces converts into readable format and create a log which is known as “Generation Log”. This log is very useful to see request and response captured by LoadRunner during recording. This log can be refer in script folder by accessing the file “CodeGenerationLog.txt “


3.Replay Log: Now this is the log which helps us a lot while modifying the script. This log generated when user replay the recorded script. In this log we can see what request has been sent to server and which kind response we have received during replay. It’s become very handy when we need to find the problem where script is getting fail during replay. We can increase/decrease the reply log contents by changing the settings in “Run time setting” by selecting standard log or extended log section.


4.Co-relations Results: This log is an interesting log as correlation is very import part of performance testing. This log represents a form of auto correlation. This compares “recording log” and “reply log” and finds dynamic values received any server. We can directly correlate the values from this log. It works like F9 function. Make sure “Data” folder exists in “Script” path.