0% found this document useful (0 votes)
112 views6 pages

Correlacion LR

The document discusses the LoadRunner web_reg_save_param correlation function. It describes that this function is used to register a request to find and save dynamic values from web requests based on boundaries into a parameter. It lists the function's attributes such as convert, ignoreRedirections, left and right boundaries, NOTFOUND handling, and parameter name. Examples are provided to demonstrate usage with required attributes only and with all attributes.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
112 views6 pages

Correlacion LR

The document discusses the LoadRunner web_reg_save_param correlation function. It describes that this function is used to register a request to find and save dynamic values from web requests based on boundaries into a parameter. It lists the function's attributes such as convert, ignoreRedirections, left and right boundaries, NOTFOUND handling, and parameter name. Examples are provided to demonstrate usage with required attributes only and with all attributes.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

LoadRunner - Correlation Functions - web_reg_save_param

There are five functions which can be used into the


script to correlate the dynamic value.
1. web_reg_save_param
2. web_reg_save_param_ex
3. web_reg_save_param_regexp
4. web_reg_save_param_xpath
5. web_reg_save_param_json
The use of these functions totally depends on the type
of dynamic value. In this blog, I have described all
the details related to web_reg_save_param.

1. web_reg_save_param: As the name suggested


this function is used for web protocol (denoted by
"web"). This function registers a request to find out
the dynamic value based on the boundaries (denoted
by "reg"). After registering the request, the next task
is to save the dynamic value in a parameter
(represented by "save_param" words). Hence it is
named as "web_reg_save_param".

Attributes of "web_reg_save_param":
a. Convert: This is an optional attribute. The
possible values are:
HTML_TO_URL: convert HTML–encoded data to a
URL–encoded data format
HTML_TO_TEXT: convert HTML–encoded data to
plain text format
b. IgnoreRedirections: This is an optional
attribute with default value "No". The possible values
are:
Yes: If "IgnoreRedirections=Yes" is specified and the
server response is redirection information (HTTP
status code 300-303, 307), the response is not
searched.
No: If "IgnoreRedirections=No" is specified then
after receiving a redirection response, search is
performed on the response from redirected location.
c. LB: This is a mandatory attribute. The left
boundary of the parameter or the dynamic data. If
you do not specify an LB value, it uses all of the
characters from the beginning of the data as a
boundary. Boundary parameters are case–sensitive
and do not support regular expressions. To further
customise the search text, use one or more Text
Flags.
d. NOTFOUND: This is an optional attribute and
default value is "Notfound-=error". This handles
option when a boundary is not found and an empty
string is generated.
"Notfound=error", the default value, causes an error
to be raised when a boundary is not found.
"Notfound=warning" ("Notfound=empty" in earlier
versions), does not issue an error. If the boundary is
not found, it sets the parameter count to 0, and
continues executing the script. The "warning" option
is ideal if you want to see if the string was found, but
you do not want the script to fail.
Note: If Continue on Error is enabled for the script,
then even when NOTFOUND is set to "error", the
script continues when the boundary is not found, but
an error message is written to the Extended log file.
e. ORD: This is an optional attribute and used to
capture dynamic value on specific occurance. If you
specify ORD=All, all the occurrences of the match are
saved in an array. Each element of the array is
represented by the ParamName_index. In the
following example, the parameter name is c_custID:
web_reg_save_param("c_custID",
"LB=customerID=", "RB=;", "Ord=All", LAST);
The first match is saved as c_custID_1, the second
match is saved as c_custID_2, and so forth. You can
retrieve the total number of matches by using the
following term: ParamName_count. For example, to
retrieve the total number of matches saved to the
parameter array, use:
Total_Matches=atoi(lr_eval_string("{c_custID_cou
nt}"));
f. Parameter Name: This is a required field. The
name of the correlation parameter to store the
dynamic value.
g. RB: This is a required attribute. The right
boundary of the parameter or the dynamic data. If
you do not specify an RB value, it uses all of the
characters until the end of the data as a boundary.
Boundary parameters are case–sensitive and do not
support regular expressions. To further customize
the search text, use one or more Text Flags.
h. RelFrameID: This is an optional attribute. The
hierarchy level of the HTML page relative to the
requested URL. The possible values are ALL or a
number.
Note: RelFrameID is not supported in GUI level
scripts.
i. SaveLen: This is an optional attribute. It saves
the length of the dynamic value from the specified
offset; to the parameter . The default is –1, indicating
to save to the end of the string.
j. SaveOffset: This is an optional attribute and it's
default value is 0 (zero). The offset of a sub–string of
the found value, to save to the parameter. The offset
value must be non–negative.
k. Search: This is an optional attribute with default
value "ALL". The scope of the search—where to
search for the delimited data. The possible values
are:
Headers (Search only the headers)
Body (search only body data, not headers)
Noresource (search only the HTML body, excluding
all headers and resources)
ALL (search body , headers, and resources).
Example 1: With required attributes only

Example 2: With all attributes


La función loadrunner web_add_ (auto) header () y un proxy que crea
tokens saml cuando se prueban servicios web - web-services, proxy, saml,
loadrunner

¿Cuál es la diferencia entre web_add_header ()y web_add_auto_header () en LoadRunner? Mi tarea es enviar


cierta información de encabezado en una solicitud de petición web contra un proxy que, sobre la base de esta
información, es decir, el nombre de usuario y el nivel de autenticación genera un token de SAML que se usa
más en una solicitud contra un servicio web.

Respuestas
2 para la respuesta № 1
La diferencia es el contexto para el encabezado agregado.

 ..._ add_auto_header () agrega el encabezado a todas las siguientes solicitudes


 ..._ add_header () se agrega solo a la siguiente solicitud
Si necesita actualizar tokens para cada solicitud, entonces web_add_header () es el camino a seguir.
El científico loco en mi probablemente intentaríaexperimentando con el encabezado para ver si agregué un
encabezado con etiquetas de parametrización y luego usé lr_save_string () para asignar un valor a la variable si
ese cambio se detectaría cuando se enviara el encabezado.

You might also like