DoxRunner
​
Process Raw Operation
The Process Raw operation applies the rules that are documented in a Test Case to a raw script using three stages described below. It is initiated using the steps described under Initiate the Initiate the Process Raw section below.
A raw script is defined as one that was recorded using the steps described under Script Operations and has the characteristics described under Characteristics of a Raw Script below.
​
Make sure you check the raw script before proceeding.​
​​
​​
Characteristics of a raw script
If the script was recorded the DoxRunner way, then all requests will be in Action.c (vuser_init.c and vuser_end.c will be empty). This is important for the Process Raw to operate. The Process Raw operation will transfer the Requests to the correct action file as appropriate.
Only lr_start_transacion() functions will be in place - no lr_end_transaction() functions. The Process Raw operation will automatically append them to the last Request of the Timer.
The name within each lr_start_transaction() will only be the Timer ID, not the Timer Name (only digits, no letters). The Process Raw operation will automatically update them to a Timer Long Name.
All Timer IDs will be sequential (gaps in the sequence are OK). This makes the Analysis Report easier to read and is critical when the Process Raw operation transfers Requests from Action.c.
​
No values are parameterised unless they were defined in VUGen. The Process Raw operation will do this.
​
Only web_reg_find() functions that conform to VUGen rules (that is, <title> </title>) will exist. The Process Raw operation will add more if configured to do so.
​
Think time will be "as recorded".​ The Process Raw operation will update them if configured to do so.
​
​
Check the raw script
After recording the script, open it in VUGen and check that the lr_start_transaction() functions are as defined above. Fix any mistakes in the Timer IDs. Make sure they are integers and are sequential - update the Timers documented in the Test Case if necessary. Investigate any Timer that has no request. Timers with no requests should be deleted from the script. Consider removing them from the Timer table of the Test Case too (although they need not be).
Below is an example of a raw script with a couple of issues that you may encounter and may need to correct before initiating the Process Raw operation.
Initiate the Process Raw operation
​
Open the Solution document and identify the Quick Access Toolbar icon that you defined when Getting Started.
If you haven't done this, refer to the Quick Access Toolbar Icon instructions.
The one in the illustration below may not be the Quick Access Toolbar icon that you configured in the Getting Started instruction. Click the one you configured.
​​
Select the Test Case
The Process Raw operation will gather and display the Test Cases listed in the Test Case Summary section of the Solution document.
​
You will typically choose one then press the Script Operations button. However you can choose more than one by adding them to the right hand pane using the Add button before pressing the Script Operations button.
​
Select the operation
In this case the operation is Process Raw.
As shown in the screen below, the items above the Operations frame are values extracted from the Foundation and Folders CIs documented by you in DoxRunner's Configuration Items section.
If necessary they can be changed here before continuing.
Select Process Raw. The options will then display.
Other Script operations:
Select the options
​
When the Process Raw operation is selected, its dialog box is extended below the Operations frame as shown below, exposing several options, giving you some control over how DoxRunner processes the raw script;​
When you are satisfied, press Apply. If this is the only raw script for the selected Test Case, the Process Raw operation starts.
​
If there is more than one script for the Test Case, another dialog box will display so you can select which one. For this to be required, the names of all raw scripts for the selected Test Case must begin with the Test Case ID.
​
Review the Three Stages summary in the next section for what happens next.
​​
Timer Options:
​
​ The recorded Timer IDs are replaced by the Timer Long Name using the Timer Name Template as a guide. The Timer Name Template is extracted from DoxRunner's Configuration section and can be defined by you. It is displayed here to allow you to tailor it. Some testers prefer underscores instead of spaces between the components;​​​​​​​
​
Wherever standard LR transaction functions are used, an additional pair of LR transactions are added if this option is selected. These are called Common Timers and add value to the Analysis Report;
​​​
If selected, an end_to_end timer is wrapped around all transactions in Action.c. This allows the total time that all Requests in the entire Iteration to be displayed in the Analysis report.;
​
All timers are extracted from Action.c and saved into their own file (rarely used);
Think Time options:
​
Recorded think times will not be changed;
​
Recorded think times will be replaced by those documented in the Think Time column of the Timer, or, if empty, the default value that you documented in DoxRunner's Configuration section are used;
​​​
Recorded think times will be replaced by the static value specified. In the example on the right, the value of all think times will be set to 6 seconds. This value is derived from the default value that you documented in DoxRunner's Configuration section;​​​​​​​​​​​​
​
​The think time range in the script's Runtime Settings is set to this specified range.
Miscellaneous options:
​​
​Scripters often simply delete the Referer clause of all requests rather than spend the time parameterising them. Since DoxRunner parameterises the Referer clauses, deleting them may be unnecessary. Including them makes for a slightly more accurate load;
​​
Everything within the EXTRARES part of all requests will be deleted. Best not to select this unless you know what you are doing;
​
​If cookies appear in a script they are usually not necessary;
If the scripter is in the iteration phase of script development the scripter may not want data to be correlated yet;
​
Sometimes it's easier to review a script's data within ITEMDATA areas that contain a lot of items if the names are sorted;
But also sometimes the application depends on the order of the names, so it's best not to select it unless you know;
​
If there are any LoadTest Database parameters defined, then they need the name of the mySQL database name.
This is normally held in DoxRunner's Configuration section, but is presented here in case the scripter needs to change it.
​
Select the script
The screen below will only display if there is more than one raw script with the same Test Case ID.
​
When you are satisfied, press Select and the Process Raw operation starts. Review the Three Stages in the section below for what happens next.
​
Three Stages
​
Once initiated, the Process Raw operation executes in three stages:
​​
Stage 1:
-
The script is archived for safety;
-
Managed Items are extracted from the Test Case and Solution document sections;​
-
Documented Request rules are identified and a tentative parameter name is applied;​
-
Tentative parameter names end with "_NotFound";
-
These Requests are matched with Responses in Stage 3.;
-
-
Text items that looks like it could be parameterised are collected;
-
These are called Unassociated Name/Value Pairs and are presented to the scripter in Stage 2;​.
-
​​​
Stage 2:
-
Display the Parameter Association form with the following components that were collected in Stage 1:
-
List of Unassociated Name/Value Pairs;
-
List of Custom parameter rules;
-
List of Text Data File parameter rules;
-
List of LoadTest Database parameter rules;
-
List of Date/Time parameter rules;
-
List of Additional Attribute parameter rules;
-
List of Random Number parameter rules;
-
List of VTS parameter rules.
-
-
The scripter needs to manually associate a parameter rule to an Unassociated Name/Value Pair.
​
Stage 3:
-
Any .c files in the Included Files folder are copied into the Script's folder;
-
They are incorporated into the script as Action files;
-
Ideally a SessionManagement.c file should be included;
-
-
The tentative Requests identified in Stage 1 are matched with the documented Response rules and parameterised;
-
The Unassociated Name/Value Pairs associated in Stage 2 are parameterised;
-
The associated value for a Custom parameter is assigned at the top of vuser_init.c or Action.c depending on several criteria;​
-
If any Text Data File parameters are associated, the script is configured accordingly;
-
If a text data file exists in the Included Files folder, it is copied into the Script's folder;​
-
Otherwise an empty Text Data File is created in the Script's folder;
-
-
If any VTS parameters are associated, the script is configured accordingly;
-
If any LoadTest Database parameters are associated, the script is configured accordingly;
-
The four LoadTest Database files are copied from the Included Files folder;​
-
The two .dll files copied from the Included Files folder are incorporated into the script as Extra files;
-
-
If any Additional Attributes are associated, the Runtime Settings are updated accordingly;​
-
Code is inserted into vuser_init.c to extract the Additional Attribute value and parameterise it;​
-
-
If any Random Number parameters are associated, the script is configured accordingly;
-
Timers:
-
All lr_start_transaction() functions are updated with the full Timer Name in accordance with the Timer Name Template;
-
The end of all requests in a transaction is identified and the relevant lr_end_transaction() functions are inserted;
-
If the option was selected, all Timers are wrapped with Common Timers;
-
If configured, the script is configured for Error Recovery...
-
All Timers with Phase LI are moved to the Login() function in SessionManagement.c;
-
All Timers with Phase TI are moved to the ToIteration() function in SessionManagement.c;
-
All Timers with Phase LO are moved to the LogOut() function in SessionManagement.c;
-
The script is configured for Error Recovery;
-
-
...otherwise...​
-
If selected, all Timers remaining in Action.c are wrapped with an End_To_End Timer;
-
The documented Timer's Expected Results are inserted as a comment;
-
The documented Timer's NFR is inserted as a comment;
-
Timers are formatted for readability;
-
​The values of all Foundation CIs are inserted into vuser_init.c as comments;
-
-
The script is saved and a copy is archived into its Archive folder as "Post Raw".
​​​​​
Script safety
​
Refer to the illustration below when reading the 4 steps that the Process Raw takes to make safety copies of the script.​​
​
Use the Restore Files operation to restore any archived script.
​
When initiating the Process Raw operation for the very first time against a raw script, a new sub-folder called ArchivedByVUGenScriptSupport is created and a copy of the raw script is archived into it, time stamped, with suffix "Raw".
​
Example: C:\Cane View\CEP001_Cane Estimation Process\ArchivedByVUGenScriptSupport\2025_02_17 13_20_52 Raw\...
If the Process Raw operation is re-executed against the same script, then the Process Raw operation uses this raw script, not the one directly under the script's folder.
​
When the Process Raw operation completes its task for the first time, the raw script directly under the script's folder is updated, and the updated version is copied to the ArchivedByVUGenScriptSupport folder, time stamped, with suffix "Post Raw".
​
Example: C:\Cane View\CEP001_Cane Estimation Process\ArchivedByVUGenScriptSupport\2025_02_17 16_29_34 Post Raw\...
​
​If the Process Raw operation is re-executed against the same script, the version in the script's folder is copied into a new sub-folder, time stamped, and with suffix "Safety Raw". This is in case the scripter manually updated the script and initiated the Process Raw operation by mistake.
​​​
Example: C:\Cane View\CEP001_Cane Estimation Process\ArchivedByVUGenScriptSupport\2025_02_17 18_31_44 Safety Raw\...
​
Then the version in the script's folder is deleted and replaced by the version in the sub-folder with suffix "Raw".
That is, the Process Raw operation always operates against the original Raw version.
​
When the Process Raw re-execution is complete, the updated version is copied to a new folder, time stamped, with suffix "Post Raw"
​
Example: C:\Cane View\CEP001_Cane Estimation Process\ArchivedByVUGenScriptSupport\2025_02_17 33_39_27 Post Raw\...
Subsequent re-execution of the Process Raw operation against the same script will result in a new "Safety Raw" and a new "Post Raw" sub-folder, each with different time stamps. If there are many of these, and you are sure you won't need them, they can only be manually deleted.
​
A new recording of a script from the same Test Case should result in a new script name. A Process Raw operation on this new recording will start the safety process all over again, starting at xxx above.
Collect Managed Items​
DocRunner reads all Managed Items from the Solution document and the Test Case.
If a Managed Item in the Solution document also appears in the Test Case, the Test Case version is used.
​
Seven Managed Items are presented to the user in Stage 2 in the 7 tabs on the right. Refer to the illustration below.
​
Request Correlation rules are used to identify text in the script that could be correlated - see Identify Request Correlation Rules below.
​
Response Correlation rules are used to finalise the correlation of those Requests identified. This is done in Stage 3.​​​
Collect Unassociated Name/Value pairs​
DocRunner applies an algorithm to the text in all components of the script to prepare a list of Name/Value pairs that could be parameterised. These are presented to the scripter along with documented Test Case rules in Stage 2.
​
Refer to the illustration below.
​
In Stage 2, the scripter manually allocates these Name/Value pairs to the documented Test Case rules.
​
Stage 3 replaces the Value component of the Associated Name/Value pairs with the parameter name.​
Identify Request Correlation Rules
​
The Process Raw operation identifies all text in all requests that meet the documented Request Correlation Rules.
​​
The documented Request Correlation Rules include the Parameter Name, the Role, and the Configuration as shown in the illustration below. The example shows the Configuration to include the LB and RB. Refer to the Correlation Rule Managed Objects for more details.
​​
Text in the script is identified by the Configuration as shown in the example below.
In that example, the LB is "sap-nwbc-context=" and the RB is "&".
​
All text identified is replaced by a temporary parameter structured as shown in the illustration below. The Sequence number is simply a unique number designed to separate those cases where the same Parameter Name is used for different text.
​
The temporary parameter is replaced in Stage 3 by a final parameter, once the snapshot containing the Response Correlation Rule and the Request's value is found.
​​
Stage 2
​
​​Parameter association
​
Stage 2 is all about the Parameter Association form that loads after Stage 1 completes.
​​
Stage 1 will have collected all Managed Items from the Test Case and the Solution document.
Seven of them are displayed under the seven tabs on the right of the form.
​
Also, Stage 1 will have collected a number of Name/Value pairs from the script. These are displayed in the left hand pane.
​
The scripter needs to associate Managed Item parameter names from the right hand panes, with as many Name/Value pairs as practical. If a Managed Item parameter name can be associated with a Name/Value pair, press either the "Associate by value" or the "Associate by boundary" button.
​
The association is displayed at the top of the bottom pane.
​
When as many associations as possible is complete, press the Apply button and Stage 3 will begin.
​​​​
Stage 3
​
Stage 3 applies all of the information that DoxRunner has gleaned from the raw script, the Test Case, and the Solution document in Stage 1, and the Parameter Association form in Stage 2.​
​
​​​
Response Correlation
​​​
As shown in the illustration below, Correlation rules that are documented in the Test Case and the Solution document are structured with a Parameter Name, a Role, and a Configuration.
​​​
Stage 1 is all about the documented Request Correlation rules. It pre-processes the Requests in the script by identifying text that matches one of the Request rules and replaces it with a tentative parameter structured as {ParameterName_SequenceNumber_NotFound}. Example: {pYards_43_NotFound}
​
Stage 3 is all about the documented Response Correlation rules. In the example below, the Response rule contains an LB and RB that all LoadRunner scripters are familiar with.
​
It completes the tentative parameters prepared in Stage 1 by searching the Responses in the CodeGenerationLog.txt file that can be found in the /Data/ folder of the Raw script. An extract is shown below as an example.
​
When it finds the appropriate Response it knows the correct snapshot name. It then replaces the tentative parameter with one structured as {ParameterName_Snapshot_SequenceNumber}. Example: {pYards_t65_43}
​
As well as replacing the tentative parameter, it appends the original value to the Request line as a comment. Sometimes this is handy for the scripter to know when debugging the script.
​
DoxRunner also inserts a relevant web_reg_save_param_ex() function just before the Request with the snapshot name of the Response. In the example below, the request will be t205, not t213. It also appends the original text as an aid to the scripter.
Note that it escapes the LB and RB if necessary.​
​​
​​
Transfer Timers using Phase​
​​​​
When recording a raw script the DoxRunner way, all transactions will reside in Action.c. They need to be moved - some to vuser_init.c, and others to vuser_end.c. This is done automatically by DoxRunner during the Process Raw operation using the contents of the Timer's Phase column.
​
The transfer comes with two options:
​​
The Error Recovery option is preferred and is described in the next section.
​
​​There are four phases recognized by the Process Raw operation, and they must appear in the same order as the description of each here:
LI - Log In - optional - the step(s) needed to log in.
These are normally moved to vuser_init.c, or a function that is called from vuser_init.c
TI - To Iteration - optional - the step(s) needed to move the session from the login or home page to the first step of the iteration. These are normally moved to vuser_init.c, or a function that is called from vuser_init.c.
I - Iteration - mandatory - the steps executed during each iteration. These are normally left in Action.c.
LO - Log Out - optional - the step(s) used after all iterations are complete.
These are normally moved to vuser_end.c, or a function that is called from vuser_end.c.
​​​​​​
Default operation
​
Referencing the illustration below, DoxRunner has the following default operation:
​
​ Timers 1 and 2 show LI in the Phase column. This is short for Log In. They are transferred to vuser_init.c.
​
Timers 3 and 4 show TI in the Phase column. This is short for To Iteration. They are transferred to vuser_init.c also.
​
Timers 5 to 14 show I in the Phase column. This is short for Iteration. They remain in Action.c.
​
Timers 15 to 99 show LO in the Phase column. This is short for Log Out. They are transferred to vuser_end.c.
​
​The Process Raw operation will:
-
Transfer Timers 1 to 4 from Action.c to vuser_init.c;
-
Transfer Timers 15 to 99 from Action.c to vuser_end.c;
-
Timers 5 to 14 will remain in Action.c.
​​
Note that DoxRunner makes no functional distinction between LI and TI - these are separate for documentation reasons only.
​
Although this default option requires no effort other than making sure the Phase column of all Timers is consistent, the Error Recovery option should be considered as explained in the next section. It requires very little extra effort.
​
If LoadRunner encounters an error while processing the transactions in Action.c, and it is configured to continue processing after error, then the transactions following that error often don't make sense to LoadRunner, and the script will continue to fail until it encounters a response to a request that makes sense.
​
A professional scripter will make sure that the script and application are functioning properly prior to any load test, so that any errors should only be due to load, such as timeouts or invalid responses under load.
​
DoxRunner has the ability to configure a script so that if LoadRunner encounters an error during the Iteration phase, it returns to a known point in the application by logging the VUser off, then back on again. Then the transactions in Action.c will start at the first one, and LoadRunner will continue either without error, or until another error is encountered.
​
By default, when recording a raw script the DoxRunner way, all transactions are placed into Action.c. By default, the Process Raw operation described above uses the Phase column to transfer timers from Action.c to vuser_init.c and vuser_end.c.
However the Phase column can also be used to configure the script for error recovery. It looks complicated, and it isn't simple, but it is easy to set up and, once set up, requires no further action.​​​​​​​​​​​​​
​
Compare the right-hand side of the illustration below with the one above. Instead of transferring Timers from Action.c to vuser_init.c or vuser_end.c, they are transferred to one of three functions. A skeleton of these three functions are contained in a file named SessionManagement.c, which is available for download from this site using an option under the Getting Started menu. By placing it into the Included Files folder, DoxRunner will automatically copy it into the script's folder as an Action file, detect the three functions in it, and place the appropriate requests from Action.c into them based on the Phase that should be documented in all Timers.
Referencing the illustration below, DoxRunner does the following to the Timers in Action.c:
​
​ Timers 1 and 2 show LI in the Phase column. This is short for Log In.
They are transferred to any .c file that contains the following text: "// <Transfer phase LI to here>;"
File SessionManagement.c contains this text within a function called Login().
​
Timers 3 and 4 show TI in the Phase column. This is short for To Iteration.
They are transferred to any .c file that contains the following text: "// <Transfer phase TI to here>;"
File SessionManagement.c contains this text within a function called ToIteration().
​
Timers 5 to 14 show I in the Phase column. This is short for Iteration. They remain in Action.c.
​
Timers 15 to 99 show LO in the Phase column. This is short for Log Out.
They are transferred to any .c file that contains the following text: "// <Transfer phase LO to here>;"
File SessionManagement.c contains this text within a function called LogOut().
​​​
Note that DoxRunner makes no functional distinction between LI and TI - these are separate for documentation reasons only. If, once logged in, the application is already at the Iteration point, then TI is not necessary.
​
As well as transferring the Timers as explained above and shown in the illustration below, DoxRunner adds code to the script to enable error recovery. This is explained after the illustration below.
​
In addition to transferring the Timers into the appropriate functions within SessionManagement.c, DoxRunner adds code to the script as shown in the illustration below.​
All requests within the Timers with Phase LI will be copied from Action.c to wherever the template // <Transfer phase LI to here>; is located. In the illustration, that template is within the Login() function in action file SessionManagement.c.
​
All requests within the Timers with Phase TI will be copied from Action.c to wherever the template // <Transfer phase TI to here>; is located. In the illustration, that template is within the ToIteration() function in action file SessionManagement.c.
​
All requests within the Timers with Phase LO will be copied from Action.c to wherever the template // <Transfer phase LO to here>; is located. In the illustration, that template is within the LogOut() function in action file SessionManagement.c.
​
​​​
Integer iIterationStatus is defined in globals.h. This variable is toggled between 0 and 1, depending on whether the iteration failed or succeeded.
​​
​
​
​
All login requests and those requests required to get to the iteration point should be in vuser_init(). Since DoxRunner will have moved these requests to functions Login() and ToIteration() respectively, DoxRunner simply places calls to these two functions in vuser_init.c.​
​iIterationStatus is flagged as succeeded to make sure that the first Iteration is attempted.
​​​
​
​​​​
​
At the top of Action() a test is made to see whether the previous iteration succeeded. If not, the vuser is logged out and logged back in. ​iIterationStatus is flagged as failed, in preparation for the possibility that it doesn't reach the end of the Iteration transactions..
​​​​​
If LoadRunner fails during the iteration, then iItertionStatus will remain as failed.
If the end of the iteration is reached, then iItertionStatus is set to succeeded, and the vuser is not logged out.
​​
​
​At the end of the test vuser_end() is reached and the vuser is simply logged out.
​​
Format Transactions
​​​
Standard Timers
​Readability
Expected Results
NFR Requirements
Think Time
web_reg_find()
Common Timers
​​​​
DoxRunner makes substantial changes to the beginning and end of each transaction.
The sections below take you through each step of the process.
Some items need to be initiated by the scripter, some rely on the Test Case and Solution document documentation, and some are automatically applied.
Below is a view of two typical requests taken from a raw script. These make up one Timer (with ID "3") and will be used in the following examples.
​
​​​​​The Process Raw operation makes significant changes to the format of a transaction.
The illustration below shows how Timer rules are used to format each transaction.
​
DoxRunner places a line at the beginning of all transactions to make the script more readable;
​
The Timer Long Name is constructed by appending the Timer Name to the Timer ID.
Refer to the lr_start_transaction paragraph further down this page for more details;
​
Notes are not used by the Process Raw operation - refer to the Recording Aid section;
​
The Expected Results are inserted into the script as comments;
​
The lr_think_time() function is either untouched, or inserted into the script using the documented Think Time, or a static value is used, depending on the option set. Refer to points xxx to yyy in the Process Raw Options section above;
​
The text from the Response Time NFR column is assessed. If it references an NFR ID from the NFR Section, then the text from the NFR Requirement column is inserted into the script as comments. Otherwise the text from the Response Time NFR column is inserted into the script as-is;
​
Although it is normal to record transactions into at least three files (vuser_init.c, Action.c, and vuser_end.c), recording
the DoxRunner way means that all transactions are recorded only into Action.c. Using the Phase column in the timers
table, the DoxRunner Process Raw operation will automatically move Timers from Action.c to vuser_init.c and vuser_end.c;​
​
If the Validation column has a value, a web_reg_find() function is created just before the lr_start_transaction() function using that value;
​
The last request in the transaction is identified and an lr_end_transaction() function is inserted.
​​​​​​​​​
​​​
Format the Standard Timer Names
​​​
In the context of DoxRunner, Standard Timer Names are simply the name within lr_start_transaction() and lr_end_transaction() functions that all LoadRunner SMEs are familiar with. As shown in the Raw Script example, above, when recording the DoxRunner way, all lr_start_transaction() functions only contain the Timer ID, and there are no lr_end_transaction() functions.
​
The illustration below shows how the Process Raw operation changes that.
​
The Solution document contains a section that documents relevant Configuration Items. It contains a Timer Template, giving the scripter some control over how the Timers are named. The example is suggested because it's ideal. It results in all Timers in the Analysis Report to be grouped by Test Case ID, and within that group, they are listed in the same order as the steps in the business process it is meant to simulate. This makes it easier to understand the Analysis Report.
​
The Timer Template is included in the Process Raw Options form to allow the scripter to change it if necessary.
​
In the example, the Timer Long Name is made up of the Test Case ID, the Timer ID, and the Timer Name. The latter two are derived from the table in the Test Case's Timer section.
​
The Process Raw operation identifies the last Request in the transaction and inserts the lr_end_transaction() function, including the new Timer Long Name. This last step is done automatically - there is no need to document it or select any option.
​
Wrapping Common Timers​
​​​
​Common Timers are discussed on the Transaction Timers page.​
​
It is not necessary to document Common Timers - they are generated automatically if selected within the Process Raw Options form as shown in the illustration below.
​
​​​​​​ Select the Add common timers option when presented with the Process Raw Options form.
​
The resulting Common Timers are highlighted below in yellow. They only contain the Timer Name, preceded by an underscore.
​
No other configuration options or documentation is required - it all happens automatically once the option is selected.
​​
​
Think Time
​​
When recording a raw script, the think time that LoadRunner records is not necessarily valid in a production environment. The scripter may be interrupted, or paused while figuring out the next step, or may go faster than a typical user. It is often more valid to look at each step and assess a reasonable time, then document that in the Think Time column of the Timer Table.
​
The Process Raw operation only focuses on those lr_think_time() functions that were recorded before the first request in a transaction. That is, if there are multiple requests following the lr_start_transaction() function, DoxRunner does not touch any lr_think_time() functions that may be located between them.
​
When initiating the Process Raw operation, you have the option of:​
-
using the value recorded (ie. DoxRunner doesn't touch any of them);
-
using the value you documented in the Timer Table (as explained below);
-
using a fixed value as documented in the Configuration section.
​
These three values are specified at xxx in the illustration below.
​
In the example in the illustration below:
​
The documented Think Time is 20 seconds;
​
The Process Raw operation Think Time option is to use this value;
​
The script is configured accordingly.
​
​If the value in the Think Time column is empty, or there is no Think Time column, then the default value that is documented in the Configuration section is used.​​​​​​
​
​​
Response Validation
​
​​This section refers to the web_reg_find() functions and how the Process Raw operation structures them.
​
​There are three levels of validation covered here. DoxRunner supports two of them.​​
​
Method 1: Standard VUGen Validation;
​​Method 2: Using the two Validation CIs in the Configuration Section;
​​Method 3: Using the Validation column of each Timer.
​​​​​​​​
Standard VUGen Validation
​
This is not a DoxRunner function - it is standard VUGen. When recording, the VUGen setting in the illustration below allows VUGen to identify text between the title tags in the response to a request, and configure the script with web_reg_find()
functions accordingly.
​
​If you configure the VUGen Recording Options as shown in the illustration below, VUGen will record web_reg_find() functions accordingly. This is not a DoxRunner function.​ The Process Raw operation will not change them, but it will append a comment showing .
If a transaction contains many requests, any resulting web_reg_find() functions may appear before any of them, not just the first one.
​​​​​​​​​​​​​​​​​​​​​​​
​
Documented Template Validation
​​
Standard VUGen validation, as mentioned above, searches for text in all responses using <title> and </title> as the LB and RB.
​
DoxRunner offers an additional method of specifying the LB and RB via a Validation Template, which is located in DoxRunner's Configuration section. It consists of two Configuration Items as shown in the illustration below.
These are used by the Process Raw operation to extract values from the responses in addition to the Standard LoadRunner method.
​
The LB and RB text is included in the web_reg_find() function.
​​​​​​​​​​​​​​
​​​​​
Documented Timer Validation
​
DoxRunner can prepare additional web_reg_find() functions using the Timer's Validation column.
If there is a value in the Validation column, then the Process Raw operation will use it to prepare a web_reg_find() function and place it before the first request in a transaction - just before the relevant lr_start_transaction() function.​​​​
​​​​​
Non-Functional Requirements (NFRs)​
​
The Process Raw operation simply converts the NFR column in the timer table to a comment and inserts it into the script just below the Expected Result comment.
​
​This is automatic - there is no documentation or configuration required.
​ NFRs are usually solution-wide and are documented in their own NFR Section, with the NFRs having an NFR ID each.
​
​ Timers have an NFR associated with each. These are listed under the Response Time NFR column, where they can be documented as a single figure such as 3 secs, or as an NFR ID, referencing the NFR Section.
​​
​ In the example in the illustration below, the timer is configured with L in the Response Time NFR column. L references an NFR in the NFR Section with Category of Long. The Requirement with NFR ID of L has a summary of the requirement. The Process Raw operation inserts this text as a comment just after the Expected Results comment.
​​​​
​
Wrapping End_to_End Timer​
​
If the Add 'End to End' timer option was selected in the Process Raw Options form, the operation wraps all requests in Action.c with an 'End to End' Timer. This assumes that all requests in Action.c are those expected to execute in a test only during the Iteration phase.
​
More details can be found on the Transaction Timers page.
​The illustration below assumes that the Phase column for timers 5 to 14 shows the letter I, short for Iteration.
​
​​​​ Select the Add 'End to End' timer option when presented with the Process Raw options, as shown in the extract below.
​
The End-to-End lr_start_transaction() function is added just before the first timer cluster in Action.c.
​ Also it will add the End-to-End lr_end_transaction() function just after the last end timer cluster in Action.c.
​
No other configuration options or documentation is required - it all happens automatically once you select the option.
​​​​
​​​​
Think Time Runtime Settings
​
The think time range in the LoadRunner runtime settings can be specified when the Process Raw options form is displayed, as shown in the illustration below.​
​
Note also that the runtime settings in the illustration below is set to ignore Think Time. This is set using the assumption that the scripter will want to shake out the script before including it in a test, and think times are irrelevant and slow down the shakeout. It must be changed manually prior to any test.
​
​​
One File per Timer
​​​​​
Some performance test analysts like to configure their LoadRunner scripts so that there is one file per Timer.
​
​DoxRunner has an option that supports this behaviour.
​
​​​​ Select the One file per timer option when presented with the Process Raw options, as shown below.
​
The Process Raw operation creates a separate action file per Timer containing all requests for that Timer, plus the ancillary functions like lr_start_transaction(), lr_think_time(), web_reg_find() etc. The illustration below shows the first request for Timer 5.
The new action files are called from the relevant vuses_init(), Action.c(), or vuser_end() functions. The illustration below shows Timers 5, 6, and 7.
​​
A list of all action files showing one per Timer for Test Case CEP001.
​
No other configuration options or documentation is required - it all happens automatically.
​​​​​​​​
Check the processed script
Once processed, the scripter should inspect the updated script and continue to update it as he or she would normally do. As the script is manually progressed to completion, the scripter needs to assess whether the test case needs to be updated as well. Any updates to the test case will be valuable for the next recording, reducing manual effort each cycle.
Repeating the Process Raw operation
After the Process Raw operation you may find that you need to update the test case and re-run it, or maybe you need to select a different option. If so, the version that is selected for execution will be the one in the Raw folder, not the one in the normal script folder, as shown in the diagram below. The version in the normal script folder will be archived before the one in the Raw folder is used.
​