Dynamic data such as SessionID’s, __VIEWSTATEs, tokens etc. must be correctly managed in any tool that uses an HTTP script. So how do we do that with a model? First you need to know how to make the parametrization manually (Manual Parametrization). After you have that information, the extraction rules need to be transposed into the model.
In this section we are going to build a rule to parametrize the sessionUid parameter – below is a screenshot of a script where the sessionUid has not been parametrized:
In this case we are going to take the values that the ‘Extract Value…’ function gave us in the Manual Parametrization tutorial and put them into our model:
Noting - in the screenshot - that the text that we want to extract is between the <sessionUid> and </sessionUid> markers we can see that AgileLoad has only taken part of the left and right parameters (see Left Delimiter and Right Delimiter below). There are two things to consider here
While this extraction rule does work – we can see that by the fact that clicking on the magnifying glass brings up the correct value in the Value window, we can see that the left and right delimiter strings have been truncated – lets expand those out to read as follows:
This makes for a neater, more robust extraction and it will be easier to read if someone else needs to maintain the model later on. Next is to transpose this data into the model.
To do that we need to get to the Manage Session Configuration window, this can be accessed with the ‘Configure Selected model’ button (the one with the screwdriver and spanner on it) on the tool bar as per the screenshot.
This will bring up the Manage Session Configuration window as below.
We have the option to import a model; models are stored as xml files (AutoModelling.xml) in the \Program Files\AgileLoad\Config\AgileLoad folder, also we could alter the currently selected model or create a new one. For the purpose of this tutorial we will create a new one. The complete model to manage the script we are working on and the script itself is made available in the download section of Agileload Learning Centre.
In this tutorial we will only build a few rules to give an introduction to models. Clicking New we are asked to give the new model a name – choose a suitable one (I chose ‘tutorial’) and click OK. Now we need to start to build the model by creating Rules.
Do so by clicking the ‘New Rule’ button like here the screenshot on below. That will create a new line in the rules table below – give your rule a suitable name – ideally try to keep it close to the parameter that you are making dynamic. In this case I chose ‘sessionUid’. You’ll notice that by default AgileLoad chooses the ‘Variable’ option rather than the ‘SubStr’ option in the ‘Search in Script’ tab on the right of the table. Replacing HTTP parameters is relatively straight forward, in this example we will use the model to replace some data that exists in the body part of the request, this is more complicated than dealing with URL parameters. In the main it is only URL parameters that need to be modified (it’s quite rare in to have to modify Body parameters in traditional web applications, however more common in Ajax applications). So to work with a URL parameter just enter the name of the URL parameter in the ‘Variable’ box in the ‘Search in Data’ tab instead of using the ‘SubStr’ section that we deal with below.
There are three sections to the each rule, the ‘Search in Script’ part, the ‘Search in Data’ part and the ‘Replace by’ part. The ‘Search in Script’ part is where we tell AgileLoad what to replace in the script. The ‘search in Data’ part is where we tell AgileLoad where to get the data from in the response. Finally the ‘Replace by’ part is the script variable that we want the parameter to be replaced by. This can be a script variable or a literal value.
Looking at the script we know that we must replace a part of the Body of the request – we want to make value between the <sessionUid> and </sessionUid> tags dynamic, i.e. replace it with a script variable. The snippet below shows the part of the script we will parametrize:
So we edit the ‘Search in Script’ parameters as below:
Here we are taking the curly brackets as constant; this means that in the ‘Search in Data’ we have to make the extract from a response WITHOUT the curly brackets. If the match is not perfect the rule will not work and will be flagged as an error in the conversion, AgileLoad will explain if the data can be found but does not match in the conversion results.
Next we take the extraction parameters that we worked out in the previous tutorial (Manual Parametrization) and use the in the ‘Search in Data’ tab as below when we create a custom extraction rule. Note: the searches may work for your application, here though we will go through setting up a custom rule which is the most robust way to deal with parameters as it will avoid more problems if the application format changes.
In this screenshot we have deselected all of the default searches and we will click the ‘new’ button which will enter a line titled custom. Note: you can have multiple custom extraction rules and they will be run in the order in which they appear in this interface.
To bring up the custom rule interface we click on the ‘…’ button. The left and right delimiters have been entered below. Note: the curly brackets have been included as they have been included in the ‘Search in Script’ criteria earlier. Finally all that remains is to specify the ‘Replace by’ data in the tab with the same name.
The Variable we specify here is the variable that will exist in the script. Note: Expression would be used to replace the ‘Search in Script’ data with a literal expression; this might be a variable you have already created, it might be a call to a Date function or similar. If this is the case you should deselect all the options in the ‘Search in Data’ tab.
Once we’ve clicked OK the model is saved and is ready to use. Let’s apply it using the Apply Model button while the model is selected in the AgileLoad toolbar and see what difference it have made to the script, firstly Agile Load has created the script variables that will be used to hold the dynamic data, AgileLoad has identified that there are two instances of this variable and since we had the ‘Always create a new variable when value change’ check box selected in the ‘Replace by’ tab it has created two variables:
Next Agile Load makes the extractions:
Note: If you’re really paying attention you’ll have noticed that there is a _projectUID that is not parametrized! This will have to be dealt with in the same way that we dealt with the sessionUid otherwise this script will not work. This can be added to the model.
Now that AgileLoad has extracted the data it needs it then replaces the data in the script with a script variable as below:
Note: that the original value appears as a commented value above the new parametrized request.
Following the process above for every parameter in the script that changes will ensure that you have a robust, accurate, correct and working script. Note that parameters may be session based and change for every session with the application like the one we have just managed, they also may relate to the data you are accessing in your transaction, such as a record serial number, or a user id so be careful to record a few different versions of the script and check for the differences in these parameters. I find that ExamDiffPro by PrestoSoft is particularly useful for comparing two scripts that you have captured.
Finally don’t forget to backup and save your models, as explained earlier they are located in
\Program Files\AgileLoad\Config\AgileLoad or \Program Files(x86)\AgileLoad\Config\AgileLoad on a 64bit operating system.