Skip to Content

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

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:

Transport Mechanisms of the SLD

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.

 

Default SLD Topology – SLDs in a Typical IT Landscape

From the things said so far, we get the following recommendation for a typical landscape where several SLD client applications are used – figure 2a shows the situation with SAP Solution Manager 7.0, 2b with SAP Solution Manager 7.1:

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.

 

Recommended SLD topology in a default landscape (as shown in figure 2a for SAP Solution Manager 7.0 and 2b for SAP Solution Manager 7.1):

  • 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.
  • 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).

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.

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 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:

Valid Topologies for SLDs in full automatic synchronization

Legend of SLD full automatic sync topologies

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:

Invalid Topologies of SLDs in Full automatic Sync

Legend of SLD Topologies in Full Automatic Sync

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.

Other Hints for SLD Data Distribution

.

Related Information

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Michael Nicholls
    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?
    (0) 
  2. Thomas Huber
    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?
    (0) 
    1. Wolf Hengevoss Post author
      All SLD content can be exported manually. In a PI-scenario the export of Business System information is important. You’ll find a description in the following article:
      http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/60a44163-4ff8-2c10-839e-af7cdf58faf0?QuickLink=index&overridelayout=true
      -> see section 3.2.
      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.

      I hope that answers your question.

      Best Regards,

      Wolf

      (0) 

Leave a Reply