System Landscape Options

You need to consider which landscape fits best to your change control processes. The processes are critical for organizations that require the delivery of regular software updates (via major or minor releases) while simultaneously providing a secure and stable production environment for end users – especially in a scenario for SAP customers that run development initiatives (innovation) and operation support (maintenance) in parallel.

This lesson provides an overview of the main system landscape options that are available together with their pros and cons. It starts with the basic three-system landscape and then moves forward to more complex scenarios.

A three-system-landscape consists of a development system (DEV), a quality assurance system (QAS), and a productive system (PRD).

• The development system DEV is needed to implement changes.

• The quality assurance system QAS is needed to perform functional tests and integration tests with production-like data. QAS is also needed to test the import of the transport requests. Without a quality assurance system, the import of transports cannot be tested before it is executed in production.

The following figure recaps the transport process in a three-system-landscape with a consolidation route (indicated by a green arrow in the following figures) between the development system and the quality assurance system and a delivery route (indicated by a black arrow in the following figures) between the quality assurance system and the production system:

1. In the first step, the first transport request (TR1) is released. As a consequence, development objects that are locked are released and the transport request is added to the import queue of the quality assurance system.

   Note

   The import queue has two functions. The first function is to contain all transport requests that have been released, and the second is to remember the sequence in which the transport requests have been released.

   Next the second transport request (TR2) is released as well.

2. In the second step, the transport requests contained in the QAS import queue are imported into the quality assurance system. System QAS is used for first tests with production-like data.

   The transport requests that are imported into the QAS system are also added to the import queue of the productive system PRD. This guarantees that the transport requests and their import sequence to the quality assurance system QAS are remembered. When you use the Import Project or the Import ALL strategy, the transport requests are also deleted from the import queue of the quality assurance system.

3. In the third step, the transport requests listed in the import buffer of the productive system are imported into production. When you use the Import Project or the Import ALL strategy, the transport requests are also deleted from the import queue of the production system.

Using the Single Transport strategy in a three-system landscape leads to the following issues and risks:

• Transport requests are imported in an individual sequence
• Risk of forgotten transports
• Risk of version downgrades by transport sequence violations

These risks are discussed in more detail in the following sections.

Transport request TR1 contains a report, ZREPORT, which calls the function module, ZMODULE which has also been created in transport request TR1. This transport request is released in the development system (step 1 in the figure above). Then transport request TR2 changes the report ZREPORT but leaves the function module ZMODULE untouched. TR2 is then released as well (step 2).

In QAS, TR1 and TR2 are imported one after the other (steps 3,4) and then tested together. The test is OK.

However, when now only TR2 is imported into PRD (step 5), the generation of ZREPORT fails, because TR1 was forgotten and function module ZMODULE therefore does not exist in PRD and cannot be called.

If then TR1 (without TR2) is also imported into PRD (step 6), the test in PRD fails again because now the old version of ZREPORT (version of TR1) has overwritten the newer version (version of TR2).

The following figure explains some reasons for these inconsistencies in a more general way:

The development system DEV contains all developments (both open developments and developments that have been recorded in released transport requests). The quality assurance system QAS contains transports that have already been imported into PRD, and also transports that have not been imported yet into PRD (labelled as "transports in transition" in the figure above) .Therefore, all three systems are on different software levels.

Objects that have been changed in a project that is currently in transition (either in open transport requests or in already released transport requests) cannot be maintained anymore during bug-fixing.

As soon as a change to a repository object is performed in the development system, this repository object is locked in the transport request (see the left part of the figure above). The lock is deleted when the transport request is released from the development system.

You can compare the object versions in DEV and PRD before starting a maintenance task. If the versions are different, then you have to temporarily switch back an old object version from the version history in the development system. This object version is corrected and transported to production. In the next step, the correction is made again with the latest object version.

The procedure to maintain two different versions of one object via versions, and to transport these versions through the system landscape is error-prone. Alternatively, the developer can search for objects in transition with transaction SREPO which – however – requires an RFC destination between the SAP system that you want to compare the production system with and the production system itself.

The right part of the figure above shows the reasons for cross reference errors. Here the transport request for object 2 has already been released in the development system and therefore the lock has already been deleted – object 2 belongs to a transport in transition.

In this example, object 1 was not changed by the project. But object 1 uses object 2, and – as stated above – object 2 was changed (from version 1 to version 2).

Initially, object 1 worked, but now object 1 has to be corrected. The new version of object 1 still works with the new version of object 2, but the new version of object 1 does not work with the old version of object 2 and this is only detected in PRD.

The system landscape topology, which can be used to detect cross-reference inconsistencies is a pre-production system. It is the (optional) SAP system for the final integration test once the scope of the release has been fixed (release test). This fourth – pre-production – system is brought between the QAS and the PRD. If this pre-production system has the current software and configuration state of production, a cross-reference error can already be detected during tests in pre-production.

Assume an SAP ECC system landscape on an old release serving one or several countries. The major development cycle and the rollout are complete. Ongoing changes are limited to Support Packages, operating and database patches. SAP configuration changes are required to support minor business requirements.

In this case, a three-system-landscape might be sufficient: The maintenance transports are bundled into packages, so that they can be tested together.

