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 the systems making up that stage (for example, an SAP Cloud Integration tenant, an SAP PO host, an 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. The same system may fill as many cells as you need, in one row or across rows.

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

Until you add something, the page shows No System Landscape Configured with two buttons, Group and System Line. If you start with a group, the first group automatically creates one column for every supported system type, so the grid becomes usable immediately. If you start with a system line instead, no columns are created for you.

1. Select Group in the centre of the empty page.
2. Enter a Name (1–40 characters: letters, digits, ., - and _, starting with a letter or digit). 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 (1–40 characters: letters, digits, ., - and _, starting with a letter or digit) 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. Its header shows the name, the description and the system type.

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 +) 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. Press Escape or click elsewhere to close it without a change.
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 changed cells are highlighted. Closing or reloading the browser tab prompts a confirmation; moving to another page inside the application does not, and the unsaved edits are lost.

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. In the filled cell, select the small × button next to the system name (screen readers announce it as "Clear").
2. The cell is now empty and highlighted as changed.
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.

A group that is still in use cannot be deleted: test cases, test runs, scheduled runs, crawlers, folders, mapping objects and Messenger objects can all point at a group. The deletion then fails with a message that the object is still referenced by other records. Point those records at another group first.

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). As with groups, a system line that test cases, crawlers, business objects or Messenger objects still use cannot be deleted.

Field reference

Group (row)

Field	Description
Name	Display name of the environment. Must be unique among all groups regardless of case, 1–40 characters: letters, digits, ., - and _, starting with a letter or digit. 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 system line (for example, ECC, S4HANA, CI_Tenants). 1–40 characters: letters, digits, ., - and _, starting with a letter or digit; unique regardless of case.
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, named after the type (for example SAP_CI) with the type's display name as description; rename them to match your landscape. 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 cell is blocked. If a system is placed in a cell of this matrix, clear those cells (or delete the group) before deleting the system on the Systems Under Test page. The error appears there, not on this page.
• Groups and system lines in use cannot be deleted. Test cases, test runs, scheduled runs, crawlers, folders, business objects, mapping objects and Messenger objects refer to groups or system lines. The confirmation dialog does not check this; the deletion fails afterwards with a message that the object is still referenced.
• 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.
• A row may hold several systems of one type, one per system line. An environment that spans two backends of the same kind — for example ECC and S/4HANA, both reached over RFC — puts each in its own column. Test cases in such a row need a System Line so the platform knows which column to use; without one they fail at run time with a message naming the candidates. See "Choosing between systems of the same type" below.
• An environment is a complete stage, not just one system. A row is meant to hold the systems 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 system is a live production target is a setting on the system itself, not on the environment. Set it there: connection checks then never send test messages to it, and Business Object execution actions and Messenger refuse to send to 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.
• Messenger uses the same matrix. A Messenger virtualization object is pointed at one group, and its flows address systems by system line name — the cell where that row and column meet decides which system receives the message. Switching the object to another group retargets it, just like a test case.
• 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.

Choosing between systems of the same type

A single row can contain more than one system of the same type, and a single system can appear in more than one column. Both are normal in real landscapes:

• One SAP Cloud Integration development tenant shared by several regional system lines. Here the extra columns all point at the same tenant, so nothing is ambiguous and no extra setting is needed.
• Two different backends of the same kind in one environment, such as ECC and S/4HANA during a migration, or ERP and CRM side by side. Here the platform cannot tell which one a test case means.

For the second case, a test case carries an optional System Line. It names the column to use, and the environment row still decides the stage. You can set it in several places:

Where	When it is used
Test case detail screen, under System Environments	Any time, on an existing or new test case
Message selector, when pulling test data	Offered only when the system you selected appears in more than one column
Crawler configuration	Applied to every test case that crawler creates
Test case loader	Applied to every test case loaded from the archive

If you leave it empty, the platform fills it in for you whenever the answer is unambiguous: once the source system is known, it is stored automatically at creation and again whenever payloads are re-fetched. It stays empty when the system genuinely sits in several columns, which is exactly when you should choose one yourself. Only system lines matching the automation object's system type are offered, and you can clear the field at any time.

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. What you can see and do is decided by the roles assigned to your user. Each role bundles permission groups, and each permission group allows activities — Read, Write, Delete, Execute and, for schedules, Change owner — on a kind of record (for example Test Case, Automation Object, System Under Test). A role grants its groups per project scope, so you may be allowed to change records in one project but only view, or not see, those of another.

If a button is disabled, a page says you don't have access, or a list comes back empty, missing permissions are the most likely cause — or, for whole product areas, the installed licence. You can review your own access under Profile → My access; an administrator can change your roles under IAM → Users.

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