01_planning guide - system landscape directory

Planning Guide

SystemLandscape Directory

Document Version 1.42 – February 2007

© Copyright 2007 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in anyform or for any purpose without the express permission of SAP AG.The information contained herein may be changed without priornotice.

Some software products marketed by SAP AG and its distributorscontain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registeredtrademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex,MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries,xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity,Tivoli, and Informix are trademarks or registered trademarks of IBMCorporation in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of theOpen Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame,VideoFrame, and MultiWin are trademarks or registered trademarks ofCitrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registeredtrademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., usedunder license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, andother SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AGin Germany and in several other countries all over the world. All otherproduct and service names mentioned are the trademarks of theirrespective companies. Data contained in this document servesinformational purposes only. National product specifications mayvary.

These materials are subject to change without notice. These materialsare provided by SAP AG and its affiliated companies ("SAP Group")for informational purposes only, without representation or warranty ofany kind, and SAP Group shall not be liable for errors oromissions with respect to the materials. The only warranties for SAPGroup products and services are those that are set forth in the expresswarranty statements accompanying such products and services, if any.Nothing herein should be construed as constituting an additionalwarranty.

SAP Library document classification: PUBLIC

DisclaimerSome components of this product are based on Java™. Any codechange in these components may cause unpredictable and severemalfunctions and is therefore expressively prohibited, as is anydecompilation of these components.

Any Java™ Source Code delivered with this product is only to be usedby SAP’s Support Services and may not be modified or altered in anyway.

Documentation in the SAP Service MarketplaceYou can find this documentation at the following Internet address:service.sap.com/sld

Planning Guide – System Landscape Directory

February 2007 3

Document History

Before you start planning, make sure you have the latest version of this document. You can findthe latest version in SAP Service Marketplace at:

service.sap.com/sld Medial Library

The following table provides an overview on the most important document changes.

Version Date Description

1.42 February 2007 Added section SLD Clients.

Added section Release Compatibility.

In section Automatic Forwarding of Landscape Data, removed the notebox with information about the behavior for SAP NetWeaver ’04. Thedescribed behavior only occurs if you set a specific SLD parameter forSAP NetWeaver ’04 or for older SLD releases – so, for most cases, thisnote box did not apply, automatic forwarding in most cases works thesame for SAP NetWeaver ’04 and SAP NetWeaver 2004s.

Changed section Outlook to Future Versions of SAP NetWeaver.

Minor changes


4 February 2007

Contents

1 Introduction.................................................................................................................... 5

1.1 Structure of the Planning Guide............................................................................... 51.2 More Information..................................................................................................... 51.3 Accessing the SAP Library...................................................................................... 6

2 Overview ....................................................................................................................... 7

3 SLD Topology................................................................................................................ 8

3.1 Process to Define Your SLD Landscape Strategy.................................................... 83.2 Fundamental SLD Concepts ................................................................................. 11

3.2.1 SLD Clients ....................................................................................................... 113.2.2 Fundamental Landscape Scenarios................................................................... 133.2.3 Synchronization Strategies ................................................................................ 173.2.4 Reasons to Have Several SLDs......................................................................... 173.2.5 Release Compatibility........................................................................................ 203.2.6 How You Can Handle Possible Changes to Your SLD Strategy ......................... 21

3.3 Best Practices Scenarios ...................................................................................... 223.3.1 Central SLD for All Applications ......................................................................... 223.3.2 Separate SLD for Dev/QA and for Production .................................................... 233.3.3 Separate SLD for NWDI .................................................................................... 243.3.4 SLD for Distributed SAP NetWeaver Exchange Infrastructure Landscapes ........ 253.3.5 SLD for Distributed Development....................................................................... 26

3.4 Network Access Scenarios.................................................................................... 273.4.1 Intranet Scenario ............................................................................................... 273.4.2 Extranet Scenario.............................................................................................. 28

3.5 Where to Run SLD in Your System Landscape ..................................................... 293.5.1 Overall Recommendations................................................................................. 303.5.2 No SLD-Critical Application................................................................................ 323.5.3 One SLD-Critical Application ............................................................................. 333.5.4 Several SLD-Critical Applications....................................................................... 34

4 Overview of Connections to and from SLD................................................................... 36

4.1 ABAP Data Supplier (1) ........................................................................................ 364.2 Java Data Supplier (2) .......................................................................................... 364.3 External Data Supplier (3) ..................................................................................... 374.4 Java SLD Client (4)............................................................................................... 374.5 ABAP SLD Client (5)............................................................................................. 374.6 SLD to SLD Message Forwarding (6) .................................................................... 37


February 2007 5

1 IntroductionThis documentation provides you with a central starting point for the planning of your landscape strategy forthe system landscape directory of SAP NetWeaver®.

1.1 Structure of the Planning GuideThe planning guide consists of the following sections:

Introduction

Contains information about this documentation and related information important for the planning of thesystem landscape directory.

Overview

Contains a short introduction to the system landscape directory.

System Landscape Directory Topology

This section introduces a high-level process to define an individual landscape strategy for the systemlandscape directory based on your requirements. You get information about landscape scenarios, bestpractices and recommendations on which host you could run the system landscape directory in yoursystem landscape.

Overview of Connections to and from System Landscape Directory

Contains information about all communication paths to and from the system landscape directory.

1.2 More InformationThe following list contains links to information about the system landscape directory on SAP ServiceMarketplace and in the SAP Library:

Content Location on SAP Service Marketplace or in the SAP Library

Information about the system landscapedirectory and correspondingdocumentation

service.sap.com/sld

Configuring and using the systemlandscape directory

User Manual – SLD:

service.sap.com/sld Media Library

Platform and Technology InformationCenter

service.sap.com/platforms

Sizing of SAP NetWeaver service.sap.com/sizing

Information about security SAP Security Guide:Located in the SAP Library [page 6] at SAP NetWeaver Library

Administrator’s Guide SAP NetWeaver Security Guide

Information about the technicaloperation of SAP NetWeaver

Technical Operations Manual:Located in the SAP Library [page 6] at SAP NetWeaver Library

Administrator’s Guide Technical Operations Manual forSAP NetWeaver

http://service.sap.com/platforms


