Introduction
Products and Product Instances are used to describe software that SAP delivers. It’s also these entities that you need to understand to maintain your systems. In the 2nd part of my blog on landscape descriptions, we’ll talk about these entities in some detail. In doing so, we’ll have to introduce two new concepts to our simplified description given in part I, namely the reuse, versioning, and nesting of elements. These two things are important, because they define what you have to do manually when managing your systems.
Products, Their Elements, and the Complexity You Need to Handle
In the 1st part of this landscape description blog series (see Additional Info), Products were explained with an analogy to a car. Once the roles of the entities Product, Product Instance, and Software Components are understood on this very high level, we can go into some details. Even if more similarities with cars could be found here also, we’ll be more abstract from now on.
While Products, Software Components, and Product Instances basics can be explained with a simple analogy, the assignment to Product Systems needs to be done carefully – the reason why is that we are dealing with Products in different versions, and their parts having dependencies caused by reuse, which has big advantages (obviously less versions of objects overall), but leads to some complexity by means of nesting and versioning, which turns up both in Product definitions and the Product Systems used to run Products in the landscape.
Products
Products are applications that you buy and run to fulfill your business needs.
- Products often are installed across several technical systems, for example to avoid dual stack installations
- Product Instances are made of Software Components, which are – again – can be reused in different Product Instances
- Product Instances contain other Product instances in two ways, which have to be handled differently, as explicit includes or implicit includes
Product Systems
A Product System is a group of one to several Technical Systems used to install a Product Version.
- Technical Systems can be reused in more than one Product Systems
- Assignment of Technical Systems to Product Systems is done on a Product Instance level. Therefore, in one Technical System, you will find Product Instances of several Product Versions, but you may assign only those Product Instances to a Product System, which belong to this one Product:
Figure 1: Product Versions A and J installed with some overlap on two Technical Systems ABP and JAP and being handled in two Product Systems ABP and JVP
Here’s the situation in figure 1 explained:
- A hypothetical Product A in the current version is AS ABAP and AS Java based. Product A
- Has Product Instances A1, A2 (AS ABAP-based), and A3 (AS Java-based).
- It also includes a Product Instance PI J1
- Product Instances of Product A are installed on AS ABAP based Technical System ABP and AS Java based Technical System JAP.
- Product J in the current version is AS Java based and has
- Product Instances J1, and J2.
- PIs J1 and J2 are installed on AS Java based Technical System JAP next to PI A3.
The including of Product Instances can be done explicitly or implicitly. Details are explained later.
How to Deal with Product Systems
Even, if Product Instances of several Product Versions are installed on the same Technical System, in maintenance you address one Product Version you want to maintain.
Example: SAP ERP 6.0 shall get SAPEHP 4, so underlying SAP NetWeaver 7.0 needs to get EHP1.
Therefore, the assignment of Technical Systems and Product Instances to Product Systems needs to be correct. This will help you to achieve this:
- Do Product Version assignment first.
- You will then in a Product System see only those Product Instances that can belong to the Product Version that has been assigned to that Product System in the SAP Solution Manager, so choose the Product Version carefully.
Versioning
Products, as we learned, are made of Product Instances. A Product is somewhat abstract, for example. In real life you’ll always deal with a Product Version. Therefore, it’s needed and sufficient to choose the right product version. Also, even if in one Product System more than one Product can be handled, in one Product System only one version of each Product can exist.
Special Case of Versioning
SAP enhancement packages (EHPs😞 EHPs define functions that can be added to an existing Product Version. Therefore, when installing an EHP, you need to have both, the Standalone Product Version (for example SAP ERP 6.0) and the EHP version (for example SAP EHP 4 for SAP ERP😞 So in that case, both of them need to be marked as installed in the SAP Solution Manager. This is true for EHPs for SAP ERP, SAP CRM, SAP SRM, and SAP SCM.
Nesting
As said before, Product Instances can contain other Product Instances – they can do so explicitly or implicitly. Implicit containing you find for Product Instances of one Product,
Implicitly Contained Product Instances and How to Deal with Them
Figure 2: Product A contains Product Instances A, B, C, D, and contains PI 1 /2 of Product B implicitly.
Example of “implicitly contained Product Instances”:
Product Instance A belonging to SAP ERP 6.0 reusing Product Instance B of SAP NetWeaver 7.0 (AS ABAP and AS Java)
That means that:
- If the Product Instance containing other Product Instances implicitly is run together with the contained Product Instances on the same Technical System, you need to assign the containing Product Instance only.
- If the Product Instance containing other Product Instances implicitly and the contained Product Instances are installed on different Technical Systems, you need to assign all Product Instance separately to the Product System.
Explicitly Contained Product Instances and How to Deal with Them
Figure 3: Product Instance X contains Product Instances O, P, and Q; PI Q contains PIs R, L, M explicitly.
Example of “explicitly included Product Instances”:
Product Instance X belonging to Product SAP ERP 6.0; PI X = ECC Server reusing
Product Instance Y belonging to Product SAP NetWeaver 7.0, PI Y = AS ABAP
In any case, when dealing with explicitly contained Product Instances, you need not assign the explicitly contained Product Instance. The reason is, that explicit containment is found, where a Product Instance from a different Product is used. The dependency is such that they need to run on the same Technical System. An example for explicitly contained Product Instances you find in SAP CRM making use of Product Instance SAP NetWeaver AS ABAP.
Special Case of Nesting
Functionally Equivalent Instances (FEIs) are Product Instances, which have been modified without changing their function (often to deal with an update of lower layers in your system) – for more information see Data Adjustment in SMSY after a Upgrade of an SAP NetWeaver Hub System.
Next Steps in Understanding Landscape Descriptions
I hope this will help clarify things. In the next blog you will get some more concrete insights into the tools and processes you have to use to manage the landscape description of your company.
Additional Information
- You’ll find the blog series and links to tools and application dealing with them on a dedicated page called Landscape Descriptions.
- Part I of this blog series Understanding Landscape Descriptions - Part I: the Simple Approach to Explaining Products, Product I...
- Blog on Products, Product Systems, Product Instances, Technical Systems, and Landscape Patterns in the SAP S...
1 Comment
