USE:
During full SAP end-to-end testing of an application interface, the final document that Int4 IFTT created in the SAP backend will be checked against the reference document stored during test cases creation. From the technical point of view, the validation is performed by comparing the selected database tables and table fields of both documents: the reference and the new one created during the test case execution. We make a business document’s database model representation and choose the tables, relations, and fields we want to be compared to achieve this. Optionally we can configure rules for matching original and new document lines and join conditions in more complex object models.
The rules are configured per configuration object. However, it is possible to reuse the rules by another object without replicating the same configuration. To achieve that, the second object must refer to the first one by header field - reference object ID. In such a case, the second object needs to have variables with the same names as they are used by DB comparison rules.
PROCEDURE:
- Database comparison rules are created per configuration object. Select the particular object by marking the row and double click on the Database Comparison Rules node in the navigation tree.
- Enter step numbers & database table names in which SAP business document is stored
The tables are processed in sequence based on Step number. Each step has following parameters:
| Parameter name | Description |
|---|---|
| Step | A consecutive number of the step. Suppose the tested object consists of multiple tables. In that case, each step will refer to a separate table (e.g., header table and lines table) and have a different number. |
| Table Name | Name of a database table validated in the step |
| Parent Step | Usually, records from the table of step 1 are selected by values from the tested message passed by Variables The underlying tables, like document items, are determined based on keys fetched from the main table. The step number of the main table is passed to the underlying tables. Please see the example for a better understanding |
| Number of rows | Optional field that will allow limiting the number of fetched records from each table. It is like 'UP TO n ROWS' in the SELECT statement. |
| Buffer Records | If checked, then expected results are stored in a buffer after the first execution of a test case and used later on to compare with the actual results. If unchecked, then the expected results are removed from the buffer (if stored previously). |
EXAMPLE:
Example configuration of Sales order header and items, schedule lines etc.:
| Step | Table | Parent Step |
|---|---|---|
| 1 | VBAK | |
| 2 | VBPA | 1 |
| 3 | VBAP | 1 |
| 4 | VBEP | 3 |
When records for reference and the newly created document will be fetched from the VBAK table (Sales Order Header) by variables, the entries from table VBPA (Partners) will be fetched based on the key field (VBELN) of the selected VBAK entry.
Then entries from VBAP will be fetched again based on the key field of the selected VBAK entry (VBELN field).
Finally, the entries from VBEP (schedule lines) will be fetched based on keys of records fetched for the VBAP table (VBELN and POSNR).
See Selection Criteria subchapter to see how this selection works in detail.