LR Protocol Configuration

HP Performance Validation SDK
For the Windows operating system Software Version:11.50
Configuration Guide
Document Release Date: June 2012 Software Release Date: June 2012
Legal Notices
Warranty The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. The information contained herein is subject to change without notice. Restricted Rights Legend Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. Copyright Notices 1994 - 2012 Mercury Interactive (Israel) Ltd., All rights reserved Trademark Notices Java is a US trademark of Sun Microsystems, Inc. Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation. Oracle is a registered US trademark of Oracle Corporation, Redwood City, California. UNIX is a registered trademark of The Open Group.
Documentation Updates
The title page of this document contains the following identifying information: Software Version number, which indicates the software version. Document Release Date, which changes each time the document is updated. Software Release Date, which indicates the release date of this version of the software.
To check for recent updates, or to verify that you are using the most recent edition of a document, go to: http://h20230.www2.hp.com/selfsolve/manuals This site requires that you register for an HP Passport and sign-in. To register for an HP Passport ID, go to: http://h20229.www2.hp.com/passport-registration.html Or click the New users - please register link on the HP Passport login page. You will also receive updated or new editions if you subscribe to the appropriate product support service. Contact your HP sales representative for details.
Support
Visit the HP Software Support web site at: http://www.hp.com/go/hpsoftwaresupport This web site provides contact information and details about the products, services, and support that HP Software offers. HP Software online support provides customer self-solve capabilities. It provides a fast and efficient way to access interactive technical support tools needed to manage your business. As a valued support customer, you can benefit by using the support web site to: Search for knowledge documents of interest Submit and track support cases and enhancement requests Download software patches Manage support contracts Look up HP support contacts Review information about available services Enter into discussions with other software customers Research and register for software training
Most of the support areas require that you register as an HP Passport user and sign in. Many also require a support contract. To register for an HP Passport ID, go to: http://h20229.www2.hp.com/passport-registration.html To find more information about access levels, go to: http://h20230.www2.hp.com/new_access_levels.jsp
Table of Contents
Chapter 1: Configuration Reference.....................................................7 Chapter 2: Using HP Performance Validation SDK Configuration Builder9 The Protocol Information Dialog........................................................11 The Template Files Dialog ...................................................................12 The Additional Settings Dialog ...........................................................12 The API Functions Dialog....................................................................13 The Supported Platforms Dialog .........................................................16 The Run-time Settings Dialog .............................................................16 The Recording Methods Dialog...........................................................17 The Code Generation Dialog ..............................................................20 The Recording and Regeneration Dialog ............................................21 The Recording Settings Dialog ............................................................22 The Summary ......................................................................................23 Chapter 3: Configuration Files ............................................................25 The Template Folder............................................................................26 Header Files .........................................................................................27 Script Settings: The USR File................................................................28 Permitted Function Calls: The ASL File...............................................28 Runtime Environment Settings: The MDRV Data File .......................29 Step Display: The Steps Data File ........................................................30 IntelliSense: The RuntimesCpp.h File .................................................33 Highlighting: The VLX File .................................................................35 Protocol Configuration: The LRP File .................................................36 Protocol-Specific User Settings ............................................................49 Appendix A: Glossary ..........................................................................59
Table of Contents
1
Configuration Reference
This includes configuration information you can use for the setup of the protocol. This section includes the following chapters:
This chapter describes: Using HP Performance Validation SDK Configuration Builder Configuration Files
On page: 9 25
Chapter 1 Configuration Reference
2
Using HP Performance Validation SDK Configuration Builder
The HP Performance Validation SDK Configuration Builder enables setting the commonly-used fields in the configuration files without your having to edit the files directly. When the builder is first run, it creates the required configuration files. Each time the builder is run subsequent to the first run, it creates new files based on its internal memory of the settings entered at the last run and on settings entered at this run. That means that any edits in the files are lost. If you have edited the file outside the configuration builder, save a copy of the configuration files and merge the changes after running the configuration builder. For header files only, each time a file is overwritten, the last version is saved with a number appended to the file name. For example, when <ProtocolID>.h is overwritten the second time the builder is run, the previous version is saved as <Protocol ID>_1.h. You can use these backup files to restore edits to the header files using a merge tool or text editor. A file to be added to the protocol is selected in the configuration builder by entering the full path to the current location of the file. When the settings are saved, the selected files are copied from the path entered to the appropriate location in the protocol development tree. The next time a configuration tab is viewed, the file name is displayed without a path. The original file still exists, but has no further connection to the protocol under development. Changes made to the original do not affect the protocol. To view the location of the protocol files in the development tree, use the summary screen. See The Summary on page 23.
Chapter 2 Using HP Performance Validation SDK Configuration Builder
This chapter describes the tabs of the HP Performance Validation SDK Configuration Builder. For a description of the actual configuration files modified by the HP Performance Validation SDK Configuration Builder (and other configuration files as well), see Configuration Files on page 25. On the tool bar and menu bar of the HP Performance Validation SDK Configuration Builder, you can create a new project, open an existing project, save the settings entered, run tools, and get help. To open an existing project, select File -> Open. In the Location field, enter or browse to the folder that contains the protocol projectsfor example, C:\Program Files\HP\Performance Validation SDK\Protocols Root. In the Protocol Name field, enter the name of the sub-folder that contains the specific protocol to configurefor example, EchoHooking. When the protocol is ready for testing or distribution, you can prepare an installation package with the HP Performance Validation SDK Installation Builder. To run the installation builder, select Tools -> Run Installation Builder from the menu bar. For more details, see About the Installation Builder on page 191. This chapter includes:

The Protocol Information Dialog on page 11 The Template Files Dialog on page 12 The Additional Settings Dialog on page 12 The API Functions Dialog on page 13 The Supported Platforms Dialog on page 16 The Run-time Settings Dialog on page 16 The Recording Methods Dialog on page 17 The Code Generation Dialog on page 20 The Recording and Regeneration Dialog on page 21 The Recording Settings Dialog on page 22 The Summary on page 23
10
The Protocol Information Dialog

In this dialog, enter basic information about the protocol: the name for display, ID, installation path, icon file, and a description. The dialog includes the following elements (listed alphabetically):
GUI Element Description Display a browse dialog box to find a file or folder.
Description Display Name Location Protocol Icon
A free text description of what the protocol does. The protocol name to display in the user interface. The path to the protocols parent folder. The bitmap to be used with the protocol in the user interface. The bitmap is a 16x16 BMP file. On first use, the full path file name of the source file is entered. When OK is clicked to save the configuration, the file is copied to the correct location in the protocol installation tree. After the configuration is saved, only the file name is displayed.
Protocol ID
The identifier to be used in communication with LoadRunner. The ID is no more than eight characters long. The absolute path to the protocol root installation folder. Any string can be used. The recommended convention is X.Y where X is the major release and Y is the minor release (or patch number).
Protocol Location Protocol Version
11
The Template Files Dialog

In this dialog, enter the full path names of protocol-specific files that must be added to the template for scripts created using this protocol. The dialog has the following controls:
Add a file to the list. When clicked, a new line with a browse symbol (...) is added to the list. Browse to the file to add. Delete the selected file from the list.
Protocol-specific files that must be added to the template for scripts created using this protocol can also be added directly to the template folder as described under The Template Folder.
The Additional Settings Dialog

