Document Header Rules

Most sites don't require special documentation for headers. VUGen will record them as specified in the Recording Options. The appropriate dialog box illustrated on the right is accessed by navigating in VUGen as follows: Recording Options / HTTP Advanced / Headers

However, sometimes VUGen still doesn't record them. For example, when recording a SAP Fiori script using Chrome, some don't get recorded and need to be added manually. To add them to the script manually can be tedious. For a guideline, follow this link: Add header manually.

As well as providing a mechanism for documenting Header rules, DoxRunner saves a scripter's time by using those documented rules to instrument a raw script using the Process Raw operation.

The illustration below the one on the right shows how they are configured in a DoxRunner document.

The rules are contained in a Headers section of either a test case or the Solution document.

The important components are the Name and the Value, as described below.

Name

The Name should conform to that used by VUGen for any of the header functions.

Name

Value

The Value can be any text relevant to the Header Name.

Value

Overview

SectionManagement

Section Management

Section Management - Header Rules

Common Characteristics

A Header Rule section is optional, is semi-structured, and may appear in three places:

Any Test Case;
The Solution document;
The Test Case Template document.

Each instance of the Header Rule section consists of:

a Section Title;
a Bookmark;
free-form Body Text;
a Table with a minimum of two columns (Name and Value).

The Bookmark:

Mandatory;
Location: Immediately before the Section Title;
Structure: Depends on which document it is embedded in:
- Test Case: P_TC879_Headers (where TC879 is the Test Case ID)
- Test Case Template: P_Headers
- Solution document: V_Headers

The Section Title:

Mandatory;
Location: immediately after the Bookmark;
Structure: Free-format text;
Style: I_Heading n or I_Appendix n, where n can be an integer from 1 to 5;
Length: Cannot be longer than 200 characters.

The Body Text

Optional;
Location: between the Section Title and the Table;
Structure: free-format text;
Style: I_BodyText;
Length: Cannot be longer than 1,000 characters.

The Table:

Mandatory;
Location: immediately below the Body Text (or Section Title if there is no Body Text):
A minimum of two rows:
- A Heading row and a Data row (one data row per rule);
- If there are no rules, the last Data row can contain empty cells (or the section can be deleted);
A minimum of two columns:
- A Name column and a Value column;
- More columns can be added;
- A Description column is recommended.
All cells in the Name and Value columns must conform to specific rules, as described in the Overview above.

Advice

TestCaseSection

Advice

Assess whether the section is necessary. This decision will need to take into consideration two factors:

Whether you have the problem where VUGen doesn't recognize some Headers;
Whether an individual Test Case has the header problem;
Which scenario you have chosen when assessing the relationship between Test Case sections and Solution document sections.

Assess the Section Title and update it if necessary.

Make sure the table has the two mandatory columns (Name and Value), each with the specified heading text.

Assess the table to see whether more columns are appropriate, especially a Description column.

Assess the Body Text between the Section Title and the Table and update it if necessary.

Make sure its bookmark is visible and located immediately before the first character of the Section Title (see each of the examples further down this page).

Do not change the bookmark.

The section looks better when on a page with portrait orientation.

Test Case Section

In a Test Case, the Headers section is optional and can be located anywhere between the Description sections and the Transaction Timer section.

It is semi-structured as described above.

If you know that a test case won't require Header rules, you may decide to delete the section. This can be done in two ways:

Using the DoxRunner Manage Sections operation;
Manually.

If you deleted the section from the test case and decide to re-add it, then it can be done in two ways also:

Using the DoxRunner Manage Sections operation;
Manually.

If the Solution document also contains a Headers section with Name that is the same as one in a test case, then the one in the Test Case takes precedence.

The illustration below shows a typical Header Rules section as it appears in a Test Case. Note the following points:

The Bookmark must be structured as shown in the previous section:
- That is, "P_", followed by the Test Case ID, followed by "_Headers";
- For example, if the is TC35, then the bookmark should be P_TC35_Headers;
The symbol is an optional link to the top of the Test Case for easier navigation.

Example

TemplateSection

Test Case Template Section

The Text Data File section is optional and can be located anywhere in the Test Case Template between the Description sections and the Transaction Timer section.

It is semi-structured. The structure is described above.