6 February 2007

1.3 Accessing the SAP LibraryAccess the SAP Library from any of the following:

SAP Help Portal at help.sap.com SAP NetWeaver <Release>

Select the required language.

The SAP Help Portal contains the latest version of the SAP Library. Therefore, we recommendthat you use this channel to access the SAP Library.

An SAP system if you have installed the online documentation:

Choose Help SAP Library.

The browser starts.

The help files on the online documentation CDs or DVDs

If you want to view the help files in HTMLHelp format from the online documentation CDs or DVDs, youneed a PC running Microsoft Windows to install the HTMLHelp Viewer.


February 2007 7

2 OverviewThe system landscape directory of SAP NetWeaver (from now on abbreviated as SLD in this documentation)is the central directory of system landscape information that is relevant for the management of your softwarelifecycle. It contains a description of your system landscape (that is, the software components that arecurrently installed) and a repository of software components that can theoretically be installed in yourlandscape (such as the software components available from SAP). Since this data gets updatedautomatically, SLD provides reliable and up-to-date system landscape information with minimized effort foryou. In this way, SLD acts as a central information provider for SAP and third-party tools that use this data todeliver the services you need to keep your landscape up and running.

Be aware that the abbreviation SLD is not intended to define a product, since the systemlandscape directory is part of SAP NetWeaver. This abbreviation is solely intended to improvereadability.


8 February 2007

3 SLD Topology

3.1 Process to Define Your SLD Landscape StrategyYou can introduce and run SLD in your SAP NetWeaver landscape in many different ways. Each of theseways has different advantages and disadvantages. Therefore, you should plan the introduction of SLDproperly according to your landscape requirements.

The following figure shows a possible process to get an individual strategy how and where to run SLD in yoursystem landscape:

How and where torun SLD in my

system landscape?

Learn SLD concepts

How many SLDs?

Synchronization?

Where to run SLD?

1. You familiarize yourself with fundamental concepts, distribution and synchronization options of SLD(such as the option to have a single central SLD or several distributed SLDs, the concept of a masterSLD, synchronization methods, and possible reasons to have more than one central SLD).

For more information about fundamental SLD concepts, see the following sections:

SLD Clients [page 11]

Fundamental Landscape Scenarios [page 11]

Reasons to Have Several SLDs [page 17]

Synchronization Strategies [page 17]

Release Compatibility [page 20]

How You Can Handle Possible Changes to Your SLD Strategy [page 20]


February 2007 9

In addition, see SAP Note 954820 (Compatibility of SLD in the system landscape) that gives informationabout released combinations of SLD server and SLD client releases.

Make sure that you have up-to-date versions of SAP Notes, which you can find on SAP ServiceMarketplace at service.sap.com/notes.

2. You decide how many SLDs you require. For this, get a clear picture of the requirements that yoursystem landscape/environment demands concerning the data stored in SLD, for example in terms of:

Applications that rely critically on SLD in your system landscape, required availability of SLD andimpact on your system landscape if SLD would temporary not be available

Required performance for accessing SLD (for example, affected by network lags due to a largephysical distance between an SLD client and your SLD itself or improper hardware performance ofthe host on which you run your SLD)

Technical constraints of your system landscape (such as networks, firewalls, message volumes,hardware, high availability)

Visibility and changeability of certain data stored in SLD (for example, you might have therequirement to restrict access to data of production systems for developmentsystems/administrators)

Legal constraints (such as sensitivity of data, retention periods, country specific laws)

Company rules, organizational structures or governance models

For more information about some of these aspects, see the following sections:

Best Practices Scenarios [page 22]

Network Access Scenarios [page 27]

In addition, see SAP Note 764393 (Configuration of the SAP System Landscape Directory) that containsfurther information about the required number of SLD instances in a landscape.

As a result of this step, you should get an idea if a central SLD fits your requirements or how manydistributed SLDs you require.

3. If you require more than one SLD, you have to think about synchronizing the SLD data stored in yourSLDs. For this, create a model to understand which data is required in which of your planned SLDs. Inaddition, you might want to restrict the forwarding of certain data to certain SLDs in your landscape togenerate different views.

For example, you maybe do not want to forward data of your production systems into adevelopment SLD.

If manual synchronization is required, we recommend that you create some kind of operationmanual that helps to establish a process when and how synchronization should be performed bywhom.

In addition, see SAP Note 764393 (Configuration of the SAP System Landscape Directory) that containsfurther information about synchronizing SLD instances in a landscape.

As a result of this step, you should receive a synchronization strategy for your SLDs.


10 February 2007

4. You decide on which system(s) you want to run your SLD(s).

You could either run SLD on a separate AS Java system or run it together with other central sharedservices or business functions (for example, your SAP NetWeaver Exchange Infrastructure system) onan existing system.

To a certain degree, this also results from the requirements you are facing in your landscape concerningSLD (for example, high availability features, planned/unplanned downtime, load of the correspondinghost, network connection). For more information, see section Where to Run SLD in Your SystemLandscape [page 29].


February 2007 11

3.2 Fundamental SLD Concepts

3.2.1 SLD ClientsThe following figure shows applications and tools that provide services by using the data that is stored inSLD – for this, these so-called SLD clients read data from and write data to SLD:

SAP NetWeaverExchange Infrastructure

SAP NetWeaver Administrator

Monitoring & Management Connectivity Layer(JMX, Agents…)


Productive Landscape

Central Monitoring& Administration

System

SAP NetWeaverAdministrator

SLD SolutionManager

ABAPSystem

JavaSystem

Non-SAPComponent



Productive Landscape


System



System


System


SLD SolutionManager

ABAPSystem

JavaSystem

Non-SAPComponent

Adaptive ComputingController

CentralizedStorage System

Control Node

Storage Network Switch

Server Network Switch

ComputingNodes

Adaptive Computing ControllerSolution Manager

CentralizedStorage System

Control Node

Storage Network Switch

Server Network Switch

ComputingNodes

Adaptive Computing ControllerSolution Manager

SAP Solution Manager

SAP NetWeaverDevelopment Infrastructure

DTR CBS

SLD

DevelopmentObjects

Binaries ofused SCs/workspace

/inactive

/buildspace

