System Landscape

Overview

The System Landscape is the single place where you organise the systems you test against into named environments and pivot them by system type. Think of it as a grid:

• Each row is a Group — an environment such as DEV, QA, or PROD that bundles together one system of each type (for example, one SAP Cloud Integration tenant, one SAP PO host, one HTTP endpoint).
• Each column is a System Line — a vertical slice across environments for a single system type (for example, "all SAP CI tenants you use", regardless of environment).
• Each cell points at the concrete system that lives at that intersection.

Configuring the landscape this way lets you reuse the same test case against multiple environments: a test case targets a group (a row), and the platform picks the correct system from the cells at run time. The matrix is also the foundation for SAP PO value-mapping tables — they re-anchor system names, communication parties, and interface names between environments based on the same grid.

The reason the landscape is modelled as a grid rather than a flat list of systems is that it decouples which stage a test runs against from the test itself. An environment is a named stage of your landscape — Development, Test, Production are the usual three — that bundles together one system of each type making up that stage. A system line is the other axis: the same kind of system tracked across all your stages, so the "QA backend" and the "Production backend" sit in the same column and can be lined up. Because every test case points at a group rather than a hard-wired system, you can re-point an entire test at a different stage just by choosing another row. That single capability is what powers the three main testing patterns: regression testing (run repeatedly against the same stage to catch unintended changes), migration testing (capture a reference result in one stage and replay it against the next, for example an upgrade target, to prove the behaviour is unchanged), and shift-left / test-driven development (build and run tests against an early stage long before production). None of these require editing the test — only changing which environment it resolves to.

A practical consequence worth planning for: parallel landscapes (for example, two versions of the same middleware running side by side during an upgrade) need their own environments. You typically end up with one set of stages per landscape — Dev, Test, Prod for the old line and another Dev, Test, Prod for the new — so that a test can be retargeted cleanly from one to the other.

The matrix shows only environments you have created yourself. Single-system "auto-groups" that the platform manages internally for each system are not listed here; they are kept in step with the underlying system automatically and are not editable from this page.

Tasks

How to add your first environment

The page starts empty until you add your first Group. The first group you create automatically seeds one column for every supported system type, so the grid becomes usable immediately.

1. Select Group in the centre of the empty page.
2. Enter a Name (up to 40 characters; letters, digits, and underscores). Use names that match how your team talks about environments — Development, Test, Production, and so on.
3. Optionally enter a Description (up to 100 characters) to remind colleagues what this environment contains.
4. Select Create. The button stays unavailable until the name is filled in.

The matrix now shows your group as a row, with one empty column for each supported system type.

How to add an environment (group)

1. From the matrix, select the Group button in the top-left corner cell (the diagonally split cell).
2. Fill in Name and optionally Description.
3. Select Create.

The new group appears as the bottom-most row.

How to add a system line (column)

A System Line is pinned to a single system type — once created, its type cannot be changed.

1. From the matrix, select the System Line button in the top-left corner cell.
2. Enter a Name (up to 40 characters) and optionally a Description.
3. Choose a System Type from the drop-down. Only systems of this type can be placed in cells of this column. This choice is only offered while creating — the field does not appear when you edit the system line later.
4. Select Create. The button stays unavailable until both the name and the system type are filled in.

The new column appears on the right.

How to assign a system to a cell

Cells are where the matrix actually does its job: each filled cell binds one specific system to the (environment, system line) intersection.

1. Select an empty cell (showing (unlocalised: the "+" placeholder glyph — Add to i18n)) or any existing filled cell.
2. A picker opens. Start typing to filter; only systems whose type matches the column's System Type are listed.
3. Choose the system you want.
4. Repeat for as many cells as you need.
5. When you are finished, select Save Matrix in the top-right toolbar.

While you have unsaved edits, the toolbar shows a counter (for example, "3 unsaved change(s)") and dirty cells are highlighted. Closing the browser tab or navigating away prompts a confirmation.

How to change which system a cell points to

1. Select the cell.
2. Pick a different system from the drop-down picker.
3. Select Save Matrix.

How to clear a cell

1. Hover or focus the filled cell so the small clear button ((unlocalised: "x" icon, aria-label "Clear" — Add to i18n)) appears next to the system name.
2. Select the clear button.
3. Select Save Matrix to commit the change.

A cleared cell removes the link between that environment and that system line — the system itself is not deleted.

How to discard pending edits

If you have made changes you do not want to keep, select Discard Changes in the toolbar. All pending cell edits are reverted; saved entries are not affected.

How to rename or describe a group or system line

1. In the row header (for a group) or column header (for a system line), select the Edit action.
2. Update the Name and Description fields. These are the only two fields offered when editing.
3. Select Save. The button stays unavailable until you have changed something and the name is valid.

