Database Comparison Rules

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.

During S/4 HANA migration projects there might be a requirement to compare data which is no longer available in the same tables of the target system e.g. due to data model simplifications.

For example status fields of Sales document which was stored in tables VBUK and VBUP in S/4 HANA is moved to VBAK/VBAP, LIKP/LIPS.

Most of the time there is a compatibility view which allows to query the old tables also in S/4 HANA system.

In case the compatibility view has different name you can maintain the mapping in /INT4/IMG > Landscape configuration > Table replacement configuration.

In the example above VBUK data can be compared by maintaining compatibility view V_VBUK_CDS.