CMS (Landscape Configurator)

Register dev.configuration

Retrieve storage locationof dev. configuration

Retrieve dev.configuration

Development Configuration

/active

DTR CBS

SLD

DevelopmentObjects

Binaries ofused SCs/workspace

/inactive

/buildspace

CMS (Landscape Configurator)

Register dev.configuration

Retrieve storage locationof dev. configuration

Retrieve dev.configuration

Development Configuration

/active

Web Dynpro Runtime

Web ServiceProvider

J2EEBackendServer

J2EEWeb Dynpro

Runtime

Deployed WebDynpro AppDeployed Web

Dynpro App

SAP Enterprise Portal

Web DynproApplication

HTTP(S)SAPNetWeaverDeveloper

Studio

SAPNetWeaverDeveloper

Studio

ABAPWeb DynproRuntime

Web DynproAppWeb Dynpro

App

ABAP developmentWorkbench

Backend ApplicationBackend Application

ABAPBackendServer

WebService

RMI SOAP RFC

RFC enabledFunction ModulesEJB (e.a.)

BusinessData

BusinessData

BusinessData

Web ServiceProvider

J2EEBackendServer

J2EEWeb Dynpro

Runtime

Deployed WebDynpro AppDeployed Web

Dynpro App

SAP Enterprise Portal

Web DynproApplication

HTTP(S)SAPNetWeaverDeveloper

Studio

SAPNetWeaverDeveloper

Studio

ABAPWeb DynproRuntime

Web DynproAppWeb Dynpro

App

ABAP developmentWorkbench

Backend ApplicationBackend Application

ABAPBackendServer

WebService

RMI SOAP RFC

RFC enabledFunction ModulesEJB (e.a.)

BusinessData

BusinessData

BusinessData

BusinessData

Software Lifecycle Managerof SAP NetWeaver

SLD

Other Clients

…

For SAP NetWeaver Exchange Infrastructure has several SLD use cases:

The SLD acts as a server for business system names (these have to be associated with thecorresponding technical systems received from their data suppliers). These are used:


12 February 2007

For the receiver determination in the Integration Directory of SAP NetWeaver ExchangeInfrastructure. Therefore, all business systems must be available in one master SLD if you needto send messages from a business system in one region to a receiver system in another region.

By application systems to get their own business system name (Java Proxy Framework andSAP systems).

The SLD provides the transport targets for Integration Directory content transports, such as from abusiness system in a development environment to a business system in a test environment.

The SLD provides all systems and adapters for the end-to-end monitoring in the Runtime Workbenchof SAP NetWeaver Exchange Infrastructure.

The SLD provides the address for the transfer of adapter configuration data from the IntegrationDirectory to the adapter cache.

The SLD contains functions for the management of software component versions. Therefore, youhave to forward component repository data (software components and software componentversions) created in an SLD used for SAP NetWeaver Development Infrastructure to an SLD usedfor the development of SAP NetWeaver Exchange Infrastructure.

You can use SAP Solution Manager to implement, train, test, maintain, monitor, control change, andmanage incidents of your SAP solution system landscape (open end-to-end application management).For this, it requires a system data repository. For this, SLD is used.

SAP NetWeaver Administrator retrieves landscape data from the SLD. It requires this information forremote monitoring functions.

Web Dynpro of Java uses the SLD to find destination information for ABAP systems and Web servicesfor adaptive RFC calls.

SAP NetWeaver Development Infrastructure uses the SLD:

As central provider for component information and landscape data

As name server for reservation of development object names

Adaptive Computing Controller retrieves landscape data from the SLD. It requires this information for itsoperation (that is, start, stop and change of resources).

You can optionally use the software lifecycle manager of SAP NetWeaver to plan software logistics tasks(installation, upgrade and patch installation) in your system landscape. For this, the software lifecyclemanager retrieves landscape data from the SLD and enriches this data with additional information (likeinformation of business scenarios that run in a system landscape).

For more information about SAP NetWeaver Exchange Infrastructure, SAP Solution Manager,SAP NetWeaver Administrator, SAP NetWeaver Development Infrastructure, AdaptiveComputing Controller, and the software lifecycle manager of SAP NetWeaver, see the MasterGuide – SAP NetWeaver available in SAP Service Marketplace atservice.sap.com/instguides SAP NetWeaver <Release>.


February 2007 13

3.2.2 Fundamental Landscape ScenariosThe most straightforward scenario is the use of a single SLD. However, depending on organizational,operational, or security reasons, it is also possible to have more than one SLD distributed over the systemlandscape.

For all landscape scenarios, the use of DNS aliases to address SLD makes it possible to switch SLD hostsvery easily. This may be necessary for maintenance (updates) and upgrades. For example, you could installa new AS Java system with a higher release, configure SLD on this new system, import the data of youractual SLD into the new SLD and switch to this new SLD. This way, you have “upgraded” to a higher releasewith minimal SLD downtime.

3.2.2.1 Central Organization (One Single Central SLD)The easiest scenario is to have a single system landscape directory server that acts as a central informationprovider for the enterprise system landscape. All systems in your system landscape, including all subnetworks, share a single system landscape directory server that contains information about the whole systemlandscape.

The advantages of using a single system landscape directory server for the entire system landscape areconsistent data, easier administration, and lower operating expense.

The following figure shows a corresponding example:

Extranet

Intranet

IntranetSAP

System

SLD

Intranet

SAPSystem

SAPSystem

SAPSystem

SAPSystemSAP

System

SAPSystem


14 February 2007

3.2.2.2 Distributed Organization (Several Distributed SLDs)A more flexible approach is the use of several distributed SLDs. However, the effort and cost to operate yourSLD landscape increases due to required manual model and content updates in all SLDs and possibleregular synchronization activities.

Hierarchical Organizations (One Central SLD with Decentralized Sub-SLDs)

This organizational form incorporates several fully separated divisions headed by the headquarters. Thelocal division’s SLD serves all local needs. Automatic forwarding of landscape data from all divisionsaccumulates as the complete system landscape in the headquarters’ SLD.