You cannot change a system line's system type after creation — the System Type field is not shown in the edit dialog at all. Create a new line of the correct type if you need a different one.

How to reorder rows or columns

The order in the matrix is purely visual but is preserved across users.

• To move a row: in the row header, use Move up or Move down.
• To move a column: in the column header, use Move left or Move right.

Reordering is saved immediately — you do not need to press Save Matrix.

How to delete a group

Deleting a group removes the row and all of its cell assignments.

1. In the row header, select the Delete action.
2. Read the confirmation message ("Delete group … This will remove all SUT assignments in this row.") and confirm with Delete.

The underlying systems themselves are not affected — only their membership in this group is removed. Any SAP PO value-mapping rows that referenced this group are also removed.

How to delete a system line

1. In the column header, select the Delete action.
2. Confirm with Delete.

Deleting a column removes all assignments in that column and any SAP PO value-mapping rows anchored to it (system conversions, communication-party mappings, and so on).

Field reference

Group (row)

Field	Description
Name	Display name of the environment. Must be unique among all groups, 1–40 characters, letters / digits / underscores only. Cannot collide with an existing system name.
Description	Optional free-text note shown under the group name in the row header. Up to 100 characters.

System line (column)

Field	Description
Name	Display name of the vertical slice (for example, ECC, S4HANA, CI Tenants). 1–40 characters.
Description	Optional free-text note. Up to 100 characters.
System Type	The single system type that every cell in this column must point to. Chosen once, when the column is created; the field is not offered when editing an existing column.

Cell

Field	Description
System reference	The concrete system that this (group, system line) cell points at. Only systems whose type matches the column's System Type are selectable. A cell can be empty, which means "this environment does not include a system of this type."

Tips & edge cases

• The first group seeds the columns. The first time you add a group to an empty matrix, one column is created for every supported system type. After that, columns must be created manually. Emptying the matrix and starting over does not re-seed.
• System type must match the column. A column is pinned to one system type. Trying to place a system of another type into a cell of that column is rejected — the picker filters them out, and the server enforces the same rule when saving.
• Cell edits are batched. Cell changes are not saved until you press Save Matrix. If saving fails, the whole batch is rejected and no cells are updated — fix the offending cell(s) and try again.
• Reorder, create, update, and delete actions save immediately. Only cell assignments are batched.
• Auto-groups are hidden here. Every system you create is wrapped in an internal "auto-group" that mirrors its name. These never appear in this matrix and are never editable from this page — manage them by editing the underlying system.
• Deleting a system that is still in a group is blocked. If a system is referenced by a cell in this matrix, you must first clear those cells (or delete the group) before the system can be deleted from the Systems page. The error you see when this happens comes from the system delete action, not from this page.
• Groups are not project-scoped. Anyone who can edit the landscape can edit the entire matrix; there is no per-project visibility on groups, system lines, or cells today.
• Same-type duplicates inside one row are a configuration error. The picker normally prevents this (one cell per column, each column is typed), but legacy or imported data could leave two systems of the same type in the same group. If that happens, test cases that resolve to that group will fail with "ambiguous SUT" — fix the matrix by clearing one of the duplicate cells.
• An environment is a complete stage, not just one system. A row is meant to hold one system of each type that together make up that stage of your landscape — for example a middleware host, a backend, and an HTTP endpoint that all belong to "QA". When you retarget a test at that environment, the platform resolves every system the test needs from that single row, so it pays to keep each environment internally consistent (all its cells point at systems that genuinely belong together).
• Mark production stages on the system, not the row. Whether a given system is treated as a live production target is a safety setting carried on the system itself, not on the environment. Set it there so that connection checks and execution approach a production system more conservatively and test traffic is kept away from systems that should never receive it. Keeping your production stage in its own clearly named environment row makes it easy to see at a glance which row is the live one.
• Lining up systems across stages is what enables retargeting. Each column should track the same logical system across your stages — the development, test, and production instances of one backend, for example. When they are lined up in a single column, a test captured against one stage can be replayed against another in the same column, which is the basis for regression, migration, and shift-left testing. If a column mixes unrelated systems, retargeting a test through it will not behave as expected.

Related features

• Systems Under Test — defines the connection details for each system that you place in matrix cells.
• SAP PO value mappings — system-conversion, exclusion, interface-name, and communication-party tables anchored to groups and columns from this matrix.
• Test cases — consume groups via their source and execution selections to resolve which concrete system to talk to at run time.

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 the System Under Test permission. The platform reuses the same permission for groups, system lines, and matrix cells — there is no separate "System Landscape" permission.

Action	Required activity
View the matrix	System Under Test: Read
Create, rename, or reorder a group or system line	System Under Test: Write
Assign or clear cells	System Under Test: Write
Delete a group or system line	System Under Test: Delete

Was this page helpful?Send a quick note to the documentation team.

0 / 2000 characters