Automation Objects
Overview
An Automation Object is a reusable blueprint that tells Int4 Suite how to drive one specific integration scenario end-to-end: which middleware to talk to, how to send a payload in, where to find the resulting message, what to validate, and how to compare actual versus expected output. Every test case is bound to exactly one automation object — the test case supplies the payloads and the expected data, the automation object supplies everything else.
This split — keeping the configuration in the automation object and the test data in th§e test case — is the heart of how Int4 Suite is meant to be used. Because the automation object holds everything that is shared by an interface or object under test (how to send, what to validate, how to manipulate data), a single automation object is normally reused across many test cases: one for each captured document or message you want to replay. You configure the scenario once, then point as many test cases at it as you need.
The same separation is what lets one test case be retargeted at a different system without rebuilding its automation object. Most validations come down to a single comparison: a reference payload (captured when the test case was created — the "before") against a current payload (produced by this execution — the "after"). Keeping these two sides independent is what makes one automation object equally suited to regression testing (same system, before and after a change), migration testing (the reference comes from the old system, the current from the new one — for example an ECC-to-S/4HANA move), and test-driven development. In every case the comparison logic is identical; only which systems supply "before" and "after" changes.
This page is the central inventory. From here you can browse every automation object you have permission to see, filter the list by type or by free-text search, jump into one to view or edit its details, and start a new automation object. The list is paged and exportable.
Each automation object has a type that pins it to a specific platform and test pattern — for example SAP CI E2E Inbound drives an inbound iFlow on SAP Cloud Integration, SAP PO Unit Test injects messages into an SAP PI/PO landscape, SAP DB Comparator checks database tables on an SAP backend, and Business Object drives a custom scenario you have scripted yourself. The type is locked at creation and the rest of the form re-shapes itself around it; the Type column on the list shows the type at a glance.
Names are short identifiers (1–40 characters, letters / digits / underscore only) and must be unique across all currently-active automation objects. Two existing automation objects with the same name cannot both be the current version at the same time.
Tasks
How to create a new automation object
- Click Create New in the toolbar above the list. The button is disabled if you do not hold the Automation Object: Write permission in any project scope.
- The detail page opens in create mode. Pick a Type first — the rest of the form is determined by that choice (see Types of automation objects below for what each type covers).
- Fill in the name, description, interface details, and the type-specific parameters, then save. The new automation object becomes the current version 1; subsequent edits will produce versions 2, 3, and so on.
The detailed walk-through of the create / edit form lives on the Automation Object detail page documentation; this list page only sends you into the form.
Types of automation objects
The Type decides which integration scenario an automation object can drive. Pick the type that matches what you want to test — once an automation object exists, the type cannot be changed without recreating it.
| Type | Description |
|---|---|
| SAP CI E2E Inbound | Tests a complete inbound iFlow on SAP Cloud Integration by sending a request through the iFlow's sender adapter (HTTP, SOAP, SFTP, …). It then reads the request and response payloads back from the iFlow trace to compare against expectations. |
| SAP CI E2E Outbound | Validates an outbound message produced by a CPI iFlow without injecting anything itself. It watches the CPI message log over a time window, finds the matching outbound message, and compares it against the expected payload. |
| SAP CI Micro Unit Test | Tests a single segment of an iFlow rather than the whole flow. |
| File Comparator | Compares two files against each other offline, with no connected system involved — useful for validating exported data, snapshots, or fixtures. The test case supplies the files; the automation object only supplies the comparison settings. |
| SAP PO Unit Test | Injects a message into an SAP PI/PO landscape and validates every outbound message the platform produces. This is the richest SAP PI/PO type, covering channel control, PIT injection, attachment validation, and message capture. |
| SAP PO Outbound | Validates an outbound message produced by SAP PI/PO without injecting anything. It searches the PI/PO message store within a time window, finds the expected message, and validates it. |
| SAP PO Synchronous | Tests a synchronous request / response on SAP PI/PO: Int4 Suite sends the request and validates the response returned in the same call. |
| SAP DB Comparator | Verifies that database tables on an SAP backend reach the expected state. It snapshots the rows selected by a reusable DB ruleset when the test case is saved, then re-reads and compares those rows when the test runs. |
| Business Object | Drives a bespoke scenario that the built-in types do not cover, via a named bundle of scripted actions defined in the Business Objects area. |
For the three SAP CI types, the detail page can pre-fill the adapter and block parameters straight from the chosen iFlow: after entering the interface name, use the Autofill button, pick the system under test to read from, and the matching parameters are filled in for you to review before saving.
SAP CI E2E Inbound
When to pick this: you want to test a complete inbound iFlow on SAP Cloud Integration. Int4 Suite sends a request through the iFlow's chosen sender adapter (HTTP, SOAP, ProcessDirect, SFTP, IDoc, XI, AMQP, or JMS) and then reads back the request payload and the response payload from the iFlow trace to compare them against expected values.
Key parameters you will be asked for on the detail page:
| Field | What it means |
|---|---|
| Adapter Type | Which CPI sender adapter the iFlow listens on. Pick the one configured on the iFlow itself. |
| Adapter-specific settings | Once you pick an adapter type, an extra block appears for that adapter — HTTP method and CSRF settings for HTTP, SOAP action for SOAP, ProcessDirect endpoint for ProcessDirect, credentials and proxy type for SFTP, Event Mesh host / queue / OAuth2 credential for AMQP, and so on. |
| Input source / output source | Whether Int4 Suite should pick payloads up from a named iFlow block or from a message attachment. Output can additionally be delegated to another automation object. |
| Block / attachment names | The specific iFlow block IDs or attachment names to read from. Leave the output block list empty to let Int4 Suite auto-detect. |
| Validate headers and exchange properties | Whether to compare CPI headers and exchange properties on top of body payloads. |
| Output Automation Object | One or more other automation objects to invoke for reading output payloads — used when the response comes from a downstream step you already have an automation object for. |
| XML comparison, flat-file parameters, file encoding / type | Standard comparison knobs that decide how tolerantly Int4 Suite matches actual versus expected payloads. |
| Externalized parameters, HTTP headers, variable as application ID | Optional iFlow-level overrides applied at execution time. |
| Payload matching | Optional rules for matching multiple messages against one another when one payload produces several outputs. |
Tips:
- Input source = Block requires the block ID; Input source = Attachment requires the attachment name.
- If you set Output source = Output Automation Object, also pick at least one entry in Output Automation Object.
- Header validation is off by default; turn it on when CPI exchange properties or headers carry meaningful business data.
SAP CI E2E Outbound
When to pick this: you want to validate an outbound message produced by a CPI iFlow but you do not want Int4 Suite to inject anything itself. The platform watches the CPI message log over a configurable time window, finds the outbound message that matches, and compares it against the expected payload.
Key parameters on the detail page:
| Field | What it means |
|---|---|
| Payload source + block / attachment name | Where to read the captured outbound payload from once the message is found. |
| Validate headers and exchange properties | Whether to compare CPI headers / exchange properties as well as the body. |
| Message find configuration | Filters and constraints used to identify the right outbound message in the log. |
| Search time threshold (default 60 seconds) | How many seconds before the test run started Int4 Suite should also search — useful when the outbound is generated a moment before the run formally begins. |
| "Search using parent application ID" / "Search using parent correlation ID" | Correlate the outbound message back to a parent inbound via application or correlation ID. |
| XML comparison, flat-file parameters, file encoding / type | Same comparison knobs as inbound. |
| Externalized parameters | Optional iFlow-level overrides applied at execution time. |
Tips:
- This type does not inject anything. If you need to send a request and then check the outbound, combine an inbound automation object (or another sender) with this one inside a single test case.
- Widen the search threshold if the outbound is slow to appear in the CPI log.
SAP CI Micro Unit Test
When to pick this: you want to test only a segment of an iFlow rather than the whole flow. Int4 Suite clones the source iFlow, mutates a temporary copy so it runs only between two designated blocks via ProcessDirect, deploys that copy, runs the test, and removes it afterwards.
Key parameters on the detail page:
| Field | What it means |
|---|---|
| Start block / end block | The two iFlow step IDs that bound the segment under test. Required. |
| Payload source + block / attachment name | Where the input payload is read from. The output payload location is read from a separate block or attachment field. |
| Variable name as application ID | Map the first value of a runtime variable to the SAP ApplicationID. Optional. |
| HTTP Headers | Extra HTTP headers to send when injecting. Optional. |
| Diagnostic mode | Keep the temporary mutated iFlow deployed after the run so you can inspect it. Only takes effect when the test run itself is in Debug Mode. |
| Compare persisted messages | Read the actual output from the Int4Data message store instead of the synchronous HTTP response. |
| XML comparison, flat-file parameters, file encoding / type, payload matching | Same comparison knobs as the other CI types. |
Tips:
- The clone-and-deploy lifecycle adds time per run. Use Micro Unit Tests when you genuinely need to isolate a sub-section; for whole-iFlow regression use the E2E types.
- Diagnostic mode only persists the mutated iFlow during a Debug Mode run. A normal run always cleans up.
File Comparator
When to pick this: you want to compare two files against each other without involving any external system — for example to validate exported data, snapshots, or fixture files as an offline regression check. The test case supplies the two files; the automation object only supplies the comparison settings.
Key parameters on the detail page:
| Field | What it means |
|---|---|
| XML comparison | XML-specific tolerance knobs — namespace tolerance and pairing rules for repeated elements. |
| Flat-file parameters | Line separator and escape character for flat files. |
| File encoding | Override the file encoding when it is not UTF-8. |
| Input file type / Output file type | Force the file type (XML, JSON, flat file, …) of either side; leave blank to auto-detect. |
Tips:
- This is the simplest type — no system under test is needed and nothing is sent anywhere; the run goes straight to comparison.
SAP PO Unit Test
When to pick this: you want to inject a message into an SAP PI/PO landscape and validate every outbound message the platform produces. This is the richest SAP PI/PO type — it covers both how messages are captured at test-case creation time and how they are injected and validated at execution time.
Key parameters on the detail page (most are optional):
| Field | What it means |
|---|---|
| Inject using PIT | Whether to inject via PIT (Process Integration Tools, SAP PO 7.5 SP14 or newer). Can be set to Use global setting, Enabled, or Disabled. |
| Stop receiver processing | Stop receiver processing during a PIT injection. |
| Asynchronous HTTP operation / URL | Direct HTTP injection for asynchronous REST / JSON interfaces — required for those. |
| Reference sender channel name / business component / party | The reference sender channel Int4 Suite should mimic when injecting. |
| Sender uses Virtual Receiver | Toggle if your scenario relies on Virtual Receiver. |
| Output Automation Object | One or more other automation objects to delegate output-payload reading to. |
| Validate output / attachments / status; Ignore receiver validation | Which dimensions of the result to compare. Receiver validation can be turned off if you do not want to compare the receiver name / party. |
| Stop channels | Channels to stop during execution so a test does not trigger unwanted side processing. Each entry pairs SUT, channel, business component, and party. |
| Output filters | Interface and namespace pairs to ignore when creating the test case from a captured message. |
| Test-case creation flags | Ignore / read parent message, read successor by reference ID, allow same sender as receiver, message versions before / after processing. |
| Message selector overrides | Override the interface name or namespace used when looking the message up in the PO message store. |
| XML comparison, flat-file parameters, file encoding / type | Standard comparison knobs. |
Tips:
- PIT injection requires SAP PO 7.5 SP14 or newer. If your landscape is older, leave it disabled.
- Use Stop channels sparingly — it stops live integration during the run; only do this in non-production landscapes.
SAP PO Outbound
When to pick this: you want to validate an outbound message produced by SAP PI/PO without injecting anything. Int4 Suite searches the PI/PO message store within a time window, finds the expected message, and validates it.
Key parameters on the detail page:
| Field | What it means |
|---|---|
| Message find configuration | Filters and matchers used to locate the right outbound message in the PI/PO message store. |
| Search time threshold (default 60 seconds) | Seconds to subtract from the test-run start time when searching, so a slightly-early outbound is still picked up. |
| Validate output / attachments / status; Ignore receiver validation | Same validation dimensions as Unit Test. |
| Stop channels | Channels to stop during execution, same shape as Unit Test. |
| Message-version-after, parent-message flags | Test-case creation flags. |
| Message selector overrides | Override the interface name or namespace for the lookup. |
| XML comparison, flat-file parameters, file encoding | Standard comparison knobs (output side only). |
Tips:
- Like CI E2E Outbound, this type does not inject. Combine it with a sender automation object inside a test case when you need to drive and observe.
SAP PO Synchronous
When to pick this: you want to test a synchronous request / response on SAP PI/PO — Int4 Suite sends the request and validates the response that comes back in the same call.
Key parameters on the detail page:
| Field | What it means |
|---|---|
| Response source | Where to read the expected response from. PO Persistence reads from the PI/PO message store; Response version from request reads from the request itself (default version BI). |
| Message version before / after | PI/PO message version IDs at the source and target boundary. |
| Validate attachments | Compare attachments on top of the body. |
| Message selector overrides | Override the interface name or namespace for the lookup. |
| XML comparison, flat-file parameters, file encoding / type | Standard comparison knobs. |
Tips:
- Response source = Response version from request is the simplest setup and works for most synchronous request/response patterns.
SAP DB Comparator
When to pick this: you want to verify that database tables on an SAP backend end up in the expected state. When the test case is saved, Int4 Suite takes a snapshot of the table rows selected by a reusable DB ruleset; when the test runs, it reads the same rows again and compares the current state against the snapshot.
Key parameters on the detail page:
| Field | What it means |
|---|---|
| Ruleset | The DB Validation ruleset that selects which tables and rows to snapshot and re-check. Pick it from the DB Rulesets list. Effectively mandatory — without it the test case cannot capture a snapshot or run. |
| XML comparison | Tolerance knobs applied when comparing the snapshots (the snapshot is stored as XML). |
| File encoding | Override the snapshot encoding if needed. |
Tips:
- This type does not inject anything — it only reads. To test "run a process, then check the database", combine it with a sending automation object inside the same test case.
- The ruleset is linked by name. Renaming or deleting the ruleset breaks every automation object that references it, so coordinate ruleset renames carefully.
- Message search and payload preview are not available for this type — the expected data comes from the snapshot, not from a message log.
- Requires the database-validation licence feature.
Business Object
When to pick this: you want to test a bespoke scenario that the built-in SAP platform types do not cover. A Business Object is a named bundle of scripted actions (listing documents, preparing input, executing, reading reference and result outputs) with its own declared parameters, maintained separately in the Business Objects area. This automation object type points at one Business Object and drives its actions during test-case creation and execution.
Key parameters on the detail page:
| Field | What it means |
|---|---|
| Business Object | The Business Object to drive. Pick it from the Business Objects list. Effectively mandatory — without it the automation object cannot be used. |
| Business Object Parameter Values | Static values this automation object supplies for the Business Object's declared parameters (text, yes/no, or date). Parameters marked as dynamic are not entered here — you fill those in on the message-selection screen each time you create a test case. |
| XML comparison, flat-file parameters, file encoding / type | Standard comparison knobs, same as the other types. |
Tips:
- This type is not tied to a single system under test. The systems to talk to are resolved at run time from the active SUT Group, per action — so a test case of this type can only run when a SUT Group is selected; otherwise the run is blocked with a clear message before it starts.
- Like the DB ruleset above, the Business Object is linked by name — renaming or deleting it breaks the automation objects that reference it.
- Requires the business-objects licence feature.
Field reference
Variant-specific fields are documented under the matching type in Types of automation objects above. The list page itself shows only this shared subset of fields:
| Field | Description |
|---|---|
| Automation Obj. | The short identifier of the automation object. 1–40 characters, letters / digits / underscore only. Unique across all currently-active automation objects — two active objects cannot share a name. |
| Description | A free-text description of what this automation object is for. Up to 200 characters. |
| Type | The automation object type — see Types of automation objects for what each one tests. Locked once the object is created. |
| Interface | The interface name this automation object targets. Free-text business metadata; up to 120 characters. Shown in the list to make it easy to recognise objects that talk to the same interface. |
| Version | The current version number. Each save creates a new version; older versions remain visible from the detail page. |
Tips & edge cases
- The name must be unique across active automation objects. Saving with a name that already exists returns a clear error. Names of historical versions do not count — only currently-active objects collide.
- The type is effectively permanent. Although the system technically accepts a type change on update, the parameters from one type are not valid for another, so the save will fail. If you need a different type, create a new automation object and delete the old one once nothing references it.
- Delete is blocked by test cases. If one or more test cases still reference an automation object, deleting it returns a 409 conflict that lists up to five offending test case IDs (with a "…" marker if there are more). Remove or repoint those test cases first.
- Copy may quietly drop the project scope. If you copy an automation object out of a project scope where you do not have Automation Object: Write, the copy is created without a project scope — it is unscoped rather than rejected. Watch the destination on the detail page after copying.
- License gates apply at creation and at copy. Every type is tied to a licensed feature — SAP CI testing, SAP PI/PO testing, file comparison, database validation, or business objects. If your licence does not cover the chosen type's feature, the create / copy is rejected. Existing automation objects of an unlicensed type remain visible but cannot be copied.
- DB rulesets and Business Objects are linked by name, not by identity. A SAP DB Comparator references its ruleset by name, and a Business Object automation object references its Business Object by name. Renaming or deleting the referenced item silently breaks the automation object — it will only fail when a test case is saved or run. Both fields can also be left empty at save time, so an incomplete automation object only surfaces as an error later; fill them in straight away.
- Versioning is automatic. Every save creates a new version; the previous current version becomes historical. You can revert to any historical version from the detail page — reverting also creates a new version rather than rewriting history.
- Value-help endpoints are broad on purpose. Pickers that show automation objects (for example when picking an "output automation object") return a relaxed result set so typeaheads stay responsive — the project-scope filter is applied when you actually open the object's detail page, not in the picker itself.
- Header IDs vs version IDs. The list shows one row per header (the persistent identity). The version number column shows which version is currently active. Internal links and integrations should always refer to header IDs, not version IDs, unless you specifically need a snapshot.
- Why some types send and others only observe. Int4 Suite validates by capturing and replaying messages the platform has already processed, so it relies on the integration platform keeping those messages around — CPI trace and attachment retention, or SAP PI/PO staging and logging. Inbound and unit types inject a payload and then poll for the result; outbound and database-comparator types never send anything — they locate a message or row the platform already produced and compare it. That is why the outbound types ask for message-finding and correlation settings rather than adapter settings. If the platform under test is not configured to retain its messages, there is simply nothing to capture, and these tests will find nothing to compare.
- One automation object, many test cases. Because the automation object is the reusable configuration, the normal pattern is to build one per interface or object under test and attach many test cases to it — one for each captured document. Editing the automation object changes how every test case bound to it runs, so treat it as shared configuration: a tweak to comparison tolerance or validation scope affects all of them at once.
Related features
- Automation Object detail and edit page — covers the create / edit form, the parameter forms per type, the versions section, copy and delete dialogs, and the version-restore flow.
- Systems Under Test — the connection profiles that automation objects target at execution time.
- Test Cases — every test case picks exactly one automation object and supplies the payloads and expected data.
- DB Rulesets — the reusable table-selection rules referenced by SAP DB Comparator automation objects.
- Business Objects — the scripted action bundles referenced by Business Object automation objects, including SUT Groups for late system resolution.
Prerequisites & permissions
You need the Automation Object: Read permission in at least one project scope to open this list. The full set of activities used on this page and the detail page that follows:
- Read — required to open the list and any detail page.
- Write — required to enable the Create New button and to edit, copy, or revert an existing automation object.
- Delete — required to remove an automation object (and only takes effect if no test case still references it).
In addition, creating or copying an automation object requires the licence feature matching its type's platform — see the licence row of the capability table in Types of automation objects.
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.