Skip to main content

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 business processes that move data into and out of SAP systems across SAP integration middleware — SAP Cloud Integration and SAP PI/PO — event brokers such as SAP Event Mesh, SAP Advanced Event Mesh and Solace PubSub+, the SAP backends (via RFC) and generic HTTP APIs.

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.

ConceptWhat it is
Automation objectReusable, 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 caseThe 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 testA connection configuration (URLs, credentials, tunables) for an external system Int4 Suite tests against.
FolderThe hierarchical tree that organises test cases and propagates project scope and the system-group assignment down to the tests inside it.
Test runOne session that executes a selection of test cases and records the outcome of each, including the comparison results and logs.
ProcessAn ordered chain of test cases that follows one business document end to end — for example sales order, delivery, invoice — drawn as a map of steps and run as one test.

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.

Single test cases combine into process tests that follow one business document across several interfaces, so you test the business process rather than each interface on its own. See Process tests.

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 (including Trading Partner Management) or SAP PI/PO, or documents through business objects, over a chosen time window and auto-create test cases in a target folder, on demand or on a schedule.
  • Complete the chain suggests the test cases that continue a process, looking up the follow-on documents in the SAP system.
  • The API Explorer lets you build and send API requests by hand and promote a request you are happy with to a test case.
  • 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.
  • Business dimensions 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.

A performance report measures processing times across repeated runs, and test case analysis lets you explore large test sets by their business values before you run them.

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.
  • Business dimensions form a catalogue of business values — order, material or customer numbers — that are read from payloads and power analysis, process suggestions and test data changes.
  • The data store keeps values that scripts write and read across runs; mapping objects translate values, such as plant or company codes, between the system groups of your landscape.
  • Content packages import and export ready-made content, such as a business dimension catalogue.
  • Global parameters hold tenant-wide settings, including the AI provider configuration.

Messenger​

Messenger stands in for partner systems that are missing from your test landscape. It answers the messages your integrations send to that partner the way the real system would, so end-to-end tests run without waiting for every connected system. See Virtualization objects.

Access, security, and licensing​

  • Sign-in is handled through Keycloak (username and password, or single sign-on) or, on SAP BTP, through the SAP Authorization and Trust Management service.
  • 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:

Was this page helpful?Send a quick note to the documentation team.
0 / 2000 characters