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.
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.
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.
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.
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.
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: 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.
Figure 2: 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 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.
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 PI, NWDI, or front ends like Browsers or the Developer Studio) access the SLD of their area or according to their function.
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 Target.
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.
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.
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.
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.
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.
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.
I believe JCO destinations as used by Web Dynpro Java applications are stored in the SLD. Are these part of the “Full Auto Synchroniszation” capability?
Yes, full automatic sync will sync all data, including those manually created.
I am currently setting up a new PI 7.3 Landscape. After reading your SLD Blog and the SLD Planning guide there is one question which we are discussing: I want to setup a landscape as described in figure 2 of your blog.
What is here the exact meaning of “Manually Export/Import” ? Is this the SLD Full/Delta Export Feature using the ALL Exportline? If so, is this not a problem according possible circular transport of landscape data?
This is not a circular transport: Forwarding only transports Technical Systems’ data while in the export – as described in 3.2 – only contains Business System information.