The following figure shows a hosting scenario with separate customer system landscapes. Each customerlandscape incorporates its own SLD containing data about this customer’s landscape only. The hostingprovider itself must have access to the system landscape of all customers. To achieve this, you configure thesub-SLDs to forward automatically all landscape data to a master SLD for the hosting provider. So, you canuse a hierarchical organization of several SLDs to create different views of your landscape.

Hosting Provider

Customer 1

SAPSystem

SLD

Customer 2

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SLD

SLD

Automatic forwardingof landscape data

Another use case is an application development landscape comprising development, test, and productionsystems. The data is forwarded from the development system to the test system and then to the productionsystem.


February 2007 15

Fully Separated Organizations (Several Standalone SLDs)

You can use several SLDs for fully separated management of data independent of each other, as shown inthe following figure:

Extranet

Intranet

IntranetSAP

System

SLD

Intranet

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SLD


16 February 2007

Distributed Organization (Several Coupled SLDs)

Global or widely distributed IT landscapes may require more than a central SLD. It is then expected that anSLD is locally available but that it provides a more than local view. You can achieve this by coupling severaldistributed SLDs that exchange all or only certain of their SLD data.

The following figure shows a corresponding example:

Extranet

Region 1

SAPSystem

SLD

Region 2

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SLD

Synchronization


February 2007 17

3.2.3 Reasons to Have Several SLDsThere may be several reasons to have more than one system landscape directory. For example, if you havegeographically distributed locations with local administration groups that want to see only their local systemsin the system landscape directory.

In addition, several system landscape directories may be required if you want to isolate your productionenvironment. By having a system landscape directory dedicated for your production systems, you make surethat these systems are not visible from your development or test environment.

An important reason to have several system landscape directories is to provide improved availability of theinformation stored in the system landscape directory. This information could be essential for applicationsrunning in your production landscape. The following list shows examples of SAP NetWeaver applications forwhich the availability of the system landscape directory can be critical:

For SAP NetWeaver Exchange Infrastructure, availability of the system landscape directory is at leastrequired at restart of SAP NetWeaver Exchange Infrastructure. As used system landscape directorycaches may be invalidated manually, the system landscape directory is critical for SAP NetWeaverExchange Infrastructure.

For Web Dynpro of Java, the system landscape directory is critical during runtime for adaptive RFC calls.

SAP NetWeaver Administrator requires the system landscape directory for remote monitoring functions.If the system landscape directory is unavailable, no central administration of systems is possible.

Adaptive Computing Controller requires the system landscape directory for its operation (that is, start,stop and change of resources). If the system landscape directory is unavailable, only monitoringfunctions of Adaptive Computing Controller are available.

For more information about SAP NetWeaver Exchange Infrastructure, SAP NetWeaverAdministrator, and Adaptive Computing Controller, see the Master Guide – SAP NetWeaveravailable in SAP Service Marketplace at service.sap.com/instguides SAP NetWeaver

<Release>.

3.2.4 Synchronization StrategiesTo support the operation of several SLDs, we provide automatic message forwarding as well assophisticated data export and import functions.

3.2.4.1 Automatic Forwarding of Landscape DataTo keep separate SLDs informed about changes of specific landscape data, you can configure the SLDbridge to forward data to other SLD instances. With automatic forwarding, the SLD allows direct server-to-server synchronization.

The following landscape data can be synchronized:

ABAP system data (transaction RZ70)

Java system data (SLD data supplier service)

Host data (SAPOSCOL)

Other system data (sldreg)


18 February 2007

In the moment, we do not recommend to set up a circular exchange of data between two ormore instances with automatic forwarding – although data received by the original sender is notforwarded again, the original sender will write an error message in its log file that the datareceived by the automatic forwarding is already contained in the local SLD. Nevertheless, weplan to change this behavior with SAP NetWeaver 2004s Support Package Stack 11 (scheduledfor the first quarter of 2007). Then, circular forwarding will be fully supported and the originalsender will no longer write an error message in its log file after receiving its own data from anyother SLD.

Any changes and entries that you entered manually into SLD (for example, business systems required forSAP NetWeaver Exchange Infrastructure, component repository extensions, or name reservation data)cannot be forwarded automatically and stays within the local SLD only. The same restriction applies for datawritten by other applications such as SAP NetWeaver Exchange Infrastructure or SAP Solution Manager.

Therefore, with automatic forwarding, you get the flexibility to run several SLDs in your system landscapewith little manual effort. As only landscape data received from the SLD data suppliers is forwardedautomatically, this approach will not fit for all requirements and you maybe have to complement theautomatic forwarding with manual synchronization effort. In addition, you will have to perform the manualupdate of the component information and of the CIM model available from SAP Service Marketplace forevery single SLD (for more information, see SAP Note 669669).

The following figure shows automatic forwarding set up for two SLDs:

Extranet (World Wide Company Network)

Region 1

SAPSystem

SLD

Region 2

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SLD

Automatic forwarding oflandscape data

If you have SLDs with different releases or patch levels in your system landscape, automatic forwarding willstill work as long as you have imported the same CIM data model and SAP CR content versions(downloaded from SAP Service Marketplace – for more information, see SAP Note 669669) in each of theseSLDs.


February 2007 19

3.2.4.2 The Export and Import Functions of SLDIf several SLDs have to contain a consistent view of data not delivered by data suppliers, you can use theexport/import function offered by SLD to manually synchronize them. Simple export and import functionsallow you to export landscape data from one SLD and import it into another SLD manually. To ensure properdistribution of data, you should designate one SLD as the master SLD. You can then use this master SLD toupdate the other SLDs.

The SLD content is divided into the following three categories:

Landscape data (LD)

Component repository data (CR)

Name reservation data (NR)

The export and import functions of SLD support the transport of SLD content for each sub-category as wellas for all data. After an initial “full export”, only changes are exported. These are called “delta exports”. Werecommend that you transport all three categories together (select export line: “ALL” in SLD administration).

Export and import provides best flexibility while it may require considerable operation effort. Therefore, it isonly recommended if you have corresponding requirements (for example, concerning availability) or if youonly have a small amount of manual changes of your SLD data that has to be transported manually.

The following figure shows export and import of SLD data from one SLD to another:


Region 1

SAPSystem

MasterSLD

Region 2

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SAPSystem

SLD

Export and import ofSLD data

