Last update: 25th of July 2019
This blog is meant to summarize discussions I have had with dozens of customers and colleagues. While all the answers are written down and updated in the SLD Planning Guide, it might be useful to start with a short blog to get the big picture first and then check the much more comprehensive guide for details and exceptions.
There are three things that define your SLD strategy: Some general things like the separation of development and production, the SAP applications you use and the way SLD systems exchange information.
SLD topology describes the required number and area of installation of SLD systems in IT landscapes and the connections between them. This is derived from the landscape itself - providing landscape data by systems' self-registration via SLD Data Suppliers.
Note: In addition to the SLD Data Suppliers being part of the technical system itself, as of SAP Solution Manager 7.2, SPS06 the SLD can be a target for agent data - see SAP Note 2556432 - Switch Outside Discovery from Diagnostics Agent to SAP Host Agent
Many applications rely on SLD data. Among these are - most prominently - SAP NetWeaver Process Integration (PI), Web Dynpro for Java, and the SAP Solution Manager. Reasons to have more than one SLD system are manifold:
Therefore, there is only one scenario where one SLD would be enough: This you find in landscapes where of all client applications of the SLD only the SAP Solution Manager is used, but neither PI, nor Web Dynpro for Java, etc... If that is your landscape, activating the SLD on your SAP Solution Manager system is sufficient. If not, I hope the following will help you
Once you have found out that you need more than one SLD, you should define how to transfer data from one SLD to the other to address the needs of all client applications of the SLD and minimize the manual effort.plan your SLD strategy.
There are three mechanisms of data exchange between SLD systems:
Figure 1: Mechanisms of Data Exchange between SLD Systems and their use cases.
From this table you can see that in a landscape more than one mechanism will be used, because there are different advantages in all of them.
Note: In your landscape, these mechanisms will be combined (as shown in the default landscape below). Nevertheless, you must not use several synchronization mechanisms for the same SLD data on the same synchronization path (for example, you do not set up fully automatic synchronization from SLD A to SLD B and configure automatic forwarding from SLD A to SLD B because both mechanisms would synchronize landscape data.
However, you could supplement automatic forwarding with regular export/import of manually entered data from SLD A to SLD B. Attention: Using export/import for automatically delivered data can lead to problems if the data is read by the LMDB, so DO NOT use export for technical systems data sent via a Data Supplier.
For details and the availability of these mechanisms, see the SLD Planning Guide.
In all landscapes sizing of systems is a topic. You'll find details regarding this topic in the Blog on Sizing a System for the System Landscape Directory of SAP NetWeaver.
From the things said so far, we get the following recommendation for a typical landscape where several SLD client applications are used - figure 2 shows the situation with SAP Solution Manager and Customer Profile used by the Maintenance Planner:
Figure 2a: Default SLD topology in a landscape with SAP Solution Manager, where Process Integration is used. The customer profile as a new important client of SLD data is also shown.
Note that as of January 2017, the SLD topology needs to be seen together with the Customer Profile, making landscape data available to the Maintenance Planner, a cloud based service of SAP Solution Manager. Also see "Other Hints for SLD Data Distribution".
The use of the optional back-up SLD is described in the blog wolf.hengevoss/blog/2009/03/27/how-to-ensure-that-sld-data-is-available-during-maintenance. Note: Do not use the virtual IP address for the full, automatic content sync to the LMDB - this could lead to CR Content inconsistencies. Also see SLD and LMDB Topology: Replacing the Source SLD for the LMDB.
In a landscape with SLD Client Applications and DEV/QA/PRD areas, the
QA and sandbox SLD systems can also be added; these would be part of the non-productive area (such systems are not shown in the picture).
For general recommendations for SLD and LMDB topology and use you'll find under "Guidance to Best Practices in SLD and LMDB".
Note: For some requirements, there is a new option to use the SAP Solution Manager LMDB as a target for data suppliers - for details, see Data Supplier Processing Options as of SAP Solution Manager 7.2 SPS06 – LMDB as a Data Supplier Targ....
There are new features available as of SAP Solution Manager 7.2 SPS09, which possibly affect the topology of SLD and LMDB and CIM/CR data handling in the IT landscape.
Note: All valid SLD/LMDB topologies stay valid.
Therefore, with SAP Solution Manager 7.2 SPS09, in case no SLD client applications are used – for example, SAP Process Integration, SAP NetWeaver Development Infrastructure, etc. – using an SLD becomes optional:
The following figure shows both options:
Figure 2b: SLD/LMDB topology options as of SAP Solution Manager 7.2 SPS09 with no SLD client apps.
In case, no SLD is available in the landscape, the LMDB needs to be updated with manual or automatic import of CIM/CR content to be configured in SAP Solution Manager transaction SolMan_Setup. For details see How to Reduce Manual Effort in CIM model and CR Content Update of SLD Systems.
If there are SLD client apps in use, the current topology should be kept.
Generally speaking, the design of the SLD topology in big landscapes in principle works as for the default landscape: The needs of the client systems are the same; therefore the data transfer mechanisms stay the same. Nevertheless, some new challenges may appear, such as the existence of more than one set of PI-systems or the wish to have more than one full automatic sync connection between SLD systems. While the design of such a landscape cannot be describes in one blog and needs a project to identify and address all business needs, some hints might help.
Business Systems' names need to be unique. In very big landscape with separated PI systems - or after a merger with another company also using PI - you could run into trouble, when identical Business System names "collide" in one SLD. The only solution here is to ensure the uniqueness of these names organizationally.
Usually, full automatic synchronization is used to keep backup SLDs in sync. It is not recommendable using a full automatic sync connection to sync SLDs of DEV and PRD area; you cannot update the SAP Solution Manager's SLD and - as described earlier - this is not necessary either.
A new point is that in big landscapes more than 2 SLDs might have a full automatic sync connection. Many topologies are valid, but the "unique path principle" must be fulfilled: From any SLD to any other there must only be 1 path for messages to guarantee that messages are handled in the correct sequence.
Unidirectional circular connections are supported: A message is only accepted once in any SLD so the transport of messages stops at the origin.
The following figure shows examples of valid topologies of SLDs in full auto sync. Only SLDs with full automatic sync connections are shown; more SLDs with other connection types can be added:
Figure 3: Valid topologies in SLDs using full automatic synchronization
Valid topologies can be combined with other topologies, as long as the unique path principle is valid. For example this would be a development SLD receiving data via bridge forwarding from an SLD being in full auto sync with others and sending back data by import and export.
In all invalid topologies there exists more than one path for messages between two SLDs - this should mainly happen in circular topologies:
Figure 4: invalid topologies in full automatic synchronization
Introduction
This blog is meant to summarize discussions I have had with dozens of customers and colleagues. While all the answers are written down and updated in the SLD Planning Guide, it might be useful to start with a short blog to get the big picture first and then check the much more comprehensive guide for details and exceptions.
There are three things that define your SLD strategy: Some general things like the separation of development and production, the SAP applications you use and the way SLD systems exchange information.
SLD Topology and Data Gathering & Distribution
Data Sources
SLD topology describes the required number and area of installation of SLD systems in IT landscapes and the connections between them. This is derived from the landscape itself - providing landscape data by systems' self-registration via SLD Data Suppliers.
Note: In addition to the SLD Data Suppliers being part of the technical system itself, as of SAP Solution Manager 7.2, SPS06 the SLD can be a target for agent data - see SAP Note 2556432 - Switch Outside Discovery from Diagnostics Agent to SAP Host Agent
Reasons to Have more than One SLD
Many applications rely on SLD data. Among these are - most prominently - SAP NetWeaver Process Integration (PI), Web Dynpro for Java, and the SAP Solution Manager. Reasons to have more than one SLD system are manifold:
- Areas in front of and behind a firewall: If something needs to be available in front of and behind a firewall, you need at least two systems.
- Separation of development, quality assurance, and productive systems: Most easily and most importantly this can be explained for PI - Business Systems are developed before they are meant to be used productively. The easiest way to separate non-productive and productive state is to separate the development and productive SLD.
- Separation of managing and managed systems: The SAP Solution Manager does not recommend to have runtime dependencies to productive systems but on the other hand recommends to have a "local" SLD activated on the SAP Solution Manager system: Since SLD data are crucial for all applications mentioned earlier, at least one more SLD is required if any other SLD client application is used
- Having 24/7 business hours does not allow for maintenance causing downtime: A backup SLD system is needed to ensure the availability of SLD data.
- Having extremely high security requirements, where certain SLD systems need to be isolated from the net may also require isolated SLD systems.
Therefore, there is only one scenario where one SLD would be enough: This you find in landscapes where of all client applications of the SLD only the SAP Solution Manager is used, but neither PI, nor Web Dynpro for Java, etc... If that is your landscape, activating the SLD on your SAP Solution Manager system is sufficient. If not, I hope the following will help you
Mechanisms of Data Exchange between SLD Systems
Once you have found out that you need more than one SLD, you should define how to transfer data from one SLD to the other to address the needs of all client applications of the SLD and minimize the manual effort.plan your SLD strategy.
There are three mechanisms of data exchange between SLD systems:
Figure 1: Mechanisms of Data Exchange between SLD Systems and their use cases.
From this table you can see that in a landscape more than one mechanism will be used, because there are different advantages in all of them.
- Automatic forwarding (also name bridge forwarding) transfers all technical systems' data a (source) SLD gets from the data suppliers unaltered to any target SLD. Since this data is sufficient for most clients and cannot be retrieved otherwise, this method is very important in each landscape
- Export/Import allows transporting all kind of data and provides full control of the point in time when changes become available in the target system. It is therefore mainly used in PI scenarios, where Business Systems and Products/Software Components are developed in the SLD to be available in time - not too late, but not too soon either! - in the productive system. Better Manage SLD Exports and Imports Using CTS+. Another use case for export/import of SLD data is the high security settings mentioned earlier. In extreme cases, a special user can personally walk to a SLD carrying the update with him.
- Full Automatic Synchronization Demo: The Full Automatic Sync Feature in the SLD of SAP NetWeaver 7.1 without bothering you with messages, which is excellent - in many but not all cases: For example, it helps in How-to Manage House-Cleaning in the System Landscape Directory - Duplicate System Entries, because among all other data also deletions are transported. This, however, is also the reason why this sync method cannot be used for all SLD data transfers: It does not provide control of any kind (apart from activating and de-activating the sync all the time). Full automatic synchronization is therefore not to be used for the PI scenario described under Export/Import - I mentioned that the sync would also transport deletions for example - and think of a Business System deleted erroneously in the Dev-SLD and ceasing to exist in production seconds later... Therefore, there remain two main use cases for this mechanism: 1st is creating a hot-backup SLD [LINK to Maintenance-BLOG] to avoid gaps in SLD data availability caused by a planned downtime and 2nd is the initial "data load" of a newly installed SLD system to prepare the migration of SLD data.
(Note that an SLD of SAP NetWeaver 7.0 based on SP Stack 12 and above can (only) be used as the source system for uni-directional synchronization.)
Note: In your landscape, these mechanisms will be combined (as shown in the default landscape below). Nevertheless, you must not use several synchronization mechanisms for the same SLD data on the same synchronization path (for example, you do not set up fully automatic synchronization from SLD A to SLD B and configure automatic forwarding from SLD A to SLD B because both mechanisms would synchronize landscape data.
However, you could supplement automatic forwarding with regular export/import of manually entered data from SLD A to SLD B. Attention: Using export/import for automatically delivered data can lead to problems if the data is read by the LMDB, so DO NOT use export for technical systems data sent via a Data Supplier.
For details and the availability of these mechanisms, see the SLD Planning Guide.
Sizing of SLD Systems
In all landscapes sizing of systems is a topic. You'll find details regarding this topic in the Blog on Sizing a System for the System Landscape Directory of SAP NetWeaver.
SLD Topology
(Default) SLD Topology in a Landscape with SLD Client Applications
From the things said so far, we get the following recommendation for a typical landscape where several SLD client applications are used - figure 2 shows the situation with SAP Solution Manager and Customer Profile used by the Maintenance Planner:
Figure 2a: Default SLD topology in a landscape with SAP Solution Manager, where Process Integration is used. The customer profile as a new important client of SLD data is also shown.
Note that as of January 2017, the SLD topology needs to be seen together with the Customer Profile, making landscape data available to the Maintenance Planner, a cloud based service of SAP Solution Manager. Also see "Other Hints for SLD Data Distribution".
The use of the optional back-up SLD is described in the blog wolf.hengevoss/blog/2009/03/27/how-to-ensure-that-sld-data-is-available-during-maintenance. Note: Do not use the virtual IP address for the full, automatic content sync to the LMDB - this could lead to CR Content inconsistencies. Also see SLD and LMDB Topology: Replacing the Source SLD for the LMDB.
In a landscape with SLD Client Applications and DEV/QA/PRD areas, the
- The (runtime) SLD of the productive systems' area acts a central SLD gathering all technical systems' data via SLD Data Suppliers. It forwards this data to all other SLDs. This SLD can run standalone on a dedicated server or, for example, on the PI server.
In many cases a high-availability setup is used for this SLD. - A separate (design time) SLD exists in the development area and if PI is used an SLD can also be set up in QA, additionally. Business Systems and Products/Software Components created here are exported from and imported into the productive SLD - preferably using CTS+ to manage exports and imports centrally.
- Optionally, a backup SLD can be added to the landscape and kept up-to-date by full automatic synchronization with the central SLD.
- Client applications (such as SAP Process Integration (PI), NWDI, or front ends like browsers or the Developer Studio) access the SLD of their area or according to their function.
- SAP Solution Manager
QA and sandbox SLD systems can also be added; these would be part of the non-productive area (such systems are not shown in the picture).
For general recommendations for SLD and LMDB topology and use you'll find under "Guidance to Best Practices in SLD and LMDB".
Note: For some requirements, there is a new option to use the SAP Solution Manager LMDB as a target for data suppliers - for details, see Data Supplier Processing Options as of SAP Solution Manager 7.2 SPS06 – LMDB as a Data Supplier Targ....
Topology Options Available as of SAP Solution Manager 7.2 SPS09
There are new features available as of SAP Solution Manager 7.2 SPS09, which possibly affect the topology of SLD and LMDB and CIM/CR data handling in the IT landscape.
- As of SAP Solution Manager 7.2 SPS09, SLD and LMDB can be a direct target for CIM model data and CR content. As of SAP Solution Manager 7.2 SPS06, the LMDB can act as a Data-Supplier target – this can now be combined with the new feature available as of SAP Solution Manager 7.2 SPS09 to allow direct CIM/CR Upload to the LMDB
- Furthermore, CIM/CR update in LMDB and SLD can automated
Note: All valid SLD/LMDB topologies stay valid.
Landscape without SLD Client Applications
Therefore, with SAP Solution Manager 7.2 SPS09, in case no SLD client applications are used – for example, SAP Process Integration, SAP NetWeaver Development Infrastructure, etc. – using an SLD becomes optional:
- You can still use it as a target for SLD Data Suppliers and as a CIM/CR source for the LMDB
- You can use the LMDB as a Data Supplier Target combining it with the new CIM/CR import to the LMDB
The following figure shows both options:
Figure 2b: SLD/LMDB topology options as of SAP Solution Manager 7.2 SPS09 with no SLD client apps.
In case, no SLD is available in the landscape, the LMDB needs to be updated with manual or automatic import of CIM/CR content to be configured in SAP Solution Manager transaction SolMan_Setup. For details see How to Reduce Manual Effort in CIM model and CR Content Update of SLD Systems.
Landscape with SLD Client Applications
If there are SLD client apps in use, the current topology should be kept.
SLD Topology in Big Landscapes
Generally speaking, the design of the SLD topology in big landscapes in principle works as for the default landscape: The needs of the client systems are the same; therefore the data transfer mechanisms stay the same. Nevertheless, some new challenges may appear, such as the existence of more than one set of PI-systems or the wish to have more than one full automatic sync connection between SLD systems. While the design of such a landscape cannot be describes in one blog and needs a project to identify and address all business needs, some hints might help.
Special Use Cases in SAP NetWeaver Process Integration
Business Systems' names need to be unique. In very big landscape with separated PI systems - or after a merger with another company also using PI - you could run into trouble, when identical Business System names "collide" in one SLD. The only solution here is to ensure the uniqueness of these names organizationally.
Topologies of SLDs with Full Automatic Sync Connection
Usually, full automatic synchronization is used to keep backup SLDs in sync. It is not recommendable using a full automatic sync connection to sync SLDs of DEV and PRD area; you cannot update the SAP Solution Manager's SLD and - as described earlier - this is not necessary either.
A new point is that in big landscapes more than 2 SLDs might have a full automatic sync connection. Many topologies are valid, but the "unique path principle" must be fulfilled: From any SLD to any other there must only be 1 path for messages to guarantee that messages are handled in the correct sequence.
Unidirectional circular connections are supported: A message is only accepted once in any SLD so the transport of messages stops at the origin.
The following figure shows examples of valid topologies of SLDs in full auto sync. Only SLDs with full automatic sync connections are shown; more SLDs with other connection types can be added:
Figure 3: Valid topologies in SLDs using full automatic synchronization
- Bi-directional full automatic synchronization connection between two systems (SLD 1 and SLD 2) - use case "backup". (This is the only bi-directional circle allowed, because there only is one other SLD. Of course a uni-directional connection would be valid in any case where a bi-directional connection is allowed.
More SLDs can be added, as long as there are no circles introduced. - Star topology (SLDs 1-4); SLD 1 would act as a master SLD here.
This can also be combined with a linear connection (see SLD 5) or other "stars" as long as the unique path principle is valid.
(The part SLD 1 <-> SLD 2 <-> SLD 5 is a longer variant of the backup topology.) - Valid circular topology (SLDs 1-4) can be used with uni-directional connections. Introducing bi-directional connections (even 1) would violate the unique path principle. This also only works with all connections going in the same direction (clockwise or anticlockwise): Changing the direction of less than all connection will invalidate the setup (see "invalid topologies".
Valid topologies can be combined with other topologies, as long as the unique path principle is valid. For example this would be a development SLD receiving data via bridge forwarding from an SLD being in full auto sync with others and sending back data by import and export.
In all invalid topologies there exists more than one path for messages between two SLDs - this should mainly happen in circular topologies:
Figure 4: invalid topologies in full automatic synchronization
- Invalid circular uni-directional topology (SLDs 1-4) with 4 uni-directional connections.
This example shows that there also is a way to create invalid topologies with uni-directional sync connections: here, a message X in SLD 4 can reach SLD 2 via SLDs 1 and 3 - successor message Y in SLD 1 might reach SLD 4 earlier than message X, resulting in incorrect data. - Invalid circular bi-directional topology (SLDs 1-4) with 4 bi-directional connections.
A message X in any SLD can reach any other SLD clockwise and anticlockwise - successor message Y in SLD 1 might reach SLD 4 earlier than message X, resulting in incorrect data.
Further Information
Other Hints for SLD Data Distribution
- A similar problem as shown for the unique path principle violation in full automatic sync connections can occur when the same information was gathered in more than one SLD and is then aggregated in one SLD. This could cause problems especially when renaming of objects is involved.
- SLD data is the basis for SAP Solution Manager LMDB so this might also be of interest: SLD-LMDB Topology – Connections, Valid, and Invalid Data Exchange Between SLD and LMDB of SAP Soluti...
- Now SAP Support Portal Customer Profile is growing in importance in landscape management: Topology of SLD, LMDB, and Customer Profile – How to Get Reliable Landscape Data in SAP Support Port...
Related Information
- Related blog post
- SAP Notes
- 1669649 - SLD/LMDB synchronization: Principle of the clear path
- 1842956 - Check Data Supplier Completeness for Technical System
- 1631346 – Solution Manager 7.1: SLD configuration for PI monitoring
or
1816997 - Setting Up Process Integration Monitoring in Solution Manager 7.2 SPS01, SPS02, SPS03, and Onwards
- 2556432 - Switch Outside Discovery from Diagnostics Agent to SAP Host Agent
- More information...
- ... on the SLD you'll find in SCN under System Landscape Directory (SLD)
- ... on CTS you'll find in SCN under SAP NetWeaver Software Change Management
- SAP Managed Tags:
7 Comments