This scenario works well if the number of urgent corrections is low. Non-urgent corrections should be released later so that QAS stays close to PRD for the test of urgent corrections.

In this scenario, all changes are created in the development system DEV (maybe after prototyping in the sandbox system SBX).

The QAS system is used as a testing environment for integration testing and data conversion testing. This system partially contains the changes from the new release that currently is in development. The QAS system is the environment for the final integration test (once the scope of the release has been fixed – release test), regression test and technical system test. It should represent the status in the PRD systems in the following way:

• Infrastructure: the setup of the QAS system should mimic PRD as closely as possible and it should be a full copy of the production system. This is the prerequisite for realistic volume tests.

• Transports: The QAS system must not be "corrupted" with new release functionality or new maintenance packages until the appropriate time (ideally as close to go-live as possible).

• Data: The QAS system should be regularly refreshed from PRD, if possible.

This landscape is the best practice landscape for solutions with production support and development projects of a minimum scope (even in parallel releases).

Recommendations to make best use of this landscape:

• Strict change management for production support and project development, and/or same development team for both types of changes.

• A strong change control should be in place (strict control of what changes move when into QAS, refresh of QAS, …).

In times of invasive changes (for example, during implementation of Support Packages), it might be useful to introduce a fourth system to support the maintenance of the production system.

• All changes are created in the development system DEV. Any invasive changes, such as Support Packages, are tested in the sandbox system SBX before they are implemented in DEV.

• The QAS system is used as a testing environment for integration testing and data conversion testing. This system partially contains the changes from the new release that currently is in development.

• The pre-production system PRE is the environment for the final integration test (once the scope of the release has been fixed – release test), regression test, user acceptance test and technical system test. It should represent the status in the PRD systems with respect to:

  • Infrastructure: the setup of the PRE system should mimic PRD as closely as possible and it should be a full copy of the production system. This is the prerequisite for realistic volume tests.

  • Transports: The PRE system must not be "corrupted" with new release functionality or new maintenance packages until the appropriate time (ideally as close to go-live as possible).

  • Data: The PRE system should be regularly refreshed from PRD, if possible.

During the implementation of Support Packages (or other minor releases), in DEV only urgent changes, standard changes and smaller non-invasive functional enhancements are developed. Here, PRE is required, for example, for testing of urgent changes during the time periods while the Support Package org the minor release is "blocking" QAS.

It is important to move the Support Packages fast through the landscape in order to limit the time period of inconsistent releases in the landscape. A reduction of the transition time for the Support Packages can be achieved by thorough testing in SBX, by a clear definition of the test scope (reflecting the changes of the concrete Support Package), by test automation and by ensured availability of test resources

The required system sizes are as follows:

• The DEV and the QAS system may be of small data volume, no high availability setup, small CPU and small RAM.

• The PRE system may have the full data volume, a reduced high availability setup, and reduced CPU and RAM.

• The PRD system of course should have full data volume, a full high availability setup, as well as full CPU and RAM.

The four-system landscape with the pre-production system is the best practice landscape for solutions with production support and development projects of a medium scope (even in parallel releases) – as it allows for a staged testing. Recommendations to make best use of this landscape are :

• Strict change management for production support and project development, and/or same development team for both types of changes.

• A strong change control should be in place (strict control of what changes move when into PRE, refresh of PRE, …).

In the scenario of the figure above, QAS is the main functional test system. All functional tests (integration tests, user acceptance tests, regression tests) take place in QAS. As a consequence, only one release can be tested in QAS (for the next go-live). Future releases can already be developed and tested in DEV.

The validation system VAL serves as a technical and functional validation system for the following purposes:

• Test of emergency changes when the next release is already sitting in QAS

• Technical cutover tests and import time predictions, in particular for upgrades or big release imports

• Technical validation of the release bundle if certain transports must be taken out of the release (last minute scope changes), for example if they do not meet the test criteria

The technical validation can comprise the analysis of RC8 during the import and an extended syntax check (ATC) of the imported code. The functional validation can comprise a number of automated test scripts for the core processes and some manual spot checks as needed.

In addition, the VAL system allows a better release management, as multiple projects can be validated together allowing a common go-live.

Another variant of the four-system landscape is shown in the following figure. Here, functional tests are not restricted to the second system of the system landscape but takes place in both the second and the third system:

In this scenario, functional tests take place in TST and QAS. So interfaces and appropriate test data must be provided for both systems. This is sometimes a problem when the SAP solution is heavily integrated with legacy systems which have only one test tier.

Typically early integration tests are done by the implementation teams and vendors in TST. Final integration tests, user acceptance tests and regression tests are done in QAS in the final preparation phase of a release.

This landscape allows to test for future releases in TST, even though they are not yet assigned to the next upcoming release. The transport bundle for the next release must be assembled only before the final preparation phase starts.

This landscape works best with the Transport of Copies mechanism which – for example – is used in SAP Solution Manager Change Request Management.

In this option, QAS partly takes over the role of the technical cutover system VAL from the variant above. However there are some restrictions:

• Transports are already imported into QAS, before the transport bundle is finalized.

• Emergency transports cannot be tested in a clean environment while the release is tested in QAS.

• Repeated dress rehearsals and cutover optimizations are not possible.