Int4 Suite at a Glance
New to Int4 Suite? Start here. This page explains what the product does, the handful of concepts everything is built from, and where to go next in this guide.
What Int4 Suite is
Int4 Suite is an enterprise platform for testing SAP integrations and SAP S/4HANA APIs. It validates the interfaces and end-to-end flows that move data into and out of SAP systems across SAP integration middleware — SAP Cloud Integration and SAP PI/PO — as well as the SAP backends (via RFC) and generic HTTP systems.
Rather than re-keying data by hand or building one-off test harnesses, Int4 Suite works by capturing real messages that a platform has already processed, replaying them, and comparing the result against a saved reference. Because it injects at the interface boundary and reads back through the platform's own APIs, it can test integrations without needing direct access to the external systems on the other side.
The core idea: capture, replay, compare
Almost everything in the product comes back to one duality: a reference result captured when a test was created (the "before") versus the current result produced when the test runs (the "after"). The comparison is always current-against-reference, and that single mechanism covers the main testing scenarios:
- Regression — the same system over time: did anything change that shouldn't have?
- Migration — reference captured from the old system (e.g. ECC, or SAP PI/PO), current produced by the new one (e.g. S/4HANA, or SAP Cloud Integration).
- Shift-left / test-driven development — re-point the same test at a different environment to validate work earlier.
Because the engine reads and replays historical messages, it depends on the integration platform having kept those messages (CPI trace retention, PI/PO staging). Where there is no retained message, there is nothing to capture and nothing to compare — which is why message retention and trace management matter throughout the product.
The building blocks
A small set of main objects explains how everything fits together. The product's signature design is the separation of test configuration from test data: the configuration is defined once and reused across many tests.
| Concept | What it is |
|---|---|
| Automation object | Reusable, versioned configuration that pins one integration scenario to a platform type (SAP CI, SAP PI/PO, SAP backend, file, business object) and decides how a test is prepared, sent, retrieved, and compared. Reused by many test cases. |
| Test case | The unit of test data for one execution: it references an automation object and carries the input and expected-output payloads captured as the reference. |
| System under test | A connection configuration (URLs, credentials, tunables) for an external system Int4 Suite tests against. |
| Folder | The hierarchical tree that organises test cases and propagates project scope and the system-group assignment down to the tests inside it. |
| Test run | One session that executes a selection of test cases and records the outcome of each, including the comparison results and logs. |
What you can test
A test case's behaviour depends on the test type of its automation object. These fall into three families:
- Inbound / unit tests — Int4 sends, then checks the result. A reference input is injected into the platform; once it has processed, Int4 captures what an internal step, attachment, or follow-on message produced and compares it to the expected output. Examples: SAP CI E2E Inbound, SAP CI Micro Unit Test, SAP PO Unit Test, SAP PO Synchronous, and Business Object tests.
- Outbound tests — Int4 reads a message the platform already produced. Nothing is injected; the run locates a message that has already left the platform (correlated to a parent message) and compares it to the expected payload. Examples: SAP CI E2E Outbound, SAP PO Outbound.
- Database comparison tests — Int4 snapshots table state and re-checks it. No message is involved: a snapshot of the rows selected by a DB ruleset is taken when the test case is created, then re-queried and compared at run time. Example: SAP DB Comparator.
Creating tests — by hand or automatically
You rarely build every test case manually. Int4 Suite provides several ways to create and enrich them:
- Crawlers discover messages on SAP Cloud Integration or SAP PI/PO over a chosen time window and auto-create test cases in a target folder, on demand or on a schedule.
- Trace schedulers keep SAP Cloud Integration iFlow traces switched on for the iFlows you care about, so messages are retained and remain capturable.
- The test case loader bulk-imports test cases from a ZIP archive, pairing request and response payloads automatically.
- Variables dynamize test data through a no-code block pipeline — extracting values from messages, generating new ones, and patching them into payloads (for example stamping a fresh, unique document number from a reusable global sequence).
- Scripts (Int4 Aster, plus XSLT, XPath, and Regex) provide reusable transformations and custom validations that test cases and automation objects can call.
Running tests and reading results
Test runs can be launched on demand, replayed from a previous run, or fired on a recurring schedule. Runs can repeat a selection many times for performance/load testing. A run aggregates the execution of every test case it covers, streams its progress live, and only passes when all of its test cases pass.
Each comparison can be viewed in several presentations (raw, formatted, a flat-file text diff, or a table where supported), payload differences can be tuned with ignore rules, and any custom validation scripts run alongside the regular comparison. Every run keeps a user-facing log stream and its full result history, which you can export.
Configuration and landscape
The artefacts test cases depend on are managed under configuration:
- Systems under test and the system landscape — connections are organised into named groups (such as DEV / QA / PROD) and pivoted across the landscape, so a single test case can be retargeted at a different environment at run time. Value mappings (SAP PO) are maintained per environment for use during comparison.
- DB rulesets define which SAP backend tables, columns, filters, and joins a database-comparison test reads.
- Business objects are customer-defined, versioned bundles of scripted, connector-driven actions used by the Business Object test type for bespoke scenarios.
- Global parameters hold tenant-wide settings, including the AI provider configuration.
Access, security, and licensing
- Sign-in is handled through Keycloak, with username/password and OIDC single sign-on.
- What you can see and do is governed by roles and permission groups assigned to your user, each granting Read / Write / Delete / Execute on a resource, optionally narrowed to a project scope. This is covered in detail in the shared permissions note that appears on most pages.
- Features and limits are enabled by a signed, customer-specific license file.
AI assistant
Int4 Suite includes an in-app conversational assistant and an external MCP server that let you drive test-automation workflows in natural language, backed by a configurable LLM provider set in global parameters.
Where to go next
This guide is organised to mirror the in-app navigation. Once you understand the concepts above, jump to the area you need:
- Test Cases — design and organise tests: the cockpit, the all-test-cases list, crawlers, trace schedulers, and the loader.
- Test Runs — execute and inspect: all test runs and scheduled runs.
- Configuration — set up the artefacts tests reference: automation objects, systems under test, system landscape, DB rulesets, business objects, and more.
- IAM — manage access: users, roles, permission groups, project scopes, and licenses.