Systems Under Test
Overview
A System Under Test (SUT) is a saved connection to one of the external systems your test cases talk to — an SAP Cloud Integration tenant, an SAP PI/PO host, an SAP ABAP backend, or a generic HTTP service. It stores everything Int4 Cloud needs to reach that system: the URL, how to authenticate, and a handful of runtime tunables such as rate limits and trace settings.
A connection deliberately captures only how to reach one concrete system — its address and credentials — and nothing about which stage of your landscape that system represents. That separation is what lets a single test case be reused widely: tests reference a stage (an environment) rather than a hard-wired address, and the platform looks up the matching connection at run time. The same connection can therefore be shared by many tests and swapped out for a different system without touching any test that uses it.
The reason there are four connection types rather than one is that the systems a test talks to are reached in fundamentally different ways. Two of them are integration middleware that the engine injects messages into and then reads results back from — SAP Cloud Integration and SAP PI/PO. One is an SAP backend used to validate that the right documents were created or changed. The fourth is a generic HTTP target for everything else. Each is spoken to through its own native interface, which is why the connection form re-shapes itself to the parameters and credentials that type needs, and why the type is fixed once chosen.
This page is the central inventory of those connections. From here you can browse every SUT you have permission to see, filter by type or production flag, jump into one to view or edit its details, create a new one, or export the full list to Excel or PDF for sharing.
Each row in the list shows the SUT's name, its purpose, what type of system it points at, whether it is flagged as a production system, and basic audit information. Names and descriptions are stored in plain text; passwords, client secrets, and RFC credentials are kept in the secret manager and never appear on this screen.
Tasks
How to create a new system
- Click Create New in the toolbar above the list. The button is disabled if you do not hold the System Under Test: Write permission in any project scope.
- On the create form, choose the system type first — SAP Cloud Integration, SAP PI/PO, SAP RFC, or HTTP. The form re-shapes itself to the parameters that type needs.
- Fill in the connection details and any credentials, then save.
Field reference
The list shows the following columns. The full set of fields, including connection parameters and credentials, is documented on the system detail page.
| Field | Description |
|---|---|
| Name | Unique identifier for the system. 1–40 characters, letters, digits, and underscores only. Names are reserved across SUTs and user-created SUT groups, so the same name cannot be used for both. |
| Description | Short free-text label (up to 100 characters) describing what the system is used for. |
| Type | The platform the system runs on. One of SAP Cloud Integration, SAP PI/PO, SAP Backend RFC, or HTTP Host. Determines which parameters and credentials are stored. The type is chosen at creation time and cannot be changed afterwards. |
| Production | Shows Yes when the system is flagged as production, No otherwise. The flag is informational on most operations; the one place it changes behaviour today is the SAP PI/PO connection check, which avoids the adapter-framework probe path on production systems. |
| Created By | E-mail of the user who created the system. |
| Created Date | When the system was created, shown as a relative timestamp (for example "3 days ago"). |
Tips & edge cases
- You only see systems you may read. The list is filtered to the project scopes your role grants you read access to. A system that exists but is assigned to a scope outside your role will not appear here. Adjust your scopes via Roles and Permission Groups if you expect to see something that is missing.
- Type is locked after creation. If a system is recreated on a different platform — for example, migrating an SAP PI/PO instance to SAP Cloud Integration — you must delete the old system entry and create a new one. The connection parameters and stored credentials cannot be converted in place.
- Delete is blocked while the system is in use. A system that is referenced by any test case, by a historical test execution, or by a manually created SUT group cannot be deleted. The platform protects the references so audit history stays consistent. Remove or reassign those references first.
- Secrets never appear on this page. Passwords, OAuth client secrets, and RFC passwords are stored in the secret manager (HashiCorp Vault or AWS Secrets Manager, depending on deployment) and are never returned to the browser. The list and the detail page show only the non-secret parts of the configuration.
- Production flag does not add a delete or update confirmation. Treat it as a label, not as a safety interlock. Use roles and scopes to control who can modify production systems.
- What the production flag is really for. Marking a system as production signals that it is a live target that test case cannot be executed.
- A connection is the addressable half; the stage is configured elsewhere. A system stored here records only how to reach one concrete system. Which stage of your landscape it represents, and how it lines up against the same system in other stages, is configured on the System Landscape page by placing the system into an environment and system line. This is the separation that lets you re-point a test at a different stage — for example to replay a captured result against an upgrade target — without editing the test or the connection.
- One connection per system, reused across many tests. Because the address and credentials live on the connection and tests reference it indirectly, you normally keep a single connection per real system and let every test that needs it share that one entry. Avoid creating near-duplicate connections to the same system; it makes the landscape harder to reason about and to retarget cleanly.
Related features
- System Landscape — defines the connection details for each system that you place in matrix cells. — collections of SUTs used in test cases and folder-level configuration. Every SUT is automatically also a single-member group.
Prerequisites & permissions
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.
To use this page you need at minimum System Under Test: Read in at least one project scope; without it the list will always be empty. System Under Test: Write in a project scope is required to enable the Create New button and to open the create form. Updating or deleting an individual system additionally requires write or delete permission on the scope that system is assigned to. The "Test connection" action available on the detail page requires System Under Test: Execute, because it dispatches real network traffic using the stored credentials.