When you transport all SLD data from one SLD instance to another, you also update thecomponent data delivered by SAP. Thus, you have to import the SAP CR delta archives into themaster SLD only.

If you have SLDs with different releases or patch levels in your system landscape, export/import will still workas long as you have imported the same CIM data model and SAP CR content versions (downloaded fromSAP Service Marketplace – for more information, see SAP Note 669669) in each of these SLDs.


20 February 2007

3.2.4.3 Outlook to Future Versions of SAP NetWeaverWith the upcoming release of SAP NetWeaver, we plan to provide a fully automatic synchronizationmechanism for all SLD data, that is, data delivered by data suppliers and data entered or changed manuallyin SLD. You will be able to set up this synchronization either uni- or bi-directional. The synchronization willtake place asynchronously, so that a system can be temporary down and synchronizes itself afterwards. Thecommunication for this synchronization takes place over the HTTP protocol.

Depending on your use case, this could dramatically reduce manual synchronization effort. As a result, youshould consider this planned feature – although it is not confirmed yet – for your mid- and long-term SLDstrategy.

Note that this statement is subject to change and may be changed by SAP at any time withoutnotice. This document is not intended to be binding upon SAP to any particular course ofbusiness, product strategy and/or development.

3.2.5 Release CompatibilityYou have to consider three kinds of interdependencies concerning releases:

Between SLDs (synchronization)

If you have SLDs with different releases or patch levels in your system landscape, automatic forwardingand export/import will still work as long as you have imported the same CIM data model and SAP CRcontent versions (downloaded from SAP Service Marketplace – for more information, see SAP Note669669) in each of these SLDs.

Between SLD and SLD data suppliers

An SLD data supplier is used by a system to report landscape data to SLD (write only). For example, thedata supplier of an SAP R/3 system sends landscape data to SLD.

Between SLD and SLD clients

An SLD client is a system that uses data that is stored in SLD (read/write access). For example, a WebDynpro application is an SLD client that reads data from SLD for adaptive RFC calls.

3.2.5.1 Release Compatibility between SLD and SLD Data SuppliersIt is supported but not recommended to connect an SLD data supplier of a system with a higher release to anSLD running on a system with a lower release.

For example, it is supported but not recommended to configure the data supplier of an SAPNetWeaver 2004s system to send data to an SLD running on SAP NetWeaver ’04.

Instead, we recommend that SLD should run on a system with the highest SAP NetWeaver release in yourlandscape. The reason for this recommendation is that it might be that SLD data that was introduced with anew release will be ignored if received by an SLD running on a system with an older release (that is, newSLD parameters sent by a newer data supplier might not get stored in an SLD running on a system with anolder release).


February 2007 21

If you want to connect an SLD data supplier with a higher release to an SLD with a lower release anyhow,make sure that you have imported a new CIM model into your old SLD and check the SLD content regularly.

Within a release, different Support Package Stacks of SLD client and server are supported. Therefore, youcan use any patch sequence within a release for the systems in your landscape on which your SLD serverand your SLD data suppliers run.

3.2.5.2 Release Compatibility between SLD and SLD ClientsIt is not generally supported for an SLD client with a higher release to use an SLD running on a lower release(such as using an SLD running on SAP NetWeaver ’04 for SAP Solution Manager 4.0 based on SAPNetWeaver 2004s). It depends on the actual client application if this is supported – for more information, seeSAP Note 954820 (Compatibility of SLD in the system landscape). Only for the exceptions listed in this SAPNote, this is supported.

For example, it is supported for an SAP NetWeaver 2004s Exchange Infrastructure system to actas SLD client of an SLD running on SAP NetWeaver ’04, as this is listed in the SAP Notementioned above.

We recommend that SLD should run on a system with the highest SAP NetWeaver release in yourlandscape. Within a release, different Support Package Stacks of SLD client and server are supported.Therefore, you can use any patch sequence for your landscape with SLD server and SLD client applicationswithin a release.

3.2.6 How You Can Handle Possible Changes to Your SLD StrategyIf you have to change your strategy in the future for any reason, the following SAP Notes (and related SAPNotes) provide information how to split or merge SLDs:

Make sure that you have the up-to-date version of each SAP Note, which you can find on SAPService Marketplace at service.sap.com/notes.

SAP Note Number Title Description

935474 Grouping SLD instances This SAP Note describes how you can merge twoSLDs by importing the content of one SLD into anotherSLD.

936318 Splitting an SLD instance This SAP Note describes how you can split an SLDinto two or more instances.

935245 Importance of “ObjectServer” SLD parameter

This SAP Note describes the consequences ofchanging the object server, which could be required tosplit or merge SLDs.

720717 Reduce the number ofSystem LandscapeDirectories (SLD)

This SAP Note describes manual actions you have toperform for SAP NetWeaver Exchange Infrastructure /Process Integration if you merge multiple SLDs.


22 February 2007

3.3 Best Practices ScenariosThe following sections outline some typical use cases for the system landscape directory.

3.3.1 Central SLD for All ApplicationsSimplicity is often key for robust and easy system landscape handling. The use of only one central SLD foran entire system landscape is shown below. Possible SLD clients are the SAP NetWeaver ExchangeInfrastructure, SAP Solution Manager, Web Dynpro applications, and the SAP NetWeaver DevelopmentInfrastructure (NWDI). These systems may consist of several instances for development (Dev), qualityassurance (QA), and production (Prod). Nevertheless, all instances are bound to one central SLD. Thisimposes high demand on the SLD regarding stability and availability (concerning operation, maintenance,and upgrade). To fulfill this demand, we recommend that you run your SLD as production system, forexample, by running the AS Java system on which you operate SLD in a high availability cluster.

The following figure shows a central SLD running on an AS Java system realized as high availability cluster:

AS Java Realized asHigh Availability Cluster

CentralMaster SLD

SAPSolutionManager

Prod

QA

Dev

SAPNetWeaver

XI

Prod

QA

Dev

Web DynproWeb Dynpro

Web Dynpro

Dev

ABAPBack EndABAP

Back EndABAPBack End

DevQA

Prod

NWDI

JCO / RFC

QA

Prod


February 2007 23

