SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?

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

SLD topology decribes the required number and area of installation of SLD systems in IT landscapes and the connections between them.

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. Export and import of SLD data can be handled centrally with 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 transfers each and every SLD data immediately to all target system without bothering you with messages, which is excellent - in many but not all cases: For example, it helps in SLD house-keeping, 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).

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:

Default SLD Topology

Figure 2: Default SLD topology in a landscape where Process Integration is used

Recommended SLD topology in a default landscape (as shown in figure 2):

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

Sizing of SLD Systems

In all landscapes sizing of systems is a topic. You'll find details regarding this topic in the Blog on SLD Sizing.

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

One last remark: 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.

Related Information

SAP Developer Network SAP Weblogs: SAP Process Integration (PI)