Introduction
SAP System landscapes are made of systems running software. However, to manage the landscape, you need to know the entities involved in more detail. Let’s start with a very short glossary of terms I’m going to use in this blog:
- A Product is an application solving business requirements provided by SAP; products have parameters such as their name starting with “SAP” (SAP ERP or SAP CRM, for example), a maintenance period, etc. Products are developed and distributed in packages called Software Components.
- Product Instances bundle software components that have dependencies at runtime and therefore need to run on the same Technical System. One example is SAP ECC. Product Instances are required when you calculated system updates or upgrades using the Maintenance Optimizer (MOpz). One Software Component can be part of several Product Instances; one Product Instance can contain other Product Instances. (This is important to know when describing a Product System in Transaction SMSY)
- A Technical System is a piece of SAP software installed on some hardware, one server or server and database separated on different hosts.
- Product Systems are Technical Systems running one product or part of a product.
- Landscape Pattern: The way, products are distributed on technical systems.
Product Systems
Product systems describe what technical systems (on the level of their product instances) have been used to install a product version, and, therefore, need to be maintained together. Here are a few examples, how product systems can be modeled.
Product Version Assignment
A product system describes the installation of one product version. Therefore, the product version of the installed software needs to be assigned to the product system. You need to differentiate between standalone product versions and add-on product versions:
- Each product system MUST have a standalone product version. Examples for product version assignment to product systems:
- SAP ERP 6.0
- SAP EHP1 for SAP NetWeaver 7.3
- A product system CAN have one or more add-on product versions in addition to the mandatory standalone product version. Examples:
- SAP ERP 6.0 and SAP EHP 6 for SAP ERP 6.0
Note, that EHPs for SAP NetWeaver are standalone product versions, while SAP EHPs for the SAP Business Suite are add-on product versions.
The Simplest Case
In the simplest case, just one technical system with all its product instances is used to in the product system.
Figure 1: Here in two examples, each product system contains just one technial system.
Product Systems with more than One Technical System but without Reuse - Landscape Pattern "Sidecar"
In a little more complex scenario, two technical systems are connected in one product systems. Again, all product instances belong to this product system. An example would be an SAP ERP 6.0 system also using a NetWeaver Portal - the portal is acting like a sidecar, it will always go with the update of the ERP system:
Figure 2: A Product system comprising two technical systems, each one only used in this context, the JAP (non-ABAP) has landscape pattern sidecar.
Reusing Technical Systems in Several Business Processes and Related Product Systems - Landscape Pattern "Hub"
In many cases, implementing business processes involves more than one technical system. This helps separating stacks from each other and eases their reuse in more than one process, making it a hub for users accessing data.
But if the steps of the business processes are tightly integrated, there will often be dependencies between Technical Systems involved, which are to be taken into account during an upgrade.
An example of such a scenario is an HR application of SAP ERP running on an AS ABAP-based backend system and a separate SAP NetWeaver Portal system providing the Employee Self Services. Additionally, the Portal system could also be reused by an SAP CRM system. The reuse in two product systems makes it a hub system, when it comes to describe its role in the landscape (called the landscape pattern 'hub"😞
Figure 3: SAP NetWeaver Portal Hub used by SAP ERP HR and SAP CRM, EEP (SAP NetWeaver Portal) has landscape pattern hub.
In Figure 3 you see the example described above. Product Systems are made of Product Instances, which are installed on Technical Systems.
There are dependencies both from the ERP and the CRM system to the Portal system. Therefore, to be able the maintain the products ERP HR and CRM, which contain not only the Product Instances on their ABAP back-end technical system but also some running on the Technical System of the NetWeaver Portal, the Product Systems of ERP HR and CRM both make use of the Portal system, which is therefore called a “Hub” when it comes to the question of the Landscape Pattern. (By the way: A technical system based on AS Java that is used in a Product System together with an AS ABAB based system is called a “Sidecar”.)
Note: For AS ABAP-based systems Landscape Pattern selection is not required since there can only be one APBA based system in a product system.
What Product Instances to select in SMSY for the Product Systems?
To be able to maintain, update, and upgrade systems, you need to select Products, Product Versions, and Product Instances in the SAP Solution Manager System Landscape (SMSY):
Figure 4: Product Instances in the SLD. Product Instance ECC Sever containing other PIs.
As figure 4 shows, some Product Instances such as SAP ECC Server contains other Product Instances (such as the one of E-Recruiting). In that case only the containing one (ECC) is to be selected.
Why Use Landscape Patterns?
Now, what does it mean for the upgrade? We have in our example two ABAP-based backend systems related to the Java-based Hub system. In case of a application-driven update – in our example the update of the ERP system to enhancement SAP enhancement package 5 to benefit from improved functions – might cause the upgrade of one or the other systems (SAP CRM) also using the same Hub (SAP NetWeaver 7.0 with the usage type Enterprise Portal. To avoid unnecessary cascading of upgrade processes though the landscape (via shared dependencies to Hub systems), the Maintenance Optimizer (MOpz) calculates the “minimum impact” case, where Hubs are only updated if necessary.
For detailedexamples see http://sapinsider.wispubs.com/article.cfm?id=5446 (SAP customers only).
In case of a technology driven update, you would therefore need a product system dedicated to the Enterprise Portal system, directly. This would be used then to upgrade the Portal explicitly.
Additional Information
- System Landscape Directory @ SDN: System Landscape Directory
7 Comments