3.3.2 Separate SLD for Dev/QA and for ProductionTo separate and safeguard the production systems, you can introduce an additional SLD system. This SLDis used for the development and QA systems. Access to the production systems can be restricted totechnical administration users running the production systems. Development and QA systems, as well as therespective staff for development and QA, are only allowed to access the SLD for development and QA. So,the SLD for development and QA does not contain any information about production systems. Therefore, it isnot possible to access production systems during development or testing mistakenly.

The following figure shows a DEV/QA SLD that forwards data to a PROD SLD:

Development and Quality Assurance Systems Production Systems

SLDfor

DEV and QA

SLDfor Overall

System LandscapeTransportof data

SAPSolutionManager

SAPNetWeaver

XI

SAPSolutionManager

QA

DevProd

Prod

SAPNetWeaver

XI

QADev

WebDynproWeb

DynproWeb

Dynpro

ABAPBack EndABAP

Back EndABAP

Back End

Prod

Prod

Dev

Dev

QA

QANWDI

JCO / RFC JCO / RFC


24 February 2007

3.3.3 Separate SLD for NWDIThe SAP NetWeaver Development Infrastructure makes use of SLD as a name server during design time.Nevertheless, development normally requires a high level of changes and updates of SLD data. Thesedevelopment requirements conflict with the requirements of the production systems.

In addition, developers require access to the name server (for example, to create new softwarecomponents), whereas you do not want to grant them access to the landscape SLD. A clear separation ofname server and landscape SLD will ease the fulfillment of this security requirement.

This is why a separate SLD name server for NWDI makes sense for large development divisions.

The following figure shows a landscape with a dedicated name server SLD for NWDI and a landscape SLD:

NetWeaver Development Infrastructure (NWDI) Production, QA and DEV System

Name ServerSLD

for NWDI

LandscapeSLD

Web DynproWeb Dynpro

QA

Web DynproProd

ABAPBack EndABAP

Back End

Dev

QA

ABAPBack End

Prod

JCO / RFC

QA

Dev

Prod

SAPSolutionManager

Prod

QA

Dev

Prod

SAPNetWeaver

XI

Prod

SAP NetWeaverDevelopmentInfrastructure

CMS

CBS

DTR

DeveloperPC

Dev


February 2007 25

3.3.4 SLD for Distributed SAP NetWeaver Exchange InfrastructureLandscapesThe SAP NetWeaver Exchange Infrastructure makes use of SLD in several ways – for more information, seesection SLD Clients [page 11].

The best solution is to have a single SLD (see also sections Central Organization (One Single Central SLD)[page 13] and Central SLD for all Applications [page 22]).

If you require a distributed landscape, you should designate one master SLD that contains the data requiredin all landscapes. The handling of distributed SLDs is explained in section Distributed Organization (SeveralCoupled SLDs) [page 16].

The key principles of distributed SLD operations are:

1. You must transport (export/import) all system data that is crucial for global operation to the master SLD.That means that you consolidate all necessary landscape data in the master SLD.

2. If you want to synchronize this master SLD’s data to all other SLDs, transport it on a regular basis. Thismanual step includes the export of master data and the decentralized import of this data.

The following figure shows the corresponding synchronization mechanism. You transport only individuallandscape objects (technical systems and corresponding business systems) manually from the slave SLDsto the master SLD, before you transport all master SLD data to the slave SLDs.


Region 1

Region 2

SLD

SAPSystem

SAPSystem

SAPNetWeaver

XI

SAPSystem

SAPSystem

MasterSLD

SAPNetWeaver

XI

SAPNetWeaver

XI

SAPNetWeaver

XI

SLD

Dev QA Prod

Transport (export/import)only of individuallandscape objects

Transport (export/import)of all master SLD data

1

2

2

Always transport in one direction to prevent mismatches.

Transport targets of SLD system information must have the same CIM data model versionas the source SLD system or a higher version.


26 February 2007

Another use case for a master SLD in the context of SAP NetWeaver Exchange Infrastructurecould be to provide different views in slave SLDs while having a master SLD that contains alldata.

For example, if you have all business systems (and corresponding technical systems) in amaster SLD to which a central SAP NetWeaver Exchange Infrastructure system is connected,you can send messages from a business system in segment/region A to a receiver system insegment/region B, although the SLDs of regions A and B only contain information of their localsegments.

For more information, see the documentation How-to Guide SAP NetWeaver – How To… Handle the SLDfor SAP XI in SAP Service Marketplace at:service.sap.com/nw04doc How-to Guides Exchange Infrastructure.

3.3.5 SLD for Distributed DevelopmentLarge and multinational companies tend to spread development departments all over the world. This may bedue to cost effectiveness (offshoring) or organizational reasons. Nevertheless, it is essential for eachregional development department to have SLD data locally available. The availability of a local SLD in eachregion enables quick responses and saves network traffic.

Forwarding of landscape data can be used to provide global back-end access in distributed Web Dynprodevelopment landscapes.

The following figure shows the automatic forwarding of landscape data from the SLD in region 2 to the SLDin region 1:


Region 1 Region 2

SLD

Automatic forwardingof SLD data for

back end systemsSLD

Back-EndSystemsBack-End

Systems

Back-EndSystemsBack-EndSystems

Back-EndSystemsPCs

runningIDE

Back-EndSystemsBack-End

Systems

Back-EndSystems

Back-EndSystems

Back-EndSystemsPCs

runningIDE


Back-EndSystemsPCs

runningIDE


Back-EndSystemsPCs

runningIDE


February 2007 27

3.4 Network Access ScenariosThis section shows SLD scenarios with special respect to networking aspects.

3.4.1 Intranet ScenarioIntranet means the use of Internet techniques within a corporate network. Although corporate networksincorporate different kinds of networks, such as LAN, WAN, VPN, or leased lines, the existence of companywide naming and addressing rules ensures direct addressing and communication between all servers.

The non-existence of barriers like firewalls and NAT (Network Address Translation) allows you to use bothSAP load balancing solutions, the SAP Message Server redirect mechanism as well as the new SAP WebDispatcher.

The load balancing solution will distribute requests to a clustered AS Java system on which SLD is running.

The following figure shows the intranet scenario:

BusinessSystem