In this dialog, set the general protocol help file in the Protocol Help box, the function reference file for the protocols API functions in the Function Reference box, and the file with resources, such as graphics, in the Resource File box. The Protocol Help file name must be the same as the protocol IDfor example, if the protocol ID is myReplay, the help file is myReplay.chm.
12
The dialog has the following controls:
GUI Element
Description Display a browse dialog box to find a file or folder.
Protocol Help
On first use, the full path file name of the protocol help file. After the configuration is saved, the file name only. On first use, the full file path and name of the protocol API reference. After the configuration is saved, the file name only. On first use, the full path file name of the protocol resource file. After the configuration is saved, the file name only.
Function Reference
Resource File
The API Functions Dialog

In this dialog, define the protocols API functions and enter the full path name of the replay DLL. This DLL can also be used to specify the resources of the functions icons. The dialog includes the following elements (listed alphabetically):
Display the The API Function Form to add a new function definition. Delete the selected item.
13
GUI Element
Description Edit the selected item.
Add a new function definition by copying the selected method prototype. Prototype API Functions area Replay DLL The list of prototypes. The full path name of the DLL for Load Runner to use to invoke the protocols functions.
The API Function Form

In this dialog, enter the definition of a function that can be invoked from a script. The dialog is divided into the main dialog area and the Arguments area. The main dialog area includes the following elements (listed alphabetically):
GUI Element Description Description A help text. This text is displayed, for example, when a user holds the mouse pointer over the method in the Script View. The name for use in the user interfacefor example, in the Add New Step dialog. The name used to invoke the method. The numerical identifier of the icon for this method in the resource.h file. See Adding an Icon for an API Function on page 49. The data type of the return value. API functions return primitive value types only.
Display Name Function Name Icon ID
Return Value Type
14
The Arguments area includes the following elements (listed alphabetically):

GUI Element Description Add a new argument.
Delete the selected argument.
Add a new function by copying the selected function.
Display Name Optional Parameterize Button
The name of the argument to be displayed in dialogs and lists. Indicates whether the argument is optional. Indicates if the button that displays the Select or Create Parameter dialog is shown with the argument when adding a new step. Check this option to indicate to the user that the argument is likely to require parameterization. Note that all string input arguments can be parameterized. This feature only guides the user.
Possible Values
A semi-colon delimited list of possible values for the argument. If this field is empty, the user can enter any value. For example: YES;NO;NextVersion;TBD. The name of the argument as it is written in the step.
Script Name
15
The Supported Platforms Dialog

In this dialog, indicate which platforms are supported and whether the protocol supports running each Vuser as a separate thread. The dialog includes the following elements:
GUI Element Enable Thread per VUser Button Supported Platforms check boxes Description Indicates if the option to run each Vuser as a thread is enabled in the Run-Time Settings dialog box. This applies to all supported platforms. Indicates if the platform on the row with the checkbox is supported.
The Run-time Settings Dialog

In this dialog, enter the full path names custom settings files. Enter the paths for the XML files that define protocol-specific run-time settings dialogs for the user interface. For each XML, enter the path of the INI files that save the values set by the user on the custom tab defined by the XML. When the protocol configuration is saved, the XML and INI files are copied to the correct location in the protocol installation tree. After the configuration is saved, only the file names are displayed. For more details, see Protocol-Specific User Settings on page 49.
16

Add a file to the list. When clicked, a new line with a browse symbol (...) is added to the list. Browse to the file to add. Delete the selected file from the list.
The Recording Methods Dialog

In this dialog, configure how communication with the application being tested will be captured. Select Custom API Hooking if the protocol provides hook functions. Select Network Recording Level if the protocol generates code from events that the LoadRunner infrastructure records. If Network Recording Level is selected, select either HTTP, WEB, or socket-based recording. It is possible for a protocol to use both custom API hooking and network recording. If you select Custom API Hooking, enter the hooking configuration information in the Custom Hooking area. In the TLB File Name box, enter the file name of the type library (TLB file) containing the definitions of the events the protocol uses. For more information, see Events on page 97. In the Custom C API Hook Functions area, add pairs of matching DLLs and pairs of matching recorded functions and hook functions. Click the add button to create a new line. Select the line and click the edit button to display the The Function Mappings Form in which the data is entered.
17

Add a new argument.
Edit the selected row.
Network Recording Level Use x Recording Use Custom C API Hooking TLB File Name
Enables the controls for selection of Socket Based Recording, HTTP Based Recording, or WEB Based Recording. Select one of the recording levels. Indicates that the protocol implements hook functions. On first use, the full file path and name of the type library in which the protocol API functions are defined is entered. When OK is clicked to save the configuration, the file is copied to the correct location in the protocol installation tree. After the configuration is saved, only the file name is displayed. The list of matching DLLs. The Recorded DLL contains the source functions and the Custom Hook DII contains the protocol hook function. Mapped Functions is the number of source-hook function pairs in the two DLLs.
Custom C API Hook Functions area
18
The Function Mappings Form

In this form, match the functions of the client application being recorded with the protocol functions that hook them. In the Record DLL field, enter the client application DLL that contains the source functions to record. In the Custom Hook DLL field, enter the protocol DLL that contains the hook functions that correspond to the source functions. In the Mappings Control area, specify the pairs of recorded functions and hook functions that are implemented in the corresponding DLLs. Click the add button to add a new row. The name of a function must be entered exactly as exported by the application DLLfor example, _SendEcho@8 might be the exported name of a function named SendEcho in the code. The configuration builder enables you to select the function. If the DLL is not available from the development machine when the configuration builder is run, the exact name can be determined by examining the DLL with a tool such as Dependency Walker. For more information, see Implementing Recording on page 71.

Add a new argument.
19
GUI Element Record DLL
Description Enter the full file path and name of the application DLL that contains the source functions. After the configuration is saved, the path is stored internally by the configuration builder and only the file name is displayed. On first use, the full path file name of the protocol DLL that contains the hook functions is entered. When OK is clicked to save the configuration, the file is copied to the correct location in the protocol installation tree. After the configuration is saved, only the file name is displayed. The list of source-hook function pairs in the two DLLs. Record is the source function. Hook is the protocol function.
Hook DLL
Mappings area
The Code Generation Dialog

In this dialog, specify the filters to be used in code generation. For each filter, add the DLL file in which the filter is located and then enter the name of the filter on the same line. Use up and down arrows to set the order in which the filters are called during code generation. For more information, see Implementing Code Generation on page 85. The dialog includes the following elements:
Add a line in the Custom Filters area.
20
GUI Element
Description Delete the selected item.
Display the Filter Definition Form to enter or edit the details of the filter. Move the selected filter up in the list. The order in the list determines the order in which the filters are run. Move the selected filter down in the list. The order in the list determines the order in which the filters are run. Custom Filters area The list of filters and, for each filter, the name of the DLL containing the filter.
The Recording and Regeneration Dialog

In this dialog, enter the full path names of the XML files that define protocol-specific recording options and regeneration options dialogs for the user interface. For each XML file, enter the full path name of the INI file into which the settings from the custom tab will be written. The initial INI file provided with the protocol contains the default values. On first entry of XML and INI files, the full path file name of the source file is entered. When OK is clicked to save the configuration, the files are copied to the correct location in protocol installation tree. After the configuration is saved, only the file names are displayed. For more details, see Protocol-Specific User Settings on page 49.
21
The dialog includes the following elements:

Adds a new line to the list. Double-click the new line or click the edit button to enter the file data. Delete the selected item.
The edit button displays the Record and Regeneration Settings Files dialog. On this dialog, use the browse button to select the XML and INI files. Recording Settings area Regeneration Settings area The list of pairs of custom tab configuration XML files and the INI files in which the selected recording options are stored. The list of pairs of custom tab configuration XML files and the INI files in which the selected regeneration options are stored.
The Recording Settings Dialog

