Products, Product Systems, Product Instances, Technical Systems, and Landscape Patterns in the SAP Solution Manager
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
In general there is still a lot of confusion around SAP product naming, versioning and concepts. Blogs and information like this are very much welcome to help get rid of the confusion.
I do think SAP could go further than this to help remove confusion. One idea would be to have an easy way to identify the technology and product SPS level for example.
It would be useful that one could see a simple overview in Solution Manager and directly know for each managed SAP system which SPS level the technology platform has (Netweaver for example) and which SPS level the product has (ERP for example). Since the introduction of SPS (vs SP) and enhancement packages people got confused about all the different component versions they see.
Kind regards
Tom
We wanted to do an upgrade from NW 7.01 to NW 7.3 - it tooks us five (!) weeks with the primary and development support to figure, how the system, product instance etc. has to be set up in SMSY in order to get the proper upgrade configuration and files.
If even the support is confused about the settings despite the target being very clear and even a note for that is existing, how should a customer be able to do that (alone)?
Landscape Verification just adds another tool/AddOn with a more or less own data base which needs to be maintained and patched.
I just wonder where this all will end?
To be honest, SMSY and MOPZ made my life MUCH more difficult (and slower) than before.
--
Markus
Seems it is important to engage SAP support early to clean up the system asap to be able to plan updates/upgrades properly.
I have an a new phenomenon:
CRM 7.0 was upgraded to EHP1
--> MOPZ said "system was upgraded to EHP1"
--> switch SMSY to "CRM 7.0/NW 701"
--> switched logical component to EHP1
--> MOPZ says "no standalone product version used"
--> switching main product version to CRM 7.0
--> switching logical component to CRM 7.0
--> MOPZ says "system was upgraded to EHP1"
(LV says "green" to everything)
---> giving up
---> time taken: almost 2 hours and a few dozen notes read
Selected each component manually in SMP and addd to download basket, confirmed basket manually.
--> time taken: less than 10 minutes
I don't create any more OSS calls for those kinds of issues, doing screenshots and writing explanations what I click where and what I expect to happen takes additional time which I usually don't have. The energy and time needed to get it implemented is way more than what it is actually supposed to help me (for this system).
--
Markus
You're done now, but for future reference I think I know what needs to happen for your CRM 7.0/NW 701 "standalone product version" issue. I went through that hell, too, with our ERP 604/NW 701 system. It turns out that, if you are using Enhancement Packs, the "Main Product Version" needs to be the NON-enhancement pack version; i.e., ERP 6.0 in my case, CRM 7.0 in yours, and then the Enhancement Pack version is listed as an "Add-On Product Version".
So, in my ERP example, for my Product System "D02" I have a Product Version of "SAP ERP 6.0". In the Header Data I have both "SAP ERP 6.0" and "EHP4 FOR SAP ERP 6.0 / NW7.01" listed as Active Product Versions. In the "System Data in SAP Support Portal" the Product Version is "SAP ERP 6.0", the "Add-On Product Versions" lists "EHP4 FOR SAP ERP 6.0 / NW7.01", and the Usage Type is "ERP Central Component (ECC)" (this implies that I have manually set up the system data in OSS this way).
Now here is where it gets a bit weird. After doing this, my "D02" Product System shows up twice in the product systems list, once under "SAP ERP", and again under "SAP ERP ENHANCE PACKAGE". This feels inconsistent to me, but it seems to work. The Product Instances between the two are NOT the same, however. In the "SAP ERP" system the "Relevant" ABAP Product Instance is "SAP ECC Server", and then the associated Portal is listed as a technical system against Product Instances "Portal Content", "SAP NW - EP Core", and "SAP XSS (Self Services)". For the other "D02" Product System, however, the one under SAP ERP ENHANCE PACKAGE, the "Relevant" ABAP Product Instance is "Central Applications", with "Human Capital Management" and "Public Sector Accounting" selected as "Also Installed", and the Portal selected as Technical System for "Portal Content", "Portal Content Common", "Portal Content Self Services", and "SAP XSS (Self Services)".
As I mentioned previously the Portal Technical System has the Landscape Attribute of "Sidecar". It's also listed as its own Product System, but I'm not sure whether this is necessary or not. Otherwise it's not used in any other Product System, so Sidecar is probably appropriate.
This appears to be working. MOPZ is finally calculating the stacks and packages that I expect it to. I'm pretty sure my EarlyWatch Alert landscape is all screwed up now by these changes, but I'll attend to that later.
Anyway, should you wish to try again (and I know that you don't), selecting "CRM 7.0" as the main product version, and "CRM 7.0 / NW 7.01" as an AddOn, would probably solve the issue.
Or you could just add the components manually.
thank you for the comments and the followup.
> "Anyway, should you wish to try again (and I know that you don't), selecting "CRM 7.0" as the main product version, and "CRM 7.0 / NW 7.01" as an AddOn, would probably solve the issue."
I can't select both. If I select "CRM 7.0/NW 7.01" the CRM 7.0 entry gets replaced by that automatically and I get yellow exclamation mark, it's either - or, not both.
* I can't select CRM 7.0 (and EHP1 for CRM) because MOPZ says, that CRM 7.0 was upgraded.
* I can't select CRM 7.0 /NW 7.01 and EHP1 for CRM because CRM 7.0/NW701 is no product instance
* I can't select EHP1 for CRM 7.0 only because that is no product instance
* I can't select CRM 7.02 because MOPZ says, that SLD has CRM 7.0 (which is wrong).
As said, I was trying two hours all kinds of combinations, LV was always "green", no matter what kind of product instance I chose in what combination with a logical component.
This may be a bug, a feature, a mess, an LMDB-refesh problem, a caching issue of ICM, the browser or simply a silly myself.
> "This appears to be working."
And this is enough for you to satisfy yourself and it's ok for you to have to configure and try days to get it to work? I don't have that time...
> "I'm pretty sure my EarlyWatch Alert landscape is all screwed up now by these changes, but I'll attend to that later."
Just for curiosity: Are you really ok with that fact - if it was so? Or do you enjoy playing with SolMan? Not judgemental here, just trying to figure whether this is the way I should/shall handle that piece of software?
I would REALLY love to use it and make use of it but the fact, that every time I have to use it, it causes trouble. I have a business to run, that's my main task, not fixing/(re-)configuring Solution Manager/SMSY/MOPZ. Am I so mistaken with my opinion that I don't consent keeping myself busy with fixing the "tool" instead of "doing my work"?
--
Markus