Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

What are recording rules and what are the benefits of using them in my project?

What are recording rules and what are the benefits of using them in my project?

All SilkPerformer users will recognise the following scenario... a script that has been recorded without problem contains some unique value in a form which needs to be customized, meaning that replay of the script is unsuccessful. Long-term SilkPerformer users may shudder as they recall the need for several minutes of manual customization of the script.

Of course, this process has become much simpler in recent versions, and most people now begin the process of customizing the script using TrueLog Explorer. But whilst this is a very effective approach, wouldn't it be even better to have a script that is automatically customized to deal with dynamic data sent from the server?

Well, you can, thanks to a relatively little-used, but very powerful feature known as Recording Rules.

Introduced in SilkPerformer 5.1, many users either do not know about these recording rules or have never taken the time to effectively use them. If you have used any of SilkPerformer's custom SilkEssential packages for Siebel, PeopleSoft or OracleForms, you will already have seen recording rules working, albeit under the hood.

Recording rules are XML based files that instruct the SilkPerformer recorder to make changes to the script before it generates it. You create a recording rule which identifies the data the recorder needs to customize by, for example, specifying the data boundaries, and then letting the recorder do the rest. Once you do this you can record an unlimited number of scripts against the same application without ever having to customize anything.

An example will help to explain this process. This article will employ the ShopIt application which ships with SilkPerformer, the goal being to customize a form (in this case replacing the value of a session id in the recorded script). The steps taken are as follows:

Search the HTML source code for the form value. The recorded session id can be found in the script and can be used for searching in the record.xlg file (see Fig 1).

Fig 1: find the data you wish to customize and make a note of the boundaries

Once located, determine the left and right boundaries and start building the recording rule as follows:



Here we use a tag to tell the recorder how to identify the left boundary and right boundary . Per XML standards certain characters are reserved and need to be encoded. For example the left boundary of this form is name=" and the right boundary is ". The quote is a reserved character and must therefore be encoded as " . Table 1 details the encoding for the most commonly used reserved characters.


Table 1. Encoding Special Characters in XML Files

We also need to tell the recorder where to search for the data. In this case the data is found in the HTTP response body - the page's source code - and we identify this using


Having identified the data we want to replace in the generated script, we then need to tell the Recorder what changes to make in the generated script. This is done within the tag:


Here holds the variable name MyVarName which will be used to store the data. Don't worry if you are replacing multiple values, the recorder will automatically append a numeric value to the end of your variable name and increment this each time it is used (i.e. MyVarName001, MyVarName002). We also tell the recorder where in the script the variables should be used. The options are


  • All
  • Url
  • LinkName
  • FormName
  • PostedData
  • FormFieldName
  • FormFieldValue
  • SetCookie


If you are confident that the value will not appear anywhere else in the script then all can be used, as here.

Putting the whole thing together, along with additional required tags we have:

    A Sample Parsing Rule


This rule may now be saved in a file with an .xrl extension. There are two places for rules to be saved depending on whether they are to be used globally across all projects or for the current project only. If you wish it to apply to all projects, it should be saved to SilkPerformer's Working\Include directory. If it is only to be applied to a single project it should be saved to the local project directory within a Documents directory which you will need to create (see Fig 2).

Fig 2: Rules saved to a local directory will only affect that project's scripts

The final stage in the recording rules process is to record the same scenario again and, hey presto, your script is generated and customized without the need for any intervention on your part. SilkPerformer will have automatically inserted the required parsing functions and replaced the recorded session id with a variable.

The power of recording rules can also be used to help in generating more robust TCP/IP scripts. One of the main issues with TCP/IP scripts is that the responses on replay are likely to be different than during record. This usually causes winsock errors on replay because the recorded SilkPerformer WebTcpIpRecvExact functions expect back a different amount of data than is actually sent.

Recording rules help SilkPerformer cope with this. There are two primary means for applications to identify the amount of data that is contained within a TCP/IP response:-


  • A length specification within the data packet
  • A terminating character sequence indicating the end of the data.


Recording rules can be used to handle both situations. Take, for example, the following which represents the end of a particular TCP/IP response:



We can see that the response finishes with what appears to be a terminating sequence \r\n. To verify this we have checked that all the responses do indeed use the same terminating data. So now for the rule:

  Capturing my response    


Implementing this rule, you should see that after recording a new script the WebTcpIpRecvExact functions will be replaced with WebTcpIpRecvUntil functions with \r\n as one of the parameters. The special characters in the tag are encoding for the html tags as shown in the conversion table earlier. The is encoding for \r\n.

Moving beyond:

This article will hopefully inspire the reader to want to experiment further with the powers of recording rules, now that we've demonstrated how they can make coding life easier. The chapter "Rule-Based Recording with SilkPerformer" in the Advanced Concepts Book that ships with SilkPerformer goes into much more detail. It also discusses further uses for recording rules, including suppressing url requests, modifying requests, inserting custom function calls in scripts and much more.

We would also recommend that some time is spent consulting the sample rules which ship with SilkPerformer (located in SilkPerformer's Working\Templates\RecordingRules directory).

Of course, if you encounter any difficulties with recording rules, or simply wish to learn more, please contact Technical Support for assistance.

Tags (1)


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2013-02-15 18:48
Updated by:
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.