In this dialog, enter the full path names of the DLL files that contain the callback functions to run before and after recording. The names of the callback functions are PreRecordingCallback and PostRecordingCallback. For more information, see Callbacks on page 75. The dialog includes the following elements:
22
GUI Element Pre-Recording Check Post-Recording Check
Description The DLL containing the pre-recording check function. The DLL containing the post-recording check function.
The Summary
The summary displays the directory and file tree that will be created when you save the settings. This display reflects the settings entered on the other dialogs.
23
24
3
Configuration Files
This chapter includes information on the configuration files and the settings in the files. To set the commonly used configuration fields in the configuration files, you can use the HP Performance Validation SDK Configuration Builder, described in Using HP Performance Validation SDK Configuration Builder on page 9.
Note: If configuration files that are created by the HP Performance Validation SDK Configuration Builder are edited outside the configuration builder and the configuration builder is run subsequently, the edits are overwritten. If you edited a configuration file, save a copy before running the builder and merge your edits back into the files after you close the builder.
This chapter includes:

The Template Folder on page 26 Header Files on page 27 Script Settings: The USR File on page 28 Permitted Function Calls: The ASL File on page 28 Runtime Environment Settings: The MDRV Data File on page 29 Step Display: The Steps Data File on page 30 IntelliSense: The RuntimesCpp.h File on page 33 Highlighting: The VLX File on page 35
25
Chapter 3 Configuration Files

Protocol Configuration: The LRP File on page 36 Protocol-Specific User Settings on page 49
The Template Folder

The <LoadRunner installation>\template\<protocol ID> folder contains the files required by the protocol script template, such as default versions of the action files. The template folder includes the following files:

vuser_init.c Action.c vuser_end.c <protocol ID>.usr globals.h default.usp default.cfg The template folder may also include other files that are required by your protocol for each Vuser script. If your protocol includes additional template files, specify them using the HP Performance Validation SDK Configuration Builder. For more information, see The Template Files Dialog on page 12 and Script Settings: The USR File on page 28. The C files are the initial script actions files added to a new script. default.usp is the default run logic. globals.h contains the include statement for this protocols header and sometimes other declarations. The run-time settings configuration file, default.cfg, contains the default run-time settings. Most sections represent a tab on the Run-Time Settings dialog box. There is a protocol-specific section whose key is the protocol ID, for example, [MyProtocol]. It contains protocol-specific defaults for settings common to more than one protocol, and settings only used by this protocol and their defaults. All run-time settings, common or protocol-specific, used by the protocol must have default values specified in the protocol-specific section. For more information, see Run-time Settings on page 49.
26
The <Protocol ID>.usr file contains the initial configuration for a new script. For more information, see Script Settings: The USR File on page 28. When the protocol is used in a single-protocol script, the initial files are taken from this folder. When the protocol is used in a multi-protocol script, some files are taken from the multi-protocol template. For example, comments you write in the protocol default Action.c are not visible in a multi-protocol script because the action files are taken from the multiprotocol template. Configuration files, like the USR and CFG files, are merged so that the first time a key is encountered in any file of the same extension (USR or CFG), its value is used. Subsequent occurrences of the key are ignored. Therefore, you cannot rely on the default settings for the protocol being used in a multiprotocol script. In default.cfg, this problem is overcome with respect to the protocol, and mitigated with respect to related protocols, by entering default values in a section named with the protocol ID. For example:
[myReplay] SampleRTSArgument=5
For a more detailed example, see Example of default.cfg on page 51.
Header Files
The principal protocol header file is <LoadRunner installation>\include\<protocol ID>.h. This file has #include directives for other headers required for the protocol steps. There is also a <LoadRunner installation>\template\<protocol ID>\globals.h file, which has an #include directive for the <protocol ID>.h file and the lrun.h file. The lrun.h file declares the VuGen infrastructure functions, like the lr_start_transaction. For multi-protocol scripts, the globals.h files of all the protocols are merged to a single globals.h file. Since this process does not preserve all #include directives, the list of included files is also entered in the ExtIncludeFiles parameter of the MDRV data file (See Runtime Environment Settings: The MDRV Data File on page 29.)
27
Script Settings: The USR File

The file <LoadRunner installation>\template\<protocol id>\<protocol ID>.usr defines the settings of a protocol script. The [ExtraFiles] section contains the list of template files to be displayed in VuGen in addition to the default files: action, vuser_init, and vuser_end. If there is no need to show any extra files in VuGen for this protocol, the section can be empty or missing. Files that appear in this section must have a default instance in the <LoadRunner installation>\template\<protocol id> template folder.
Example of an ExtraFiles Section

[ExtraFiles] user.h= interfaces.h= recordsets.inf= globals.h=
Permitted Function Calls: The ASL File

The <LoadRunner installation>\merc_asl\< protocol id>.asl file lists the API functions of the protocol. This is a security measure to ensure that the extension makes only those invocations intended by the protocol developer. For example:
[Allowed_Functions] lr_start_transaction= lr_start_sub_transaction= lr_start_transaction_instance= lr_stop_transaction= lr_stop_transaction_instance= lr_resume_transaction=
The settings in the ASL file can be disabled without altering the file. It is recommended that this be done only during development. See SecurityMode on page 29.
28
Runtime Environment Settings: The MDRV Data File

File <LoadRunner installation>\dat\mdrv\mdrv_<protocol id>.dat is the configuration file of the mdrv process. The following are commonly used settings:
Parameter ExtIncludeFiles ExtPriorityType LibCfgFunc Description A comma-delimited list of additional include files. For extensions created with this SDK, this parameter is always protocol. The configuration function name. After loading the extension library, the driver calls this registration function. The extension gets the addresses of the driver services and mdrv gets the addresses of the management API functions. When SecurityMode is ON, only functions listed in the ASL file are allowed. (Default = On) The name of the ASL file. A comma-delimited list of other extensions to load when using this extension. If the protocol is not based on another protocol, only lrun_api need be specified. (Default = lrun_api) The name of the DLL for the specified platform.
SecurityMode SecurityRequirementsFiles UtilityExt
WINNT_EXT_LIBS SOLARIS_EXT_LIBS and so on
Example of MDRV.dat File:

[myReplay] ExtPriorityType=protocol WINNT_EXT_LIBS=SDKProtocol.dll LibCfgFunc=RegisterProtocol UtilityExt=lrun_api ExtIncludeFiles=globals.h SecurityRequirementsFiles=myReplay.asl SecurityMode=On
29
Step Display: The Steps Data File