BusinessSystem

BusinessSystem

BusinessSystem

BusinessSystem

AS Java(multiple nodes)AS Java

(multiple nodes)AS Java(multiple nodes)

SAP WebDispatcher

orReverse Proxy Lo

ad b

alan

cing

Load

bal

anci

ngus

ing

mes

sage

ser

ver

redi

rect

ion

Business systemslocated within the

company‘s network

Business systemslocated within the LAN

SLD running on aclustered AS Java system


28 February 2007

3.4.2 Extranet ScenarioExtranets extend the range of the Intranet. Well-known systems – for example, systems of business partners– get access to certain servers within the Intranet. These business systems are normally connected overpoint-to-point access through VPN or leased lines but not over public networks. Nevertheless, these systemsare not allowed to access the whole corporate network but only a few dedicated servers. This restriction isnormally accomplished by employing some kind of reverse proxy within the DMZ (Demilitarized Zone). Thisproxy forwards the requests to permissible servers.

SAP provides the SAP Web Dispatcher for use as HTTP reverse proxy and load balancer. SAProuter can beused to check and forward RFC connections.

The following figure shows the extranet scenario:

BusinessSystem

BusinessSystem

BusinessSystem

SLD(multiple servers)SLD

(multiple servers)SLD(multiple servers)

Business systemslocated within the LAN

SAP WebDispatcheror Reverse

Proxy

SAProuter

BusinessSystem

withRFC based

communication

BusinessSystem

withHTTP based

communication

VPN Tunnel

VPN Tunnel

Leasedline

Leasedline

DMZ(demilitarized zone)

Well known businesssystems located inremote networks

Acc

ess

Rou

ter

Fire

wal

l

Load

bal

anci

ng


February 2007 29

3.5 Where to Run SLD in Your System LandscapeThere are different options where to run your SLD in your SAP NetWeaver landscape. Each option hasdifferent advantages and disadvantages. You can use the following points as a basis for your decision-making:

SLD standalone system:This is the most flexible way to run SLD.

Factor Explanation

+ Release independency Applications are not affected by the upgrade of your SLD system, asSLD is backward-compatible.

+ Flexibility As there are no direct interdependencies between the SLD system andan application system, it is easier to plan and perform changes – forexample, it is easier to plan the downtime of an application system, asyou do not have to consider SLD availability requirements.

- Cost You have to operate and maintain an additional system.

Running SLD integrated with an SAP application (for example, SAP NetWeaver ExchangeInfrastructure):This is the easiest and cheapest way to run SLD.

Factor Explanation

+ Cost You do not have to operate and maintain an additional system.

+ Availability Availability is the same as of the application – if the application system isup, SLD is also available. If the system is down, SLD is not available, butthis should not be critical, as the application is down as well.

- Release dependency Applications are affected by the upgrade of your SLD and vice versa.

- Flexibility SLD depends on the application and vice versa – for example, if youplan the downtime of an application system, you have to consider SLDavailability requirements as well.

Running SLD on a shared services system:

Factor Explanation

+ Centralization ofadministrative tasks

SLD is running on the central administration and monitoring system aswell

+ Cost You do not have to operate and maintain an additional system for SLDonly.

+ Availability Availability is the same as of the shared services – if the centraladministration and monitoring system is up, SLD is also available. If thesystem is down, SLD is not available, but the shared services that relyon SLD are down as well.

- Release dependencies Shared services are affected by the upgrade of your SLD and viceversa.

- Flexibility SLD depends on the shared services and vice versa – for example, ifyou plan the downtime of the central administration and monitoringsystem, you have to consider SLD availability requirements as well.


30 February 2007

- Continuous availability If SLD is critical for your landscape, the central administration andmonitoring system needs to be continuously available (that is, specificruntime and maintenance procedures may be required to ensurecontinuous operation).

For more information about shared services (such as SAP Solution Manager and SAPNetWeaver Administrator) and examples how to run these shared services in an SAPNetWeaver landscape together with SLD, also see the Master Guide – SAP NetWeaveravailable in SAP Service Marketplace at service.sap.com/instguides SAP NetWeaver

<Release>.

3.5.1 Overall Recommendations

If you have separate environments (for example, as you separated your production environmentfrom your development and test environment), be aware that the following recommendationsshould be considered for every separate environment.

If possible, we recommend that you use one system landscape directory server.

If you do not run applications that critically rely on the availability of the system landscape directoryand that are critical for you, we recommend that you use one system landscape directory. You couldrun this system landscape directory on the central administration and monitoring system (that is, theSAP NetWeaver Administrator system), on an application system or standalone on a dedicatedsystem.

If you use exactly one application that critically relies on the availability of the system landscapedirectory and that is critical for you, we recommend that you run at least your production SLD on thesystem together with this critical application.

If you use more than one application that critically relies on the availability of the system landscapedirectory and that is critical for your business, we recommend that you have one dedicated master SLDand additional System Landscape Directories running on these application systems.

To keep your system landscape directories synchronized, you may have to perform manualexports/imports. This approach provides good availability while it may require considerable operationeffort. Therefore, it is only recommended if you have high requirements concerning availability or if youonly have a small amount of manual changes of your system landscape directory data that has to betransported manually.

The following figure shows a flow diagram that gives a recommendation according to your use case:


February 2007 31

ABAP-onlylandscape?

SLD is optional – if required, runone SLD on a dedicated system or

on the SAP NetWeaverAdministrator system

Number ofapplicationsthat critically

rely onavailability ofSLD and thatare critical?

Run SLD on a dedicated system,on an application system or on

the SAP NetWeaver Administratorsystem

0

Run SLD on the system togetherwith this critical application

1

Run either one production SLD(such as on a HA system) or adedicated master SLD + additionalSLDs on the critical applicationsystems

> 1

Yes

No

The following sections give more information about each of these cases.


32 February 2007

3.5.2 No SLD-Critical ApplicationIf no SLD critical application exists in your landscape, you may choose between flexibility and TCO. RunningSLD integrated with the application that requires SLD is easy and causes minimum TCO. Running SLDstandalone or in the central administration system ensures maximum flexibility.

3.5.2.1 Standalone SLD SystemThe following figure shows a standalone SLD system:

Non-Critical Applications

SAPSystem

SAPSystem

Master SLD

SLD

SAP NetWeaverApplication Server

3.5.2.2 SLD Integrated with the ApplicationThe following figure shows an SLD running on an application system:


SAPSystem

SAPSystem

SLD

SAP NetWeaver Application Server

Non-Critical

Application

Master SLD


February 2007 33

3.5.2.3 SLD on a Centralized Administration ServerFor SAP NetWeaver, we recommend that you group administration and monitoring components andfunctions of SAP NetWeaver, like SAP NetWeaver Administrator and central user administration, on onehost. You can optionally run SAP Solution Manager on this host as well, but in a separate system. For moreinformation about this centralized administration and monitoring, see the Master Guide – SAP NetWeaveravailable in SAP Service Marketplace at service.sap.com/instguides SAP NetWeaver<Release>.

On this centralized administration server, you can optionally run a central SLD.

The following figure shows an SLD running on a central administration and monitoring system with SAPNetWeaver Administrator, central user administration (CUA), and software lifecycle manager of SAPNetWeaver:


SAPSystem

SAPSystem

Central Administration and Monitoring

CUA

SAPNetWeaver

Admini-strator

SLD

SLM

SAPSolutionManager



3.5.3 One SLD-Critical ApplicationThe best way to ensure SLD availability to the critical application is to run SLD integrated with the criticalapplication. If the critical application is up and running, SLD is up and running as well. This is a good way in asmall landscape regarding TCO. Nevertheless, with respect to flexibility in a growing landscape, you shouldhave a look to next section using several SLDs.

The following figure shows an SLD running on an application system:


SAPSystem

SAPSystem

Critical Application(For Example SAP NetWeaver XI)

SLD

SAP NetWeaver Application Server

SAPNetWeaver

XI


34 February 2007

3.5.4 Several SLD-Critical ApplicationsIf several applications critically depend on SLD information, you can run one production SLD system if youmake sure that it is continuously available (that is, specific runtime and maintenance procedures may berequired to ensure continuous operation).

Another option is to run one master SLD and several SLDs integrated with each critical application. This willensure SLD availability to these applications. Nevertheless, with several SLDs, you require a synchronizationconcept for your SLD data.

3.5.4.1 Standalone Master SLD SystemThe following figure shows a standalone master SLD and several slave SLDs running on applicationsystems:

Critical Application(For Example,

SAP NetWeaver XI)

SLD


SAPNetWeaver

XI

Critical Application(For Example, NWDI)

Critical Web DynproApplication

SLD


NWDI SLD


WebDynpro

MasterSLD


Central Master SLD


SAPSystem

SAPSystem

Manual consolidation and synchronization:

1) All data you require globally is mergedinto the master SLD

2) Consolidated data is distributed

With several SLDs, you require a synchronization concept for your SLD data. For more information, seesection Synchronization Strategies [page 17].


February 2007 35

3.5.4.2 Central Administration SystemThe following figure shows a master SLD running on a central administration and monitoring system andseveral slave SLDs running on application systems:

Central Administration and Monitoring

CUA

SAPNetWeaver

Admini-strator

MasterSLD

SLM

SAPSolutionManager



Critical Application –(For Example,

SAP NetWeaver XI)

SLD

SAP NetWeaverApplication System

SAPNetWeaver

XI

Critical Application –(For Example, NWDI)

Critical Web DynproApplication

SLDNWDI SLDWebDynpro


SAPSystem

SAPSystem

Manual consolidation and synchronization:

1) All data you require globally is mergedinto the master SLD

2) Consolidated data is distributed



With several SLDs, you require a synchronization concept for your SLD data. For more information, seesection Synchronization Strategies [page 17].


36 February 2007

4 Overview of Connections to and from SLDThe following figure gives you an overview of all communication paths to and from the SLD. On the right side(bullets 1 to 3), the figure shows the SLD data suppliers. They send actual system landscape data to SLD.SLD clients on the left side are capable of interacting with the SLD. This means they can retrieve, send, andupdate system landscape data with SLD.

The following figure shows all communication paths that the following sections explain:

SLD Server

SLD Client

SLD Bridge

Java

SLD SystemABAP

Application

SAP System

ABAP

Application

ABAP

Application

SLD Server

SLD Client

LCRABAP API

Java

SLD System

Application

JCO RFC

Application

Application

Java

SAP System

SAP Gateway

JCO RFC

Java

SAP SystemSystem notbased on

SAPNetWeaver

sidregC++ Programm

HTT

P

RFC

RFC

RFC

HTTP/S

HTTP/SHTTP/S (WBEM)

SLD Clients Data Supplier

1

3

2

4

5

5

5

6

SLD Bridge

SLD Client

LCRABAP API

4.1 ABAP Data Supplier (1)ABAP data suppliers must send their data to the SLD bridge by using RFC. The destination is a JavaConnector (JCo), which is registered with the gateway and provides the connection to the SLD bridgerunning in the Java environment.

4.2 Java Data Supplier (2)Java data suppliers send their data directly to the SLD bridge using the HTTP / HTTPS protocol.


February 2007 37

4.3 External Data Supplier (3)Applications not running on the SAP NetWeaver Application Server may use sldreg to send theirlandscape data. sldreg can be used as an interface to send the data to the SLD bridge using the HTTP /HTTPS protocol.

4.4 Java SLD Client (4)The SLD Java client is able to interact directly with the SLD server using the HTTP / HTTPS protocol.

4.5 ABAP SLD Client (5)An SLD ABAP client cannot communicate with the SAP server directly. The first communication step is withan RFC server (RFC destination LCRABAP-API) registered with a gateway. The LCRABAP server interfaceswith the SLD client, which communicates with SLD using the HTTP / HTTPS protocol.

4.6 SLD to SLD Message Forwarding (6)Data suppliers send their messages only to the SLD bridge to which they are connected. Nevertheless, youcan configure each SLD bridge to forward all incoming data supplier messages to other SLD bridges as well.You can use this forwarding mechanism to update or synchronize several SLDs in large IT landscapes. Formore information, see section Automatic Forwarding of Landscape Data [page 17].

01_planning guide - system landscape directory

Documents