It must be referenced by a Bookmark that must be located immediately before the Section Title.

The Bookmark is structured as follows: P_Headers

The Body Text is expected to contain generic text that will be copied to any new Test Case then updated by the scripter.

The Table must have a minimum of two rows - a Heading row and a Data row - and two columns as shown below.

It is recommended that you leave the table empty and populate it only after it's incorporated into a Test Case. If the Data row contains a rule, then that rule is copied to any new test case.

Example

Solution Document Section

The Headers section is optional and can be located anywhere in the Solution document.

Header rules are normally defined in the Headers section of a test case, however they can also be documented in the Solution document. This is optional. One is included in the original downloaded version of the Solution document and is available unless it was manually deleted after the document was downloaded.

There is only one way to add rules to the Headers section of a Solution document and that is to manually insert them into the table.

If it exists, the section it is semi-structured. The structure is described above and is identical to the Test Case.

It must be referenced by a Bookmark that must be located immediately before the Section Title.

The Bookmark is structured as follows: V_Headers

Why would you use the Solution document to document Header rules? You don't need to, but if there are rules that are common across multiple test cases, then they may be easier to manage if placed in the Solution document instead. In fact, to take an extreme view, you can document -all- Header rules in the Solution document and define -none- in the Test Cases, if that is easier to manage. The choice is yours.

If a rule in a Data row of the Table contains a rule that is the same as one in a test case then the one in the Test Case takes precedence.

SolutionSection

Example

AddRule

Add a Header rule

All Header rules are documented as a row in the table that is embedded in a Headers section, which must exist beforehand.

They can be added to a Test Case in two ways:

Manually add a row in the table that should exist in the appropriate Headers section;
Via the Reverse Engineer operation from a legacy script.

It can only be added to the Solution document or the Test Case Template manually.

Rules are not normally present in the Test Case Template, but can be in the rare case where a rule is known to be needed in all (or most) new test cases.

Advice

Make sure bookmarks are visible;
Assess the Header rule and decide whether you will ever need it;
If you believe that it is relevant in the Solution document:
- Manually add it to the Solution document;
- Type in a heading that is appropriate to the solution - see the illustration below for the standard heading;
- Make sure the bookmark V_Heading is placed in front of the heading;
- Type in generic body text that you expect to apply to most test cases - you will most likely tailor it in the test case that is created from the template;
- Add rules that are common to several test cases;
- The section looks better when on a page with portrait orientation.

Add a Header rule manually

This can be done in a test case, the Solution document, and the Test Case Template. Make sure the Headers section exists. It should exist unless you have deleted it.

Adding a rule manually is simply a matter of adding a row to the table and typing in the details, making sure there is one row per parameter as illustrated below. Only the Name and Value columns are used by the Process Raw operation.

Extra columns can be added, but are ignored by the Process Raw operation. A Description column is optional but recommended.

Refer to the Overview above for details of each column.

AddManually

Add using the Reverse Engineer Operation

The Reverse Engineer operation is designed to update the documentation for a test case from a legacy script.

xxx rules are included in this process, however it's possible that not all rules are captured and documented.

Make sure you check the test case once the Reverse Engineer operation has completed.

AddViaReverseEngineer

DeleteRule

Delete a Rule

Except for the last rule, deleting one can only be done manually in all documents by simply deleting the respective row in the table.

Deleting the last rule can be done in two ways:

Simply clear all cells in the row (do not delete the row);
Delete the entire section.

A rule cannot be deleted using DoxRunner or via the green Parameter Association screen.

HowToIdentifyMissingHeader

How to identify a missing header

Once you have identified those headers that VUGen has missed, you need to identify which requests they are to apply to.

To see them, open the Snapshot tab at the bottom of VUGen (with the script open of course), configured as the Recording. Place the cursor in each request and see whether the header is in the request portion of the Snapshot tab – if so, add that header to the script just prior to the request.

For example, the first one would be configured as:

· web_add_header("MaxDataServiceVersion", "3.0");

In this case the Value would be documented as "3.0".

The second one would need to be correlated. Assuming you correlate it into parameter pCSRFToken_t212, it would look like this:

· web_add_header("X-CSRF-Token", "{pCSRFToken_t212}");