DB Rulesets
Overview
A DB Ruleset is a reusable recipe that describes which rows to read from an SAP backend database. Each ruleset is a tree of steps; every step names one SAP table, the columns to return, the filter conditions that select the rows, and optional sorting, de-duplication, and inner joins. Child steps read related tables driven by values from their parent's rows, so a single ruleset can capture a whole document graph — for example a header, its items, and their sub-items.
The point of a DB Ruleset is to let a test check the business outcome of an integration, not just the message that crossed the wire. After a document has been processed in the SAP backend, the message may have arrived correctly but still have produced the wrong document; database validation closes that gap. A ruleset is a model of a business document's database footprint — the tables that hold it, the parent-to-child relations between them (header to items to sub-items), and the fields that matter — so that when a test runs, the platform can read back the rows the document actually created and compare them, field by field, against the reference captured when the test case was built. The step tree mirrors how the document itself is structured: a top-level step reads the header, and each child step reads a related table keyed by values from its parent's rows. The sorting and de-duplication options line records up so that two reads of "the same" document compare cleanly even when the database returns them in a different order.
Rulesets are configuration only. A ruleset on its own does not read anything; it is consumed by a database-comparison automation object when a test case runs. At that point the named ruleset is executed against the test's SAP system, and the rows it returns become the payload that the comparison snapshots and checks for differences.
This page is the central list of all DB Rulesets. From here you can search for a ruleset, open one to view or edit it, and start a new one. Each ruleset keeps a full version history: editing a ruleset never overwrites the previous content — it creates a new version, and you can restore an earlier version at any time.
Tasks
How to create a new ruleset
- Choose Create New in the toolbar.
- Fill in the ruleset details and build its step tree on the page that opens, then save.
If the Create New button is greyed out, you do not have permission to create rulesets (see Prerequisites & permissions).
How to export the list
- Choose Export in the toolbar to download the current list. You can export to Excel or PDF.
Field reference
These are the columns shown for each ruleset in the list.
| Field | Description |
|---|---|
| Name | The ruleset's name — the identifier you use to find it and the value an automation object references to run it. Names are unique among the live (current) rulesets. Select the name to open the ruleset. |
| Description | A free-text label describing what the ruleset reads. |
| Version | The current version number. Every time a ruleset is edited a new version is created, so this number tells you how many times the ruleset has changed. |
Tips & edge cases
- A ruleset never reads anything by itself. The actual database read happens only when a database-comparison automation object runs the ruleset inside a test case against an SAP RFC system. There is no "run" action on the ruleset itself.
- One ruleset, two testing intents. The same ruleset serves both regression and migration: in regression the reference and current rows come from one system; in migration the reference comes from the legacy system and the current from the new one. You do not build a separate "migration" ruleset — you point the test's reference and current systems at the two landscapes, and the ruleset reads each one the same way. This is what makes a ruleset worth maintaining as a shared, reusable asset rather than per-test configuration.
- Model the document the way it is structured. Build the step tree to follow the document's own shape — header at the top, items as its children, sub-items below those — and add sorting or de-duplication where the database might return rows in an inconsistent order. A ruleset that mirrors the real parent/child relations keeps the comparison meaningful: each child step reads only the rows belonging to the specific parent document for this test run, not every row in the table.
Related features
Prerequisites & permissions
You need the DB Ruleset: Read permission to see this list and open a ruleset, and the DB Ruleset: Write permission to create, copy, edit, or restore one. Deleting a ruleset requires the DB Ruleset: Delete permission. Where a ruleset is assigned a project scope, your permission must cover that scope. There is intentionally no "execute" permission on rulesets — running a ruleset is controlled by the permissions on the automation object and test case that use it.
About permissions. Int4 Suite controls what you can see and do through roles and permission groups assigned to your user. Each role grants permissions on a specific resource (for example, Test Case, Automation Object, System Under Test) at one of four levels: Read, Write, Delete, or Execute. Some permissions are further narrowed by project scope, so you may have access to one part of the system but not another.
If a button is disabled or a list comes back empty, missing permissions are the most likely cause. Ask an administrator to review your role assignments, or check IAM → Users if you have the User: Read permission.