The <LoadRunner installation>\dat\<protocol name>_steps.dat file configures presentation of steps in the Insert Step dialog and elsewhere in the VuGen user interface. This file contains a [GROUP] section that specifies in which group to display the steps in the Add Step dialog box. For protocols created with the HP Performance Validation SDK, the GROUP_NAME parameter value always includes the name of the protocol, so that each SDK protocol is its own group. The file also contains a section for each API step. This section describes the display of that API. The file may also have a [General] section, if required. This file is maintained with the HP Performance Validation SDK Configuration Builder. See The API Functions Dialog on page 13. The following are commonly used parameters. AutoAddPrefix is in the [General] section. All other parameters are specified for each API step.
Parameter AutoAddPrefix Description Indicates whether the key name of a named argument is displayed in add and edit step dialogs.
1=key displayed, 0=not displayed.
For protocols created with the HP Performance Validation SDK, it is strongly recommended that the value be 1. CAPTION CLASSNAME For display. A string of format Stepn_class in the range Step1_class, Step2_class, ..., Step13_class. n is the number of items in the parameter list of the function signature. Indicates whether the symbol for a variable-length argument list (...) is displayed in dialogs. 1=displayed, 0=not displayed.
HAS_ELLIPSIS
30
Parameter HIDE_PARAM_BUT TON_A ( _B, _C, ..., M)
Description Indicates whether to display or hide the Insert Parameter button for an argument in the insert and edit step dialogs. The argument position is indicated with letters A to M, indicating arguments from the first (A) to the thirteenth (M). There is no need to enter more parameter items than there are arguments.
A value of 1 indicates that the button is displayed, not
that it is hidden.
A value of 0 indicates that the button is not displayed.
Note: String positional arguments and all the values of named arguments in protocols created using the HP Performance Validation SDK can be parameterized. Therefore, this parameter only effects the display. Set the value to 1 to encourage the end user to consider using a parameter for this argument. ICONID RETVAL_TYPE PARAM_TYPE_A ( _B, _C, ..., M) The identifier of the icon for this method in the resource file. The icon is a 16x16 bitmap (BMP file). The return type, one of: void, char, int, long, or LPCSTR. The type of data expected in argument n, from A to M, indicating arguments from the first (A) to the thirteenth (M). It is not necessary to enter more PARAM-TYPEs than there are arguments. Possible values are T_CHAR, T_GENERAL, T_INT, T_PASSWORD, T_STR, and T_XML. In the case of named arguments, PARAM_TYPE indicates to LoadRunner how to interpret the string argumentfor example, for a named argument "CustomerAge=30", the PARAM_TYPE is T_INT.
31
Parameter TEXT_DLG_PARAM _A ( _B, _C, ..., M)
Description Short descriptions of argument n, from 1 (A) to 13 (M). There is no need to enter more text parameter items than there are arguments. The following characters can also be specified:
;
This is a combo field. Valid values are the strings that follow the ; .
*
Optional.
^
A snapshot.
$
Indiation that the step has a LAST argument.

&
Read-only. VISIBALESTEPNAM E The name used to invoke the function, generally the same as the function declaration.
32
Example of *_steps.dat File

[GROUP] GROUP_NAME=PQ_Server [General] AutoAddPrefix=1 [pq_get_request_que] VISIBALESTEPNAME=pq_get_request_que CLASSNAME=Step2_class ICONID= ISGROUP=1 LEVEL=ROOT_NO_CHILD CAPTION=Get request que name INSDLGCAPTION=Get request que name from %1% HAS_ELLIPSIS=0 TEXT_DLG_PARAM_A=Step Name:$ PARAM_TYPE_A=T_STR HIDE_PARAM_BUTTON_A=0 TEXT_DLG_PARAM_B=ServerName:$ PARAM_TYPE_B=T_STR HIDE_PARAM_BUTTON_B=0
IntelliSense: The RuntimesCpp.h File

The <LoadRunner installation>\bin\vslick\builtins\<Protocol ID>RuntimesCpp.h file contains the formats of the API functions as they are displayed by IntelliSense, with a few comment lines for each function. The file configures the display of each function as a tooltip in VuGen. Named arguments are best described as they appear in the script, that is, "KeyName=<value>". For positional arguments, state the data type, as in the function declaration. (See positional argument and named argument in the glossary.) Optional arguments are enclosed in square brackets. Additional notations can be used at your discretion. Sometimes additional information in a tooltip is useful, but too much can make it difficult to understand. It may be preferable to have a simple tooltip and let the user read the protocol function reference for more details.
33
Additional notations include the following:
Choices of argument values from a list can be indicated with a bit-wise OR marker, for example, "ClearBuffer=Yes|No". Passing exactly one argument from a list can also be indicated with a bitwise OR marker, for example, "UserName="|"UserID=". Passing at least one argument from a list can be indicated with a logical OR marker between optional arguments, for example, ["LDAPUser="] || ["LocalUser="]. Where one argument is required only if another is specified, they are enclosed together in optional argument brackets, for example ["OpenComment=<value>", "CloseComment=<value>"]. As noted, additional notation options should be used sparingly, with careful consideration of whether the additional information justifies the lessreadable format. For named arguments where no additional notations are used, this file is most simply maintained with the HP Performance Validation SDK Configuration Builder. See The API Functions Dialog on page 13. For positional arguments, the file must be maintained with a text editor. If this file is edited outside the HP Performance Validation SDK Configuration Builder and the configuration builder is run subsequently, the edits are overwritten. To preserve changes made in any way other than with the configuration builder, make a copy before running the configuration builder. After the run, merge the changes you wish to preserve back to the file.
Example of *Cpp.h Entry

// The qtp_define_comment_chars function defines a string to // start a line comment, and strings for open and close comments // for use on multiple lines. // At least one must be specified: either the line comment marker // or the open-close marker pair. Both single- and multi-line markers // may be specified int qtp_define_comment_chars (const char * StepName, ["SingleLineComment=<marker>"] || [, "MultiLineStartComment=<mark>", MultlLIneEndComment=<mark>",] LAST);
34
Highlighting: The VLX File

The <LoadRunner installation>\bin\vslick\<Protocol ID>.vlx file contains the API function names and keywords. It is used for highlighting in VuGen. If this file is edited outside the HP Performance Validation SDK Configuration Builder and the configuration builder is run subsequently, the edits are overwritten. To preserve changes made in any way other than with the configuration builder, make a copy before running the configuration builder. After the run, merge the changes you wish to preserve back to the file.
Important: With the exception of userkeywords, the parameters in this file must be consistent with the programming languages used by the protocol.
The following are commonly used settings:

Parameter userkeywords Description A space-delimited list of words reserved by the protocol to be highlighted in steps using a function of this protocol. All the protocol step functions must be listed. There can be more than one userkeywords line.
Example of a Section of the VLX File

userkeywords=my_function1 my_function2 userkeywords=MY_CONSTANT1 MY_CONSTANT2 userkeywords=mldap_logon mldap_search userkeywords=LRMMS_STREAM_1_TYPE LRMMS_STREAM_2_TYPE
35
Protocol Configuration: The LRP File

The file <LoadRunner installation>\dat\protocols\<protocol id>.lrp is the master configuration file for the protocol. If this file is edited outside the HP Performance Validation SDK Configuration Builder and the configuration builder is run subsequently, the edits are overwritten. To preserve changes made in any way other than with the configuration builder, make a copy before running the configuration builder. After the run, merge the changes you wish to preserve back to the file. In addition, there is an sdkbase.lrp file that contains common settings for all protocols created with the HP Performance Validation SDK.
Important: Do not edit sdkbase.lrp. To apply values different from those specified in sdkbase.lrp, override the value in the protocol LRP file.
The LRP file includes the following sections:

The Protocol Section, described on page 37 The Replay Section, described on page 37 The Replay Section, described on page 37 The Vugen Section, described on page 40 The API Section, described on page 44 The Filters Sections, described on page 44 Miscellaneous Sections, described on page 44
36
The Protocol Section

