Best Practices

Read-Only Transactions

A read-only transaction is a transaction in which new records aren't inserted and data is not altered. Recorded scripts for read-only transactions run without modification.

Such scripts may however contain parsing functions for value arrays. Parsing functions may, for example, parse the value array of the third record in a table. If during replay this table contains fewer than 3 records, no value array can be parsed and the result may be replay errors. Such situations can be avoided by adjusting the occurrence parameter of parsing functions so that existing value arrays are parsed.

The better solution however is to ensure that each table in a database contains adequate records during load tests, thereby avoiding the problem altogether.

Read/Write/Update Transactions

A writing transaction is a transaction that inserts new records or changes the values of existing records.

Required Script Customizations

Scripts for writing transactions require only minimal customization to ensure successful replay. This is because value arrays for new records can be parsed from server responses.

When modifications are required for successful replay, it is generally because many tables in Siebel do not allow duplicate records. The circumstances by which Siebel considers records to be duplicates vary between tables. In most instances, a certain combination of record fields must be different for Siebel to consider a record unique.

For successful replay, these fields must be changed, even with Try Script runs. This can be done easily when the Web Recorder creates these values as variables.

For Try Script runs, it is sufficient to manually change these values directly in scripts. For tests however, data files must be prepared and scripts must be customized in such a way that each virtual user inserts records with unique value combinations.

Be Aware of Empty Tables

HTTP traffic generated by the insertion of records into empty tables differs significantly from HTTP traffic generated by inserting records into tables that are already populated with one or more records. For this reason, scripts that record the insertion of records into empty tables can not later be used during replay sessions once tables have been populated - and vice versa.

To avoid such problems, ensure that you do not insert records into empty tables during recording sessions. Also ensure that tables are not emptied before or during load tests.

Note that the following scenarios are not affected by these constraints:

• Creating new records in tables that include other records (for example, accounts).
• Creating new records in a table associated with the records just created (for example, creating new notes for new accounts). While the notes table for newly created accounts is empty, the notes table of newly created accounts during script replay is also empty, so such scripts will not cause problems.