Setting Name Category Description The general category of the protocol, for example, EBusiness or ERP/CRM. For a full, current list of existing categories, open the New Virtual User dialog in Vugen and open the Category list. The display name may have spaces and punctuation. The protocol ID of the protocol on which this protocol is based. All settings are taken from the LRP of this base protocol. However, if a setting in the LRP of the base protocol is also specified in the LRP of this protocol, these settings override those of the base protocol. A free text description of the protocol. This protocol cannot be used in a multi-protocol script with protocols from the groups specified with these codes. Do not edit this value. Enables (1) or disables (0) display of the check box in VuGen that allows the user to configure handling each step as a transaction. Do not enable this check box unless the protocol implements this feature. Indicates whether not to list (1) or to list (0) the protocol in the New Protocol Script dialog. The icon of the protocol for the New Protocol Script dialog. The icon is a 16x16 bitmap (BMP file). Use the relative path starting from the dat folder. For example, for file <LoadRunner installation>\dat\bitmaps\myicon.bmp, enter Icon=bitmaps\myicon.bmp The maximum number of threads per process. The default is 50. May be reduced to solve problems of performance on the client running on the load generator.
CommonName DerivedFrom
Description DontSupportGroup
EnableAutoTranPerFu nc
Hidden Icon
MaxThreadPerProcess
37
Setting Name Multi Name PostSaveNotify
Description Indicates whether to enable (1) or disable (0) the protocol as a multi-protocol Vuser type. The protocol name. Use the same string entered for the ProtocolID parameter. The callback function for notification on a save operation. After a save operation, the specified function in the specified DLL is invoked. The format is PostSaveNotify=<function_name>:<dll_name>. For example: PostSaveNotify=PostSaveNotify:DotNetRecordUtils.dll
PostRecordingNotify
The function name and DLL of the callback to be invoked when a recording session is completed. The function name is required to be PostRecordingCallback, but the DLL is specific to the protocol. For example: PostRecordingNotify=PostRecordingCallback:SDKProtoc ol.dll
ProtocolId
A string of up to eight characters that follows the rules for C language variable names. It is used internally by VuGen to identify the protocol. The function name and DLL of the callback to be invoked before starting a recording session. The function name is required to be PreRecordingCallback, but the DLL is specific to the protocol. For example: PreRecordingCheck=PreRecordingCallback:SDKProtoco l.dll
PreRecordingCheck
ResultsDirUI
Enables (1) or disables (0) the Prompt for results directory check box in the Tools->Options dialog. Set to 1 if the Test Results Report is implemented and used.
38
Setting Name RTS_DynamicTreeBm pDir_1 RTS_DynamicTreeBm pDir_2 RTS_DynamicTreeBm pDir_n RunTimeExtraDir
Description The folder containing resources for use on dynamic tree tabs, relative to the <LoadRunner installation>\dat directory. Always use folder bitmaps. For example: RTS_DynamicTreeBmpDir_1=bitmaps
A comma-delimited list of directories in the script directory tree to copy to the load generators. All the directories files and sub-directories are copied. For example: RunTimeExtraDir=solution,data\SerializedObjects
RunTimeExtraFileExt
Defines which file types are copied from the controller to the load generators to run the script. For example: RunTimeExtraFileExt=*.pem,*.der,*.xml,*.config
SDKVersion Single Version VISUAL_LOG
The version of the HP Performance Validation SDK on which this version of the protocol was developed. Indicates whether to enable (1) or disable (0) the protocol as a single Vuser type. The version of this protocol. Set to 1 if the Test Results Report is implemented and used. For protocols created with the SDK, set this value to 1. The names of the test run processes for the platforms supported by the protocol. The process is mmdrv.exe for all Windows platforms and mrdv.exe for all UNIX platforms.
WINNT WIN2000 WINXP WIN95 SUNOS SOLARIS HPUX AIX
39
The Vugen Section

Name Description Config uration Topic Code generat ions options
REG_DynamicTreeInitXml File_n (REG_DynamicTreeInitXm lFile_1 REG_DynamicTreeInitXml File_2 ... REG_DynamicTreeInitXml File_n) See also, REG_DynamicTreeOutIni File_n on page 175. REG_DynamicTreeOutIniF ile_n (REG_DynamicTreeOutIni File_1 REG_DynamicTreeOutIniF ile_2 ... REG_DynamicTreeOutIniF ile_n) See also, REG_DynamicTreeInitX mlFile_n on page 175.
Specifies the XML presentation configuration file for a dynamic tree tab. The user enters configuration data in the tab for use in generating a script using this protocol. The first tab is File_1, the second tab is File_2 and so on. See Protocol-Specific User Settings on page 49 For example: REG_DynamicTreeInitXmlFile_1=file1_reg. xml REG_DynamicTreeInitXmlFile_2=file2_reg. xml The files in which the values specified in the corresponding code regeneration options tab are saved. For example, if there is a custom tab defined: REG_DynamicTreeInitXmlFile_1=my_reg.x ml The data from the tab is saved in: REG_DynamicTreeOutIniFile_1=my_user_ reg_cfg.ini The developer writes the initial values in these files and the configuration builder overwrites the initial values with the users selections. The default values in the REG_DynamicTreeInitXmlFile file are for display only. The values at record time are taken from this file.
Code generat ions options
40
Name
Description
Config uration Topic Recordi ng options
RO_DynamicTreeInitXmlF ile_n (RO_DynamicTreeInitXml File_1 RO_DynamicTreeInitXmlF ile_2 ... RO_DynamicTreeInitXmlF ile_n) See also, RO_DynamicTreeOutIniF ile_n on page 174. RO_DynamicTreeOutIniFil e_n (RO_DynamicTreeOutIniFi le_1 RO_DynamicTreeOutIniFil e_2 ... RO_DynamicTreeOutIniFil e_n) See also, RO_DynamicTreeInitXml File_n on page 176.
Specifies the XML presentation configuration file for a dynamic tree tab. The user enters recording options in the tab for use in recording a session that uses this protocol. The first tab is File_1, the second tab is File_2 and so on. See Protocol-Specific User Settings on page 49 For example: RO_DynamicTreeInitXmlFile_1=my_reg_cf g.xml RO_DynamicTreeInitXmlFile_2.xml=my_ot her_reg_cfg.xml The files in which the values specified in the corresponding recording options tab are saved. For example, if there is a custom tab defined: RO_DynamicTreeInitXmlFile_1=my_ro.xml, The data from the tab is saved in: RO_DynamicTreeOutIniFile_1=my_user_ro _cfg.ini The developer writes the initial values in these files and the configuration builder overwrites the initial values with the users selections. The default values in the RO_DynamicTreeInitXmlFile file are for display only. The values at record time are taken from this file.
Recordi ng options
41
Name
Description
Config uration Topic Runtime settings
RTS_DynamicTreeInitXml File_n (RTS_DynamicTreeInitXml File_1 RTS_DynamicTreeInitXml File_2 RTS_DynamicTreeInitXml File_n) See also, RO_DynamicTreeOutIniF ile_n on page 174 AllowScriptEdit
Specifies the XML presentation configuration file for a dynamic tree tab. The user enters configuration data in the tab for use in running a test that uses this protocol. The first tab is File_1, the second tab is File_2 and so on. See Protocol-Specific User Settings on page 49 For example: RTS_DynamicTreeInitXmlFile_1=citrix_rts. xml RTS_DynamicTreeInitXmlFile_2=citrix_rts_ 2.xml Enable (1) editing of the script. (Default = 1)
General
EnableThreads
Enables (1) or disables (0) the "Run Vuser as a thread" check box in the Run Time Settings dialog. Comma-delimited list of the languages supported for this protocol. For protocols created with the HP Performance Validation SDK, only C is supported. For example: LangSupported=C (Default = C)
General
LangSupported
General
Mulit_OutputTabName# Mulit_OutputTabFile# Mulit_OutputTabIcon# Mulit_OutputID#
When defining multiple tabs for a file in the Output window, set values for the tab name, file, tab icon and tab ID settings. For example:
; Multi Code Generation Log Mulit_OutputTabName1="Generation Log" Mulit_OutputTabFile1=data\CodeGenerationLog.txt Mulit_OutputTabIcon1="5" Mulit_OutputID1="33088"
General
42
Name
Description
Config uration Topic General
OutputTabFile#
The path and name of the file whose contents are displayed in the corresponding tab in the Output window. # is the index number for the tab. For example, to display the Generation Log in the first tab of the output window: OutputTabFile1=data\CodeGenerationLog.t xt
OutputTabName#
The name for a tab in the Output window, where # is the index number for the tab. For example, to create a tab for the Generation Log: OutputTabName1=Generation Log
General
Platform executables
The names of the run-time environment executable files for supported platforms. For example: AIX=mdrv HPUX=mdrv LINUX=mdrv SOLARIS=mdrv WIN2000=mmdrv.exe WINNT=mmdrv.exe WINXP=mmdrv.exe
General
RecordingLogFile
The name of the log file for recording. The default is RecordingLog.txt. For example: RecordingLogFile=data\RecordingLog.txt
General
43
Name
Description
Config uration Topic General
SupportMultipleAction
Allow (1) multiple actions in a script. (Default = 1)
TemplateDir
The name of template directory. It must be identical to the protocol ID. For example: TemplateDir=Oracle_NCA
General
The API Section

For every API function, a line describes the highlighting colorsfor example: <API function name>= lr_cmd_color;<interface of API function> If required, there may also be lines that define the highlighting of constants. There is also an extra_section value. It is a comma-delimited list of functions that can be used in a script of this type.
Example of API Section

[API] extra_section=lr_general,c_general,lr_xml,QTWeb amf_call=lr_cmd_color;int amf_call(const char *StepName[, argument]...) amf_define_header_set=lr_cmd_color;int amf_define_header_set(const char *ID[, argument]...) amf_define_envelope_header_set=lr_cmd_color;amf_define_envelope_header_set(co nst char *ID[, argument]...) amf_set_version=lr_cmd_color;int amf_set_version(const char *AmfVersion) LAST=c_cmd_color
The Filters Sections

The filters a protocol requires in addition to the default filters are configured in the [CustomFilters] section and in each individual [<filter>] section.
44
The Custom Filter Section

The CustomFilters section contains the names of the filters implemented by the protocol for code generation. The filters appear in the order in which they are invoked. In addition to the filters created by the protocol, there are divider filters that represent the action of writing the output filters from the previous filter to a repository. Theses filters are inserted automatically by the HP Performance Validation SDK Configuration Builder. Do not edit or delete them or change the order. For example: [CustomFilters] Filters=*CUSTOM_SECTION_DIVIDER_1,myFilter1,*CUSTOM_SECTION_DIV IDER_2,myFilter2 For more information about filters, see Handling All Types of Events on page 87.
The Filter Sections

Each filter declared in the CustomFilters section must be configured in a section having the name of the filter. For example, if there is a declaration: [CustomFilters] Filters=myFilter1,myFilter2 then there must be filter configuration sections [myFilter1] and [myFilter2] .
45
These are the values in the filter configuration sections:

Config uration Topic Code Genera tion Code Genera tion Code Genera tion
Name
Description
name
The name of the filter. The name must be unique in the protocol. The DLL that contains the implementation of the filter. This DLL must be located in the <LoadRunner>\bin directory The initialization function name. LoadRunner calls this function once before passing any recorded event to the filter. The default name of the init_func is <filter_name>_init_func.
dll
init_func
cleanup_func
The last method called when the filter is finished. A comma-separated list of protocol IDs. Events marked with these IDs are sent to the filter. It is strongly recommended that filters for new protocols handle only the events belonging to their protocol. If no protocol ID is specified, the filter is called for all protocols. System events have a protocol ID of zero (0). They are sent to all filters.
Code Genera tion Code Genera tion
protocols
after
The ID of a filter after which this filter is inserted in the filtering chain. Either "before" or "after" must be used, but not both. For possible values, see Before and After Values on page 47.
Code Genera tion
46
Name
Description
Config uration Topic Code Genera tion
cleanup_func
The clean up function name. LoadRunner calls this function once after all events have been processed. The filter sends any remaining events as required by the protocol logic, and releases any allocated memory. The default name of the cleanup_func is <filter_name>_cleanup_func.
before
The ID of a filter before which this filter is inserted in the filtering chain. Either "before" or "after" must be used, but not both. For possible values, see Before and After Values on page 47.
Code Genera tion
For more information about events, see Events on page 97.
Before and After Values

The values of the before and after parameters can be dividers, markers, or filters. For example, these are valid values: *SECTION_DIVIDER_2 _END_SECTION_4 CleanDependentEvents ThinkTime
Miscellaneous Sections
The CustomTlbs Section
This section contains the TLBs key. The key is the list of type libraries that contain record-time events definitions for the protocol. Several TLBs can be registered on the same line using a comma or semicolon as a delimiter. For example:
47
[CustomTlbs] TLBs=LoadRunnerMyProto.tlb, LoadRunnerMyProtoExtra.tlb For more information, see Declaring Event Types on page 98
The Custom Recorder Section

The [CustomFunctions] section contains a mapping of client application functions and their modules to the protocol hook functions that will handle recording calls to those functions. Each line contains the name of a function belonging to the application to be recorded (the hooked function), the DLL in which that function is implemented, the protocol hook function (the function to be called when the application function is invoked) and the protocol DLL in which the hook function is implemented. For example: [CustomFunctions] Function1:MyApplication.dll=Hook_Function1:Hook_MyProtocol.dll Function2:MyApplication.dll=Hook_Function1:Hook_MyProtocol.dll Function3:My2ndApplication.dll=Hook2nd_Function1:Hook_MyProtocol2nd.dll Function4:My2ndApplication.dll=1Hook2nd_Function2:Hook_MyProtocol2nd.dll For more information about Custom API Recording, see Implementing Recording on page 71.
48
Protocol-Specific User Settings

Many protocols require configuration settings that are not common to all protocols. The settings may be for run-time, recording, or code generation for example, the Citrix protocol requires a typing rate, the Java Messenger Service requires the JDK home directory, and so on. To get protocol-specific settings from the user, add a tab with controls for entering the required settings to the Run-Time Settings, Recording Options, or Regeneration Options dialog box. To add a dynamic tree custom tab to a settings dialog box, create a tab definition XML file that defines the settings to be entered on the tab. Use the HP Performance Validation SDK Configuration Builder to add it to the protocol configuration. See The Template Files Dialog on page 12. The configuration builder sets the value of one of the RTS_DynamicTreeInitXmlFile_n items in the LRP file to the filename of the tab definition XML. The root element defines the tab as a unit. All other elements in the tab definition file define either a control in which the user will set a configuration value or a static display element. The STATIC element can be a container for other controls, which appear as sub-nodes of the STATIC element on the dialog box. STATIC elements can contain other STATIC elements. This nesting can be used to create a hierarchy. CHECKBOX and RADIO elements can also contain other elements. The SubTreeStatus attribute enables or disables the contained elements. Each type of element has a set of valid attributes. For configuration controls, the Key attribute is the string by which the setting is identified in the protocol code. With the exception of the root element, each element type can be used as many times as required. The default values in tab configuration files are not used at run-time, recordtime, or at code regeneration. They only provide guidance to the user. The data used is in the output INI file that corresponds to the tag.
49
The name of the output INI file is entered in the configuration builder with the name of the custom tab files. The protocol developer creates the INI fines and populates them with the initial values. Each time the configuration is set by the user in VuGen, the output INI file is overwritten with the values the user selects. The following are some of the attributes that are common to many elements:
Common Attribute Label Section Description The text to display next to the control. The section of the default.cfg file into which to write the item. For protocol-specific settings, ensure the section is uniquefor example, <Protocol_ID>_<Section name>. The item key in the CFG file, and the name by which the item is identified in code. The help ID of the page in the protocol general documentation CHM file that describes this element. The value of this attribute is the ID of the CHM page minus 131,072 (Ox20000). For example, if the ID of the page in the CHM is 131,073, then the HelpID attribute of the element in the tab definition XML file is 1. The ID of the CHM page may not be less than 131,072. The HelpId attribute is most commonly used in the root element. Hint1 Hint2 Default The Default is optional. The title for context-sensitive help. The context-sensitive help text. The control is initialized to display this selection.
Key HelpId
50
Common Attribute SubTreeStatus
Description Enable or disable child elements of CheckBox and Radio elements that contain other elements. Possible values are: Uncheckall. When the user clears (unchecks) the parent, the child elements are automatically cleared. Disableall. When the user clears the parent, the child elements are disabled without changing the value. For example, a child element that was checked when the parent was cleared, remains checked and cannot be cleared. Checkall. When the user selects the parent, the child elements are automatically checked.
Val%d
The list of strings for a string selection control (val1, val2, ..., valn). For example. Label="Window Size" default="800 x 600" val1="640 x 480" val2="800 x 600" val3="1024 x 768" val4="1280 x 1024" val5="1600 x 1200"
51
You can enter the following elements in a tab configuration file:

Element Root_Element Description The Root_Element describes the dialog template. Valid Attributes Title: The title of the dialog. Header: The header of the dialog. HelpId: See the table of common attributes above for details. SubjectName: The name of the parent node for Run-time Settings and Recording Options tabs. Do not use SubjectName for Regeneration Options. Label, Hint1, Hint2: Icon: Name of BMP file containing a 16x16 icon The file is in the optional bmp directory. Label, Section, Key, Hint1, Hint2, SubTreeStatus Default: Use "default=1" to check the item (Optional).
STATIC
Static text. Usually used to start a new subject with a hierarchical list of element.
CHECKBOX
Turns an option on or off.
52
Element COMBOBOX
Description A list of strings of which one can be selected. The user cannot enter values that are not in the list.
Valid Attributes Label, Section, Key, Hint1, Hint2 Val%d: The list of strings: val1, val2,...,valn. Default: If the default is one of the values, that value is selected when the control is first displayed. If Default is not specified, the first list element is selected. If the default is a string that is not in the list, the string is displayed when the tab is initialized but it is not selectable. Below is an example of a default that serves as a prompt, but is not selectable: <Choose a frequency> Label, Section, Key, Hint1, Hint2 Val%d: The list of strings: val1, val2,...,valn. Default: If the default is one of the values, that value is selected when the control is first displayed. If Default is not specified, the first list element is selected. If the default is a string that is not in the list, the string is displayed when the tab is initialized but it is not selectable. Below is an example of a default that serves as a prompt, but is not selectable: <Choose a frequency> Label, Section, Key, Hint1, Hint2, Default (Optional).
COMBOBOX_ EDIT
A list of strings. The user can either select from the list or enter a value not in the list.
EDIT_TEXT
A control in which the user enters free text.
53
Element EDIT_PASS
Description A password control in which the user enters free text. The value is encrypted when saved. Use the decryption functions to use the data in the protocol. Add an edit control that accepts only integers.
Valid Attributes Label, Section, Key, Hint1, Hint2, Default (Optional).
EDIT_NUM_IN T
Label, Section, Key, Hint1, Hint2, MinVal, MaxVal: Default: Numeric text (Optional). Label, Section, Key, MinVal, MaxVal, Hint1, Hint2 Default: Numeric text (Optional). Label, Hint1, Hint2, SubTreeStatus (Optional) Section: Use the same value for all Radio elements in a set. Key: Use the same value for all Radio elements in a set. KeyVal: The value of the Key if this button is checked. It must be unique for each Radio element with the same Key. Default: One element in the set must be set with Default="1".
EDIT_NUM_FL OAT
Add a edit control that accepts only numbers. The number can include a decimal point. A control that is set or cleared by clicking on it. A set of radio buttons is defined by using the same Section and Key attributes for each of the controls. When a radio button is selected, all others in the set are cleared automatically. A radio button element can contain other elements and can enable and disable them using the SubTreeStatus. Therefore, a set of radio buttons can be used to enable one group of several groups of options.
RADIO
FOLDER_DLG
A control used to select a folder. It is an edit control with a browse button.
Label, Section, Key, Hint1 Default: Either a message to the user or a default folder. (Optional).
54
Element FILE_DLG
Description A control used to select a file. It is an edit control with a browse button.
Valid Attributes Label, Section, Key, Hint1, Hint2 FileFilter: A filter for file extensions. For example: Setup files (*.exe)|*.exe|All Files (*.*)|*.*|| Default: Either a message to the user or a default folder. (Optional). Label, Section, Key, Hint1, Hint2, SecFormat: Set to 1 to convert a date from dd/mm/yy to the number of seconds since Jan. 1, 1970 UTC. The conversion is performed when the value is saved. (Optional) Default: If no Default is specified, the default value is 0 (zero), indicating today.
DATE_DLG
A control used to select a date. It is an edit control with a date-helper button. The field accepts either a string of format dd/mm/yy or the delta from today (integer)for example, 0 is today, 7 is a week from today, and so on.
55
Example of Tab Definition XML

<Root_Element Title="Configuration" Header="Client Configuration" SubjectName="Citrix" HelpId="20532"> <STATIC Label="General" Icon="default.bmp" Hint1="General" Hint2="General Citrix client configuration setting"> <COMBOBOX Section="Citrix" Key="Latency" Icon="10" Label="SpeedScreen Latency Reduction" default="Use Server Default" val1="Use Server Default" val2="Off" val3="On" val4="Auto" Hint1="SpeedScreen Latency Reduction" Hint2="Mechanism used to enhance user interaction when network speed is slow. For unknown network speed, set the option to 'auto' which turns it on or off based on the current network speed."/> <CHECKBOX Section="Citrix" Key="Compression" KeyVal="1" Label="Use data compression" default="1" Hint1="Use data compression" Hint2="Compresses the transferred data. Enable when working with limited-bandwidth. "/> <CHECKBOX Section="Citrix" Key="Cache" KeyVal="1" Label="Use disk cache for bitmaps" Hint1="Use disk cache for bitmaps" Hint2="Use a local cache to store bitmaps. Enable when working with limited-bandwidth."/> <CHECKBOX Section="Citrix" Key="Queue" KeyVal="1" Label="Queue mouse movements and keystrokes" Hint1="Queue mouse movements and keystrokes" Hint2="Create a queue of mouse movements and keystrokes, sending them as server packets at less frequent intervals. Enable when working with slow connections."/> <COMBOBOX Section="Citrix" Key="Sound" Icon="10" Label="Sound quality" default="Use Server Default" val1="Use Server Default" val2="Sound off" val3="High sound quality" val4="Medium sound quality" val5="Low sound quality" Hint1="Sound quality" Hint2="Select the sound quality. If your client does not have a Sound Blaster 16 compatible sound card installed, select 'Sound off' to disable sound support. With sound support enabled, Published applications will be able to play sounds on your client."/> </STATIC> </Root_Element>
56
Example of a default.cfg section

When the user accepts the values on the custom tab, the settings are written to the default.cfg file. For more details, see The Template Folder on page 26. This section of default.cfg is the result of a user accepting the defaults on the custom tab defined in the preceding example.
[CITRIX] Latency=Use Server Default Compression=1 Cache=0 Queue=0 Sound=Use Server Default
57
58
A
Glossary
Term Definition
argument
(See also: positional argument, named argument, parameter)
A value passed to a function or an item in a function parameter list. The term argument is preferred to the term parameter in most HP Software documentation for both formal parameters and actual parameters. This convention avoids confusion where the product makes special use of the term parameter. 1. A function implemented by a protocol to be used in test steps. 2. A function exposed by the application. As used in this guide, the application is the item on which you perform load testing. It can be a single server-based application, a set of applications having a common invocation point, or any other item that uses a communications network to reply to requests, up to an entire server farm. During a test run, the application receives requests from, and responds to, a load generator that is emulating users of the applications client.
API function
application
application to be tested client application
Another term for application. The Windows application that exercises the server application. Recording with API hooking traps communication between the client and the application being tested.
59
Appendix A Glossary
Term
Definition
code generation
The iterative process of abstracting higher level information from lower level information, and results in a test script. Code generation starts with recorded events and ends with events that correspond to an output to the script or log. The events are then written to the output. See also: filter. Code generation starts automatically at the end of a recording session. See also, regeneration.
event
A data structure that stores information to be used in code generation. Events may represent activities of the client application and server, comments, log entries, C code, and others. Events are either recorded or are a product of a filter. A software component that processes events by combining or abstracting data from input events and outputting new, higher-level events. Filters are used in code generation. A function implemented by the protocol that is invoked in place of the applications recorded function during a recording session. The client side of the test run. The load generators run the test by sending requests to the application as required by the test script and processing the responses. The LoadRunner run-time test execution component.
filter
hook function
load generator
mdrv
60
Appendix A Glossary
Term
Definition
named argument
(See also: positional argument, argument)
Named function parameters are implemented in VuGen as a string containing a key-value pair. For example, in this call, all arguments except the first (the step name) and the LAST marker are named arguments: web_url("Open xyz home page.", "URL=http://www.xyz.com/", "TargetBrowser=HP Technologies", "RecContentType=text/html", "Mode=HTML", LAST); The prototype for this function is: int web_url(const char * mpszStepName, ...);
parameter
A variable in a script that is managed by LoadRunner. A parameter is not declared in the script as, for example, a C language variable is declared. Parameters are sometimes created at design time. In general, these parameters get the run-time value from a table or from a function. Examples of such functions are a random number generator or iteration counter. Other parameters are output arguments of test steps, created during test run to store values from the server response. As an input argument, a parameter is a marker consisting of the parameter name in brackets. The form of brackets is configurable, but is generally curly brackets {} or angle brackets <>. For example, the call to web_reg_save_param("outFlightVal", ...); causes output parameter outFlightVal to be created and a value assigned after the next action that leads to a response from the server. The parameter can then be used as an input argument: "Value={outFlightVal}".
61
Appendix A Glossary
Term
Definition
positional argument
(See also: argument, named argument)
An item in the parameter list of a function whose meaning is fixed by its position in the list. For example, this function has two positional arguments: int lr_param_increment (const char *destination_param, const char *source_param); A set of DLLs, resources, and configuration files to be used by LoadRunner to test a given type or types of application. For example, the FTP protocol is used to test FTP server applications. A special case is the utilities protocol (sometimes called lr functions) that provides LoadRunner services to other protocols. A source function that is recorded using a hook function during a recording session. The activity during which a VuGen user performs a series of actions that constitute a business process on a client application of the application being tested, while VuGen traps the communication between the client and the application. A code generation run initiated by the user. Regeneration is initiated by the user and runs the same process on the same data as code generation. However, depending on the protocol implementation, regeneration and code generation may be configured differently. An API of the application to be tested. A call in a test script to a function defined by a protocol (API function) or, less commonly, a call to an external program from a test script. In this guide, a test step is a call to an API function unless specified otherwise. The LoadRunner component that performs socketlevel recording for all protocols that require socketlevel events.
protocol
recorded function recording session
regeneration
source function test step
WPLUS
62
Appendix A Glossary
63
Appendix A Glossary
64

LR Protocol Configuration

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LR Protocol Configuration

Uploaded by

Copyright:

Available Formats

HP Performance Validation SDK

For the Windows operating system Software Version:11.50

Chapter 1 Configuration Reference

Chapter 2 Using HP Performance Validation SDK Configuration Builder

Chapter 2 Using HP Performance Validation SDK Configuration Builder

The Protocol Information Dialog

Description Display Name Location Protocol Icon

Protocol Location Protocol Version

Chapter 2 Using HP Performance Validation SDK Configuration Builder

The Template Files Dialog

The Additional Settings Dialog

Chapter 2 Using HP Performance Validation SDK Configuration Builder

The dialog has the following controls:

Description Display a browse dialog box to find a file or folder.

The API Functions Dialog

Chapter 2 Using HP Performance Validation SDK Configuration Builder

Description Edit the selected item.

The API Function Form

Display Name Function Name Icon ID

Return Value Type

Chapter 2 Using HP Performance Validation SDK Configuration Builder

The Arguments area includes the following elements (listed alphabetically):

Delete the selected argument.

Add a new function by copying the selected function.

Display Name Optional Parameterize Button

Chapter 2 Using HP Performance Validation SDK Configuration Builder

The Supported Platforms Dialog

The Run-time Settings Dialog

Chapter 2 Using HP Performance Validation SDK Configuration Builder

The dialog has the following controls:

The Recording Methods Dialog

Chapter 2 Using HP Performance Validation SDK Configuration Builder

The dialog has the following controls:

Add a new argument.

Delete the selected argument.

Edit the selected row.

Custom C API Hook Functions area

Chapter 2 Using HP Performance Validation SDK Configuration Builder

The Function Mappings Form

The dialog has the following controls:

Add a new argument.

Delete the selected argument.

Chapter 2 Using HP Performance Validation SDK Configuration Builder

GUI Element Record DLL

The Code Generation Dialog

Add a line in the Custom Filters area.

Chapter 2 Using HP Performance Validation SDK Configuration Builder

Description Delete the selected item.

The Recording and Regeneration Dialog

Chapter 2 Using HP Performance Validation SDK Configuration Builder

The dialog includes the following elements:

The Recording Settings Dialog

Chapter 2 Using HP Performance Validation SDK Configuration Builder

GUI Element Pre-Recording Check Post-Recording Check

Chapter 2 Using HP Performance Validation SDK Configuration Builder

This chapter includes:

Chapter 3 Configuration Files

The Template Folder

Chapter 3 Configuration Files

For a more detailed example, see Example of default.cfg on page 51.

Chapter 3 Configuration Files

Script Settings: The USR File

Example of an ExtraFiles Section

Permitted Function Calls: The ASL File