Planning Guide
System
Landscape Directory
Document Version 1.45 – July 2007
© Copyright 2007 SAP AG. All rights reserved.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and
other SAP products and services mentioned herein as well as their
No part of this publication may be reproduced or transmitted in any
respective logos are trademarks or registered trademarks of SAP AG
form or for any purpose without the express permission of SAP AG.
in Germany and in several other countries all over the world. All other
The information contained herein may be changed without prior
product and service names mentioned are the trademarks of their
notice.
respective companies. Data contained in this document serves
informational purposes only. National product specifications may
Some software products marketed by SAP AG and its distributors
vary.
contain proprietary software components of other software vendors.
These materials are subject to change without notice. These materials
Microsoft, Windows, Outlook, and PowerPoint are registered
are provided by SAP AG and its affiliated companies ("SAP Group")
trademarks of Microsoft Corporation.
for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex,
omissions with respect to the materials. The only warranties for SAP
MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries,
Group products and services are those that are set forth in the express
xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity,
warranty statements accompanying such products and services, if any.
Tivoli, and Informix are trademarks or registered trademarks of IBM
Nothing herein should be construed as constituting an additional
Corporation in the United States and/or other countries.
warranty.
Oracle is a registered trademark of Oracle Corporation.
SAP Library document classification: PUBLIC
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the
Disclaimer
Open Group.
Some components of this product are based on Java™. Any code
change in these components may cause unpredictable and severe
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame,
malfunctions and is therefore expressively prohibited, as is any
VideoFrame, and MultiWin are trademarks or registered trademarks of
decompilation of these components.
Citrix Systems, Inc.
Any Java™ Source Code delivered with this product is only to be used
HTML, XML, XHTML and W3C are trademarks or registered
®
trademarks of W3C , World Wide Web Consortium, Massachusetts
by SAP’s Support Services and may not be modified or altered in any
way.
Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
Documentation in the SAP Service Marketplace
You can find this documentation at the following Internet address:
JavaScript is a registered trademark of Sun Microsystems, Inc., used
under license for technology invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
service.sap.com/sld
Planning Guide – System Landscape Directory
Document History
Before you start planning, make sure you have the latest version of this document. You can find
the 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
1.45
July 2007
Description
In sections Automatic Forwarding of Landscape Data and Release
Compatibility, changed statement concerning required CIM data models
and SAP CR content versions of SLDs that synchronize data using
automatic forwarding – in contrast to the former statement, automatic
forwarding works independent of releases, patch levels, and installed
CIM data models and SAP CR content versions of the involved SLDs, as
the SLD bridge forwards data without interpreting or changing it.
Added section Central SLD Running on a Production System.
Minor changes
1.44
June 2007
Added section Sizing of a System for the System Landscape Directory
Minor changes
1.43
March 2007
Changed statement concerning circular forwarding in section Automatic
Forwarding of Landscape Data, as SAP NetWeaver 7.0 Support
Package Stack 11 became available.
Added information about SAP NetWeaver Process Integration in section
SLD Clients.
Minor changes
1.42
February 2007
Added section SLD Clients.
Added section Release Compatibility.
In section Automatic Forwarding of Landscape Data, removed the note
box with information about the behavior for SAP NetWeaver 2004. The
described behavior only occurs if you set a specific SLD parameter for
SAP NetWeaver 2004 or for older SLD releases – so, for most cases,
this note box did not apply, automatic forwarding in most cases works
the same for SAP NetWeaver 2004 and SAP NetWeaver 7.0.
Changed section Outlook to Future Versions of SAP NetWeaver.
Minor changes
July 2007
3
Planning Guide – System Landscape Directory
Contents
1
Introduction.................................................................................................................... 5
1.1
1.2
1.3
Structure of the Planning Guide............................................................................... 5
More Information..................................................................................................... 5
Accessing the SAP Library...................................................................................... 6
2
Overview ....................................................................................................................... 7
3
SLD Topology................................................................................................................ 8
3.1
Process to Define Your SLD Landscape Strategy.................................................... 8
3.2
Fundamental SLD Concepts ................................................................................. 10
3.2.1 SLD Clients ....................................................................................................... 10
3.2.2 Fundamental Landscape Scenarios................................................................... 12
3.2.3 Reasons to Have Several SLDs......................................................................... 15
3.2.4 Synchronization Strategies ................................................................................ 16
3.2.5 Release Compatibility........................................................................................ 19
3.2.6 How You Can Handle Possible Changes to Your SLD Strategy ......................... 20
3.3
Best Practices Scenarios ...................................................................................... 21
3.3.1 Central SLD for All Applications ......................................................................... 21
3.3.2 Separate SLD for Dev/QA and for Production .................................................... 22
3.3.3 Separate SLD for NWDI .................................................................................... 23
3.3.4 SLD for Distributed SAP NetWeaver Process Integration Landscapes ............... 24
3.3.5 SLD for Distributed Development....................................................................... 25
3.4
Network Access Scenarios.................................................................................... 26
3.4.1 Intranet Scenario ............................................................................................... 26
3.4.2 Extranet Scenario.............................................................................................. 27
3.5
Where to Run SLD in Your System Landscape ..................................................... 28
3.5.1 Overall Recommendations................................................................................. 29
3.5.2 No SLD-Critical Application................................................................................ 30
3.5.3 One SLD-Critical Application ............................................................................. 32
3.5.4 Several SLD-Critical Applications....................................................................... 33
3.5.5 Sizing of a System for System Landscape Directory .......................................... 37
4
Overview of Connections to and from SLD ................................................................... 39
4.1
4.2
4.3
4.4
4.5
4.6
4
ABAP Data Supplier (1) ........................................................................................ 39
Java Data Supplier (2) .......................................................................................... 39
External Data Supplier (3) ..................................................................................... 40
Java SLD Client (4)............................................................................................... 40
ABAP SLD Client (5)............................................................................................. 40
SLD to SLD Message Forwarding (6) .................................................................... 40
July 2007
Planning Guide – System Landscape Directory
1 Introduction
This documentation provides you with a central starting point for the planning of your landscape strategy for
the system landscape directory of SAP NetWeaver®.
1.1 Structure of the Planning Guide
The planning guide consists of the following sections:
Introduction
Contains information about this documentation and related information important for the planning of the
system 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 system
landscape directory based on your requirements. You get information about landscape scenarios, best
practices and recommendations on which host you could run the system landscape directory in your
system 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 Information
The following list contains links to information about the system landscape directory on SAP Service
Marketplace and in the SAP Library:
Content
Location on SAP Service Marketplace or in the
SAP Library
Information about the system landscape directory
and corresponding documentation
service.sap.com/sld
Configuring and using the system landscape
directory
User Manual – SLD:
Platform and Technology Information Center
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
NetWeaver Security Guide
Information about the technical operation of SAP
NetWeaver
July 2007
service.sap.com/sld
Media Library
SAP
Technical Operations Manual:
Located in the SAP Library [page 6] at SAP
NetWeaver Library
Administrator’s Guide
Technical Operations Manual for SAP NetWeaver
5
Planning Guide – System Landscape Directory
1.3 Accessing the SAP Library
Access 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 recommend
that 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, you
need a PC running Microsoft Windows to install the HTMLHelp Viewer.
6
July 2007
Planning Guide – System Landscape Directory
2 Overview
The 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 software
life-cycle. It contains a description of your system landscape (that is, the software components that are
currently installed) and a repository of software components that can theoretically be installed in your
landscape (such as the software components available from SAP). Since the landscape description gets
updated automatically, SLD provides reliable and up-to-date information with minimized effort for you. In this
way, SLD acts as a central information provider for SAP and third-party tools that use this data to deliver 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 system
landscape directory is part of SAP NetWeaver. This abbreviation is solely intended to improve
readability.
July 2007
7
Planning Guide – System Landscape Directory
3 SLD Topology
3.1 Process to Define Your SLD Landscape Strategy
You can introduce and run SLD in your SAP NetWeaver landscape in many different ways. Each of these
ways has different advantages and disadvantages. Therefore, you should plan the introduction of SLD
properly according to your landscape requirements.
The following figure shows a possible process to get an individual strategy how and where to run SLD in your
system landscape:
How and where to
run 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 master
SLD, 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 10]
Fundamental Landscape Scenarios [page 10]
Reasons to Have Several SLDs [page 15]
Synchronization Strategies [page 16]
Release Compatibility [page 19]
How You Can Handle Possible Changes to Your SLD Strategy [page 19]
8
July 2007
Planning Guide – System Landscape Directory
2. You decide how many SLDs you require. For this, get a clear picture of the requirements that your
system 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 and
impact 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 large
physical distance between an SLD client and your SLD itself or improper hardware performance of
the 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 the
requirement to restrict access to data of production systems for developers)
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 21]
Network Access Scenarios [page 26]
In addition, see SAP Note 764393 (Configuration of the SAP System Landscape Directory) that contains
further information about the required number of SLD instances in a landscape.
Make sure that you have up-to-date versions of SAP Notes, which you can find on SAP Service
Marketplace at service.sap.com/notes.
As a result of this step, you should get an idea if a central SLD fits your requirements or how many
distributed SLDs you require.
3. If you require more than one SLD, you have to think about synchronizing the SLD data stored in your
SLDs. For this, create a model to understand which data is required in which of your planned SLDs. In
addition, you might want to restrict the forwarding of certain data to certain SLDs in your landscape to
generate different views.
For example, you maybe do not want to forward data of your production systems into a
development SLD.
If manual synchronization is required, we recommend that you create some kind of operation
manual that helps to establish a process when and how synchronization should be performed by
whom.
In addition, see SAP Note 764393 (Configuration of the SAP System Landscape Directory) that contains
further information about synchronizing SLD instances in a landscape.
As a result of this step, you should receive a synchronization strategy for your SLDs.
July 2007
9
Planning Guide – System Landscape Directory
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 shared
services or business functions (for example, your SAP NetWeaver Process Integration system) on an
existing system.
To a certain degree, this also results from the requirements you are facing in your landscape concerning
SLD (for example, high availability features, planned/unplanned downtime, load of the corresponding
host, network connection). For more information, see section Where to Run SLD in Your System
Landscape [page 28].
3.2 Fundamental SLD Concepts
3.2.1 SLD Clients
The following figure shows applications and tools that provide services by using the data that is stored in
SLD – for this, these so-called SLD clients read data from and write data to SLD:
J2EE
Backend
Server
Business
Data
Web Service
Provider
Business
Data
Web
Service
EJB (e.a.)
RMI
ABAP
Backend
Business
Backend
Backend Application
Application
Server
Data
RFC enabled
Function Modules
RFC
SOAP
Retrieve storage location
of dev. configuration
J2EE
Web Dynpro
Runtime
Deployed Web
Deployed Web
Dynpro App
Dynpro App
SAP
NetWeaver
Developer
Studio
ABAP
Web Dynpro
Runtime
SLD
Web Dynpro
Web Dynpro
App
App
Retrieve dev.
configuration
ABAP development
Workbench
HTTP(S)
Register dev.
configuration
CMS (Landscape Configurator)
DTR
Web Dynpro
Application
Development
Objects
SAP Enterprise Portal
CBS
/workspace
/buildspace
Binaries of
used SCs
/inactive
/active
Web Dynpro Runtime
Development Configuration
Software Lifecycle Manager
of SAP NetWeaver
SAP NetWeaver
Development Infrastructure
SLD
…
SAP NetWeaver
Process Integration
Other Clients
Central Monitoring
& Administration
System
SAP NetWeaver
Administrator
Adaptive Computin g Controller
Solution Manager
Solution
Manager
SLD
Cont rol Node
Centralized
Storage System
Productive Landscape
Monitoring
Monitoring&&Management
ManagementConnectivity
ConnectivityLayer
Layer
(JMX,
(JMX,Agents…)
Agents…)
Server Network Switch
ABAP
System
Java
System
Non-SAP
Component
Computing
Nodes
SAP NetWeaver Administrator
Storage Network Switch
SAP Solution Manager
Adaptive Computing
Controller
10
July 2007
Planning Guide – System Landscape Directory
SAP NetWeaver Process Integration (SAP NetWeaver Exchange Infrastructure) has several SLD use
cases:
SLD acts as a server for business system names (these have to be associated with the
corresponding technical systems received from their data suppliers). It is used:
For the receiver determination in the Integration Directory of SAP NetWeaver Process
Integration.
By application systems to get their own business system name (Java Proxy Framework and
SAP systems).
Therefore, you must make sure that all business systems (and the corresponding technical systems)
that an SAP NetWeaver Process Integration system communicates with are available in the SLD that
is used by this SAP NetWeaver Process Integration system.
In SLD, you create transport targets for Integration Directory content transports. These transport
targets define which system in one environment (DEV, TEST, QA, PROD) corresponds to which
system in another environment.
For example, you define that the business system BSD in your development environment
corresponds to a business system BSQ in your quality assurance environment and that the SAP
NetWeaver Process Integration system XID in your development environment corresponds to
XIQ in your quality assurance environment.
If you now transport configuration objects from one environment to the other, the corresponding
systems from the source environment will be mapped to the target environment during the import.
For example, if you have configured that a message is sent from XID to BSD in your
development environment, this configuration will be changed to XIQ
BSQ in your quality
assurance environment.
As a result, if your SAP NetWeaver Process Integration systems use more than one SLD, propagate
business systems (and the corresponding technical systems) in addition from DEV to TEST, from
TEST to QA, and from QA to PROD so that each SLD contains the business systems from its
environment and from the environment of its predecessor SLD:
DEV SLD requires only information about DEV business systems, as no business systems get
imported from other environments
QA SLD requires information about the business systems from both DEV and QA environments,
as business systems from DEV are imported and mapped to business systems from QA
PROD SLD requires information about the business systems from both QA and PROD
environment, as business systems from QA are imported and mapped to business systems from
PROD
For example, you have to transport all business systems + corresponding technical systems
from the SLD that is used by XID to the SLD that is used by XIQ to be able to define the
mapping mentioned above in the SLD of the QA environment.
July 2007
11
Planning Guide – System Landscape Directory
The Integration Repository of SAP NetWeaver Process Integration requires information about
products and software component versions. This information is stored in the SLD. You have to make
sure that this component repository data is available in every SLD that is used by SAP NetWeaver
Process Integration. For this, we recommend that you transport this data (export/import).
You could also create products and software component versions directly in the target SLD
again instead of transporting them from a source SLD. Nevertheless, the GUIDs (globally unique
identifier) of the software component versions have to be identical in both the source and the
target SLD, which is assured by transporting this data.
SLD provides all systems and adapter engines for the end-to-end monitoring in the Runtime
Workbench of SAP NetWeaver Process Integration.
SLD provides the address for the transfer of adapter configuration data from the Integration Directory
to the adapter cache.
You can use SAP Solution Manager to implement, train, test, maintain, monitor, control change, and
manage incidents of your SAP solution system landscape (open end-to-end application management),
for which SAP Solution Manager requires a system data repository. For this, SLD is used.
SAP NetWeaver Administrator retrieves landscape data from the SLD. It requires this information for
remote monitoring functions.
Web Dynpro of Java uses the SLD to find destination information for ABAP systems and Web services
for 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 its
operation (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 lifecycle
manager retrieves landscape data from the SLD and enriches this data with additional information (like
information of business scenarios that run in a system landscape).
For more information about SAP NetWeaver Process Integration, SAP Solution Manager, SAP
NetWeaver Administrator, SAP NetWeaver Development Infrastructure, Adaptive Computing
Controller, or the software lifecycle manager of SAP NetWeaver, see the Master Guide – SAP
NetWeaver available in SAP Service Marketplace at service.sap.com/instguides
SAP
NetWeaver
<Release>.
3.2.2 Fundamental Landscape Scenarios
The 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 system
landscape.
For all landscape scenarios, the use of DNS aliases to address SLD makes it possible to switch SLD hosts
very easily. This may be necessary for maintenance (updates) and upgrades. For example, you could install
12
July 2007
Planning Guide – System Landscape Directory
a new AS Java system with a higher release, configure SLD on this new system, import the data of your
actual SLD into the new SLD and switch to this new SLD. This way, you have “upgraded” to a higher release
with minimal SLD downtime.
3.2.2.1
Central Organization (One Single Central SLD)
The easiest scenario is to have a single system landscape directory that acts as a central information
provider for the enterprise system landscape. All systems in your system landscape, including all sub
networks, share a single system landscape directory that contains information about the whole system
landscape.
The advantages of using a single system landscape directory for the entire system landscape are consistent
data, easier administration, and lower operating expense.
The following figure shows a corresponding example:
Extranet
Intranet
Intranet
SAP
System
Intranet
SAP
System
SAP
System
SAP
System
SLD
SAP
System
SAP
System
3.2.2.2
SAP
System
Distributed Organization (Several Distributed SLDs)
A more flexible approach is the use of several distributed SLDs. However, the effort and cost to operate your
SLD landscape increases due to required manual model and content updates in all SLDs and possible
regular synchronization activities.
Hierarchical Organizations (One Central SLD with Decentralized Sub-SLDs)
This organizational form incorporates several fully separated divisions headed by the headquarters. The
local division’s SLD serves all local needs. Automatic forwarding of landscape data from all divisions
accumulates as the complete system landscape in the headquarters’ SLD.
The following figure shows a hosting scenario with separate customer system landscapes. Each customer
landscape incorporates its own SLD containing data about this customer’s landscape only. The hosting
provider itself must have access to the system landscape of all customers. To achieve this, you configure the
July 2007
13
Planning Guide – System Landscape Directory
sub-SLDs to forward automatically all landscape data to a master SLD for the hosting provider. So, you can
use a hierarchical organization of several SLDs to create different views of your landscape.
Hosting Provider
SLD
Customer 1
Customer 2
SAP
System
SAP
System
Automatic forwarding
of landscape data
SLD
SLD
SAP
System
SAP
System
SAP
System
SAP
System
Another use case is an application development landscape comprising development, test, and production
systems. The data is forwarded from the development SLD to the test SLD and then to the production SLD.
Fully Separated Organizations (Several Standalone SLDs)
You can use several SLDs for fully separated management of data independent of each other, as shown in
the following figure:
Extranet
Intranet
Intranet
SAP
System
SLD
SAP
System
SAP
System
14
Intranet
SAP
System
SAP
System
SLD
SAP
System
July 2007
Planning Guide – System Landscape Directory
Distributed Organization (Several Coupled SLDs)
Global or widely distributed IT landscapes may require more than a central SLD. It is then expected that an
SLD is locally available but that it provides a more than local view. You can achieve this by coupling several
distributed SLDs that exchange all or only certain of their SLD data.
The following figure shows a corresponding example:
Extranet
Region 2
Region 1
SAP
System
SAP
System
Synchronization
SLD
SLD
SAP
System
SAP
System
SAP
System
SAP
System
3.2.3 Reasons to Have Several SLDs
There may be several reasons to have more than one system landscape directory. For example, if you have
geographically distributed locations with local administration groups that want to see only their local systems
in the system landscape directory.
In addition, several system landscape directories may be required if you want to isolate your production
environment. By having a system landscape directory dedicated for your production systems, you make sure
that these systems are not visible from your development or test environment.
Having more than one system landscape directory also gives you the possibility to test content imports, CIM
data model updates, and patches first before performing them in the system landscape directory used for
your production environment.
An important reason to have several system landscape directories is to provide improved availability of the
information stored in the system landscape directory. This information could be essential for applications
running in your production landscape. The following list shows examples of SAP NetWeaver applications for
which the availability of the system landscape directory can be critical:
For SAP NetWeaver Process Integration, availability of the system landscape directory is required at
restart of SAP NetWeaver Process Integration. As used system landscape directory caches may be
invalidated manually, the system landscape directory is also critical during runtime for SAP NetWeaver
Process Integration.
For Web Dynpro of Java, the system landscape directory is critical during runtime for adaptive RFC calls.
July 2007
15
Planning Guide – System Landscape Directory
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 monitoring
functions of Adaptive Computing Controller are available.
If the system landscape directory is not available, no login to SAP NetWeaver Development
Infrastructure is allowed. In addition, no name registration can be performed. As a result, Java
development might be impaired if SAP NetWeaver Development Infrastructure is used or if the system
landscape directory is run as name server.
For more information about SAP NetWeaver Process Integration, SAP NetWeaver Administrator,
Adaptive Computing Controller, and SAP NetWeaver Development Infrastructure, see the
Master Guide – SAP NetWeaver available in SAP Service Marketplace at
service.sap.com/instguides
SAP NetWeaver
<Release>.
3.2.4 Synchronization Strategies
To support the operation of several SLDs, we provide automatic message forwarding as well as
sophisticated data export and import functions.
3.2.4.1
Automatic Forwarding of Landscape Data
To keep separate SLDs informed about changes of specific landscape data, you can configure the SLD
bridge to forward data to other SLD instances. With automatic forwarding, the SLD allows direct server-toserver 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)
As of SAP NetWeaver 7.0 Support Package Stack 11, circular forwarding is fully supported.
If your SLDs run on SAP NetWeaver 7.0 systems with Support Package Stack 10 or on a lower
release/Support Package Stack, we do not recommend to set up a circular exchange of data
between two or more SLDs with automatic forwarding – although the original sender does not
forwarded his data again (after the original sender received his data from the other SLD), the
original sender will write an error message in its log file that the data received by automatic
forwarding is already contained in its local SLD.
Any changes and entries that you entered manually into SLD (for example, business systems required for
SAP NetWeaver Process Integration, component repository extensions, or name reservation data) cannot be
forwarded automatically and stays within the local SLD only. The same restriction applies for data written by
other applications such as SAP NetWeaver Process Integration or SAP Solution Manager.
16
July 2007
Planning Guide – System Landscape Directory
Therefore, with automatic forwarding, you get the flexibility to run several SLDs in your system landscape
with little manual effort. As only landscape data received from the SLD data suppliers is forwarded
automatically, this approach will not fit for all requirements and you maybe have to complement the
automatic forwarding with manual synchronization effort. In addition, you will have to perform the manual
update of the component information and of the CIM model available from SAP Service Marketplace for
every single SLD (for more information, see SAP Note 669669).
The following figure shows an automatic forwarding set up for two SLDs:
Extranet (World Wide Company Network)
Region 1
Region 2
SAP
System
SAP
System
Automatic forwarding of
landscape data
SLD
SLD
SAP
System
SAP
System
SAP
System
SAP
System
As the SLD bridge forwards data without interpreting or changing it, automatic forwarding works independent
of releases, patch levels, and installed CIM data models and SAP CR content versions of the involved SLDs.
3.2.4.2
The Export and Import Functions of SLD
If several SLDs have to contain a consistent view of data not delivered by data suppliers, you can use the
export/import function offered by SLD to manually synchronize them. Simple export and import functions
allow you to export data from one SLD and import it into another SLD manually. To ensure proper distribution
of data, you should designate one SLD as the master SLD. You can then use this master SLD to update 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 well
as for all data. After an initial “full export”, only changes are exported. These are called “delta exports”. We
recommend 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 is
only recommended if you have corresponding requirements (for example, concerning availability) or if you
only have a small amount of manual changes of your SLD data that has to be transported manually.
July 2007
17
Planning Guide – System Landscape Directory
The following figure shows the export and import of SLD data from one SLD to another:
Extranet (World Wide Company Network)
Region 2
Region 1
SAP
System
SAP
System
Master
SLD
SAP
System
SLD
Export and import of
SLD data
SAP
System
SAP
System
SAP
System
When you transport all SLD data from one SLD instance to another, you also update the
component data delivered by SAP. Thus, you have to import the SAP CR delta archives into the
master SLD only.
If you have SLDs with different releases or patch levels in your system landscape, export/import will still 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 these SLDs.
3.2.4.3
Outlook to Future Versions of SAP NetWeaver
With the upcoming release of SAP NetWeaver, we plan to provide a fully automatic synchronization
mechanism for all SLD data, that is, data delivered by data suppliers and data entered or changed manually
in SLD. You will be able to set up this synchronization either uni- or bi-directional. The synchronization will
take place asynchronously, so that a system can be temporary down and synchronizes itself afterwards. The
communication for this synchronization takes place over the HTTP protocol.
Depending on your use case, this could dramatically reduce manual synchronization effort. As a result, you
should consider this planned feature – although it is not confirmed yet – for your mid- and long-term SLD
strategy.
Note that this statement is subject to change and may be changed by SAP at any time without
notice. This document is not intended to be binding upon SAP to any particular course of
business, product strategy and/or development.
18
July 2007
Planning Guide – System Landscape Directory
3.2.5 Release Compatibility
You have to consider three kinds of interdependencies concerning releases:
Between SLDs concerning synchronization:
Automatic forwarding:
As the SLD bridge forwards data without interpreting or changing it, automatic forwarding works
independent of releases, patch levels, and installed CIM data models and SAP CR content versions
of the involved SLDs.
Export/import:
If you have SLDs with different releases or patch levels in your system landscape, export/import will
still 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 these SLDs.
Between SLD and SLD data suppliers
An SLD data supplier is used by a system to report landscape data to SLD (write access only). For
example, the data 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 Web
Dynpro 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 Suppliers
It is supported but not recommended to connect an SLD data supplier of a system with a higher release to an
SLD running on a system with a lower release.
For example, it is supported but not recommended to configure the data supplier of an SAP
NetWeaver 7.0 system to send data to an SLD running on SAP NetWeaver 2004.
Instead, we recommend that SLD should run on a system with the highest SAP NetWeaver release in your
landscape. The reason for this recommendation is that it might be that SLD data that was introduced with a
new release will be ignored if received by an SLD running on a system with an older release (that is, new
SLD parameters sent by a new data supplier might not get stored in an SLD running on a system with an
older release).
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 data model version 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, you
can use any patch sequence within a release for the systems in your landscape on which your SLD server
and your SLD data suppliers run.
3.2.5.2
Release Compatibility between SLD and SLD Clients
It 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 2004 for SAP Solution Manager 4.0 based on SAP
NetWeaver 7.0). It depends on the actual client application if this is supported – for more information, see
SAP Note 954820 (Compatibility of SLD in the system landscape) that gives information about released
combinations of SLD server and SLD client releases.
July 2007
19
Planning Guide – System Landscape Directory
For example, it is supported for an SAP NetWeaver 7.0 Process Integration system to act as
SLD client of an SLD running on SAP NetWeaver 2004, as this is listed in the SAP Note
mentioned above.
We recommend that SLD should run on a system with the highest SAP NetWeaver release in your
landscape. Within a release, different Support Package Stacks of SLD client and SLD are supported.
Therefore, you can use any patch sequence for your landscape with SLD and SLD client applications within
a release.
3.2.6 How You Can Handle Possible Changes to Your SLD Strategy
If you have to change your strategy in the future for any reason, the following SAP Notes (and related SAP
Notes) 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 SAP
Service Marketplace at service.sap.com/notes.
SAP Note Number
Title
Description
935474
Grouping SLD instances
This SAP Note describes how you can merge two
SLDs by importing the content of one SLD into another
SLD.
936318
Splitting an SLD instance
This SAP Note describes how you can split an SLD
into two or more instances.
935245
Importance of “Object
Server” SLD parameter
This SAP Note describes the consequences of
changing the object server, which could be required to
split or merge SLDs.
720717
Reduce the number of
System Landscape
Directories (SLD)
This SAP Note describes manual actions you have to
perform for SAP NetWeaver Process Integration /
Process Integration if you merge multiple SLDs.
20
July 2007
Planning Guide – System Landscape Directory
3.3 Best Practices Scenarios
The following sections outline some typical use cases for the system landscape directory.
3.3.1 Central SLD for All Applications
Simplicity is often key for robust and easy system landscape handling. The use of only one central SLD for
an entire system landscape is shown below. The SLD clients may consist of several systems for
development (Dev), quality assurance (QA), and production (Prod). Nevertheless, all systems are bound to
one central SLD. This imposes 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, for example, 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 with high availability:
AS Java with
High Availability
Dev
QA
Prod
SAP
Solution
Manager
Central
Master SLD
QA
NWDI
Dev
Dev
Web Dynpro
Prod
Web Dynpro
Web Dynpro
QA
Prod
SAP
NetWeaver
PI
JCO / RFC
Dev
ABAP
QA
ABAP
Back
Prod End
Back End
ABAP
Back End
July 2007
21
Planning Guide – System Landscape Directory
3.3.2 Separate SLD for Dev/QA and for Production
To separate and safeguard the production systems, you can introduce an additional SLD system. This SLD
is used for the development and QA systems. Access to the production systems can be restricted to
technical administration users running the production systems. Development and QA systems, as well as the
respective 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 is
not 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
Dev
Prod
QA
SAP
Solution
Manager
SLD
SLD
for
DEV and QA
for Overall
System Landscape
Transport
of data
SAP
Solution
Manager
Dev
QA
Prod
SAP
NetWeaver
PI
SAP
NetWeaver
PI
Dev
Web
QA
Dynpro
Web
Dynpro
JCO / RFC
Prod
Web
Dynpro
JCO / RFC
Dev
NWDI
22
ABAP
QA
Back End
ABAP
Back End
Prod
ABAP
Back End
July 2007
Planning Guide – System Landscape Directory
3.3.3 Separate SLD for NWDI
The 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. These
development requirements conflict with the requirements of the production systems.
In addition, developers might require access to the name server (for example, to create new software
components – if this is not performed by a central administration team), whereas you do not want to grant
them access to the landscape SLD. A clear separation of name server and landscape SLD will ease the
fulfillment of this security requirement.
This is why a separate SLD name server for NWDI can make 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
Dev
SAP NetWeaver
Development
Infrastructure
CMS
QA
Prod
Prod
Name Server
SLD
for NWDI
Landscape
SLD
SAP
Solution
Manager
CBS
Dev
QA
Dev
DTR
Developer
PC
QA
Web Dynpro
Prod
Web Dynpro
Web Dynpro
Prod
Prod
SAP
Business
System
JCO / RFC
Dev
ABAP
QA
Back End
ABAP
Prod
Back End
ABAP
Back End
July 2007
23
Planning Guide – System Landscape Directory
3.3.4 SLD for Distributed SAP NetWeaver Process Integration
Landscapes
SAP NetWeaver Process Integration (SAP NetWeaver Exchange Infrastructure) makes use of SLD in
several ways – for more information, see section SLD Clients [page 10].
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 21]).
If you require a distributed landscape, you should designate one master SLD that contains the data required
in all landscapes. The handling of distributed SLDs is explained in section Distributed Organization (Several
Coupled SLDs) [page 15].
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. This
manual 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 individual
landscape objects (technical systems and corresponding business systems) manually from the slave SLDs
to the master SLD, before you transport all master SLD data to the slave SLDs.
Extranet (World Wide Company Network)
Region 1
Transport (export/import)
only of individual
landscape objects
SAP
System
1
Master
SLD
2
SAP
System
Region 2
SLD
Transport (export/import)
of all master SLD data
2
Dev
QA
Prod
SAP
NetWeaver
PI
SAP
NetWeaver
PI
SAP
NetWeaver
PI
SAP
System
SAP
NetWeaver
PI
SAP
System
SLD
Always transport in one direction to prevent mismatches.
Transport targets of SLD system information must have the same CIM data model version
as the source SLD system or a higher version.
24
July 2007
Planning Guide – System Landscape Directory
Another use case for a master SLD in the context of SAP NetWeaver Process Integration could
be to provide different views in slave SLDs while having a master SLD that contains all data.
For example, if you have all business systems (and corresponding technical systems) in a
master SLD to which a central SAP NetWeaver Process Integration system is connected, you
can send messages from a business system in segment/region A to a receiver system in
segment/region B, although the SLDs of regions A and B only contain information of their local
segments.
For more information, see the documentation How-to Guide SAP NetWeaver – How To… Handle the SLD
for SAP XI in SAP Service Marketplace at:
service.sap.com/nw04doc
How-to Guides
Exchange Infrastructure.
3.3.5 SLD for Distributed Development
Large and multinational companies tend to spread development departments all over the world. This may be
due to cost effectiveness (offshoring) or organizational reasons. Nevertheless, it is essential for each
regional development department to have SLD data locally available. The availability of a local SLD in each
region enables quick responses and saves network traffic.
Forwarding of landscape data can be used to provide global back-end access in distributed Web Dynpro
development landscapes.
The following figure shows the automatic forwarding of landscape data from the SLD in region 2 to the SLD
in region 1:
Extranet (World Wide Company Network)
Region 1
Region 2
Back-End
Back-End
Systems
Systems
Back-End
Back-End
Systems
Systems
Automatic forwarding
of SLD data for
back end systems
SLD
SLD
Back-End
PCs
Back-End
Systems
running
Systems
IDE
Back-End
PCs
Back-End
Systems
running
Systems
IDE
Back-End
PCs
Back-End
Systems
running
Systems
IDE
July 2007
Back-End
PCs
Back-End
Systems
running
Systems
IDE
25
Planning Guide – System Landscape Directory
3.4 Network Access Scenarios
This section shows SLD scenarios with special respect to networking aspects.
3.4.1 Intranet Scenario
Intranet means the use of Internet techniques within a corporate network. Although corporate networks
incorporate different kinds of networks, such as LAN, WAN, VPN, or leased lines, the existence of company
wide 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 both
SAP load balancing solutions, the SAP Message Server redirect mechanism as well as the new SAP Web
Dispatcher.
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:
Business systems
located within the
company‘s network
Business
System
Load balancing
using
message server
redirection
Business
System
Business systems
located within the LAN
SLD running on a
clustered AS Java system
SAP Web
Dispatcher
or
Reverse Proxy
Business
System
26
Load balancing
AS Java
AS Java
(multiple
nodes)
AS
Java
(multiple
nodes)
(multiple nodes)
Business
System
Business
System
July 2007
Planning Guide – System Landscape Directory
3.4.2 Extranet Scenario
Extranets 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 over
point-to-point access through VPN or leased lines but not over public networks. Nevertheless, these systems
are not allowed to access the whole corporate network but only a few dedicated servers. This restriction is
normally accomplished by employing some kind of reverse proxy within the DMZ (Demilitarized Zone). This
proxy forwards the requests to permissible servers.
SAP provides the SAP Web Dispatcher for use as HTTP reverse proxy and load balancer. SAProuter can be
used to check and forward RFC connections.
The following figure shows the extranet scenario:
Well known business
systems located in
remote networks
DMZ
(demilitarized zone)
Business systems
located within the LAN
Business
System
VPN
Business
System
T unn
el
SAP Web
Dispatcher
or Reverse
Proxy
Firewall
Access Router
Leased
line
Load balancing
with
HTTP based
communication
SLD
SLDservers)
(multiple
SLDservers)
(multiple
(multiple servers)
Business
System
SAProuter
Leased
line
Business
System
with
RFC based
communication
July 2007
NT
VP
el
unn
Business
System
27
Planning Guide – System Landscape Directory
3.5 Where to Run SLD in Your System Landscape
There are different options where to run your SLD in your SAP NetWeaver landscape. Each option has
different advantages and disadvantages. You can use the following points as a basis for your decisionmaking:
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, as
SLD is backward-compatible.
+ Flexibility
As there are no direct interdependencies between the SLD system and
an application system, it is easier to plan and perform changes – for
example, it is easier to plan the downtime of an application system, as
you 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 Process Integration):
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 for one
application
Availability is the same as of the application – if the application system is
up, SLD is also available. If the system is down, SLD is not available, but
this 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 you
plan the downtime of an application system, you have to consider SLD
availability requirements as well.
Running SLD on a shared services system:
28
Factor
Explanation
+ Centralization of
administrative tasks
SLD is running on the central administration and monitoring system as
well
+ Cost
You do not have to operate and maintain an additional system for SLD
only.
+ Availability for shared
services
Availability is the same as of the shared services – if the central
administration and monitoring system is up, SLD is also available. If the
system is down, SLD is not available, but the shared services that rely
on SLD are down as well.
- Continuous availability
If SLD is critical for your landscape, the central administration and
monitoring system needs to be continuously available (that is, specific
runtime and maintenance procedures may be required to ensure
continuous operation).
- Release dependencies
Shared services are affected by the upgrade of your SLD and vice
versa.
- Flexibility
SLD depends on the shared services and vice versa – for example, if
you plan the downtime of the central administration and monitoring
system, you have to consider SLD availability requirements as well.
July 2007
Planning Guide – System Landscape Directory
For more information about shared services (such as SAP Solution Manager and SAP
NetWeaver Administrator) and examples how to run these shared services in an SAP
NetWeaver landscape together with SLD, also see the Master Guide – SAP NetWeaver
available 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 environment
from your development and test environment), be aware that the following recommendations
should 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 directory
and that are critical for you, we recommend that you use one system landscape directory. You could
run this system landscape directory on the central administration and monitoring system (that is, the
SAP NetWeaver Administrator system), on an application system or standalone on a dedicated
system.
If you use exactly one application that critically relies on the availability of the system landscape
directory and that is critical for you, we recommend that you run at least your production SLD on the
system together with this critical application.
If you use more than one application that critically relies on the availability of the system landscape
directory and that is critical for your business, we recommend that you:
Either have a central system landscape directory running in production mode (such as running on a
high availability system)
Or have one dedicated master system landscape directory and additional system landscape
directories running on these application systems. To keep your system landscape directories
synchronized, you may have to perform manual exports/imports. This approach provides good
availability while it may require considerable operation effort. Therefore, this is only recommended if
you have high requirements concerning availability or if you only have a small amount of manual
changes of your system landscape directory data that has to be transported manually.
The following figure shows a flow diagram that gives a recommendation according to your use case:
July 2007
29
Planning Guide – System Landscape Directory
ABAP-only
landscape?
Yes
SLD is optional – if required, run
one SLD on a dedicated system or
on the SAP NetWeaver
Administrator system
0
Run SLD on a dedicated system,
on an application system or on
the SAP NetWeaver Administrator
system
No
Run either one production SLD
(such as on a HA system) or a
dedicated master SLD + additional
SLDs on the critical application
systems
Number of
applications
that critically
rely on
availability of
SLD and that
are critical?
>1
1
Run SLD on the system together
with this critical application
The following sections give more information about each of these cases.
3.5.2 No SLD-Critical Application
If no SLD critical application exists in your landscape, you may choose between flexibility and TCO. Running
SLD integrated with the application that requires SLD is easy and causes minimum TCO. Running SLD
standalone or in the central administration system ensures maximum flexibility.
3.5.2.1
Standalone SLD System
The following figure shows a standalone SLD system:
SLD System
SLD
SAP NetWeaver
Application Server
30
Non-Critical Applications
SAP
System
SAP
System
July 2007
Planning Guide – System Landscape Directory
3.5.2.2
SLD Integrated with the Application
The following figure shows an SLD running on an application system:
Application System
NonCritical
Application
Non-Critical Applications
SAP
System
SLD
SAP
System
SAP NetWeaver Application Server
3.5.2.3
SLD on a Centralized Administration Server
For SAP NetWeaver, we recommend that you group administration and monitoring components and
functions of SAP NetWeaver, like SAP NetWeaver Administrator and central user administration, on one
host. You can optionally run SAP Solution Manager on this host as well, but in a separate system. For more
information about this centralized administration and monitoring, see the Master Guide – SAP NetWeaver
available 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 SAP
NetWeaver Administrator, central user administration (CUA), and software lifecycle manager of SAP
NetWeaver:
Central Administration and Monitoring
SAP
Solution
Manager
SAP NetWeaver
Application Server
July 2007
SAP
NetWeaver
Administrator
SLD
CUA
SLM
Non-Critical Applications
SAP
System
SAP
System
SAP NetWeaver
Application Server
31
Planning Guide – System Landscape Directory
3.5.3 One SLD-Critical Application
The best way to ensure SLD availability to the critical application is to run SLD integrated with the critical
application. If the critical application is up and running, SLD is up and running as well. This is a good way in a
small landscape regarding TCO. Nevertheless, with respect to flexibility in a growing landscape, you should
have a look to next section using several SLDs.
The following figure shows an SLD running on an application system:
Critical Application
(For Example SAP NetWeaver XI)
SAP
NetWeaver
PI
SLD
SAP NetWeaver Application Server
32
Non-Critical Applications
SAP
System
SAP
System
July 2007
Planning Guide – System Landscape Directory
3.5.4 Several SLD-Critical Applications
If several applications critically depend on SLD information, you can run one production SLD system if you
make sure that it is continuously available (that is, specific runtime and maintenance procedures may be
required to ensure continuous operation). For this, you can either run SLD on a dedicated highly available
(HA) system or run SLD on a production application system that is highly available.
Another option is to run one master SLD and several SLDs integrated with each critical application. This will
ensure SLD availability to these applications. Nevertheless, with several SLDs, you require a synchronization
concept for your SLD data.
3.5.4.1
Central SLD Running on a Production System
The following figure shows a central SLD running on a production system that is highly available (HA):
Critical Application
(For Example,
SAP NetWeaver XI)
Critical Application
(For Example, NWDI)
Critical Web Dynpro
Application
SAP
NetWeaver
PI
NWDI
Web
Dynpro
SAP NetWeaver
Application Server
SAP NetWeaver
Application Server
SAP NetWeaver
Application Server
Non-Critical Applications
SLD
SAP NetWeaver
Application Server
SAP
System
SAP
System
Central SLD Running
on an HA System
July 2007
33
Planning Guide – System Landscape Directory
The following figure shows a central SLD running on a production application system that is highly available:
Critical Application
(such as NWDI)
Critical Web Dynpro
Application
Critical Web Dynpro
Application
NWDI
Web
Dynpro
Web
Dynpro
SAP NetWeaver
Application Server
SAP NetWeaver
Application Server
SAP NetWeaver
Application Server
Central SLD Running
on a Production
Application System
(such as
SAP NetWeaver PI)
SAP
NetWeaver
PI
SLD
Non-Critical Applications
SAP
System
SAP
System
SAP NetWeaver
Application Server
34
July 2007
Planning Guide – System Landscape Directory
3.5.4.2
Standalone Master SLD System
The following figure shows a standalone master SLD and several slave SLDs running on application
systems:
Critical Application
(For Example,
SAP NetWeaver XI)
SAP
NetWeaver
PI
SLD
SAP NetWeaver
Application Server
Critical Application
(For Example, NWDI)
NWDI
SLD
SAP NetWeaver
Application Server
Critical Web Dynpro
Application
Web
Dynpro
SLD
SAP NetWeaver
Application Server
Non-Critical Applications
Master
SLD
SAP
System
Manual consolidation and synchronization:
1) All data you require globally is merged
into the master SLD
2) Consolidated data is distributed
SAP NetWeaver
Application Server
SAP
System
Central Master SLD
With several SLDs, you require a synchronization concept for your SLD data. For more information, see
section Synchronization Strategies [page 16].
July 2007
35
Planning Guide – System Landscape Directory
3.5.4.3
Central Administration System
The following figure shows a master SLD running on a central administration and monitoring system and
several slave SLDs running on application systems:
Critical Application –
(For Example,
SAP NetWeaver XI)
SAP
NetWeaver
PI
SLD
Critical Application –
(For Example, NWDI)
NWDI
SLD
SAP NetWeaver
Application System
SAP NetWeaver
Application System
Critical Web Dynpro
Application
Web
Dynpro
SLD
SAP NetWeaver
Application System
Manual consolidation and synchronization:
Central Administration and Monitoring
1) All data you require globally is merged
into the master SLD
2) Consolidated data is distributed
SAP
Solution
Manager
SAP NetWeaver
Application Server
SAP
NetWeaver
Administrator
Master
SLD
CUA
SLM
Non-Critical Applications
SAP
System
SAP
System
SAP NetWeaver
Application Server
With several SLDs, you require a synchronization concept for your SLD data. For more information, see
section Synchronization Strategies [page 16].
36
July 2007
Planning Guide – System Landscape Directory
3.5.5 Sizing of a System for System Landscape Directory
The following sections provide relevant considerations to size a system used for the system landscape
directory.
3.5.5.1
Hardware
As a starting point, we recommend that you stick to the recommendation for an AS Java system given in the
implementation documentation of SAP NetWeaver. This normally fits most use cases of the system
landscape directory. For large use case scenarios, you can perform normal AS Java sizing.
For more information about:
Hardware recommendations given in the implementation documentation, see SAP Service Marketplace
at service.sap.com/instguidesnw
Sizing of SAP NetWeaver in general, see SAP Service Marketplace at service.sap.com/sizing
For example, we recommend to run the system landscape directory of SAP NetWeaver 7.0 at
least on a host with a 64-bit dual core CPU with not less than 4 GB of RAM and on up-to-date
hardware for the other parts as well (like disks, etc.).
Running the system landscape directory on more powerful hardware should reduce the
processing times assumed below for the estimation of the system load.
3.5.5.2
System Design
We recommend that you run the system landscape directory on a non-clustered system. If you run the
system landscape directory of SAP NetWeaver 2004 or SAP NetWeaver 7.0 on a clustered system, make
sure to disable the cache of the system landscape directory. For more information, see SAP Note 825116.
If you plan to run the system landscape directory on a system shared by several applications, be aware that
all applications running shared on this system will compete for hardware resources.
3.5.5.3
Estimation of System Load
The following rule of thumb helps you to judge the hardware requirements based on the load in a system
landscape directory caused by SLD data suppliers.
To compute the data received by one SLD data supplier, we assume the following maximum processing
times for the system landscape directory (based on the hardware listed above):
10 seconds for data received from the data supplier of an ABAP system
30 seconds for data received from the data supplier of a Java system
July 2007
37
Planning Guide – System Landscape Directory
For example, if you have 60 ABAP and 30 Java systems connected to your system landscape
directory and each of these systems sends data twice a day (which correlates to the standard
data supplier configuration), you would get a maximum processing time for data suppliers of 50
minutes (60 ABAP systems * 2 messages per system and day * 10 seconds/per message + 30
Java systems * 2 messages per system and day * 30 seconds/per message = 3000 seconds per
day = 50 minutes per day).
These assumptions do not consider peak loads of the system landscape directory. So, it could be a problem
for the system landscape directory if all data suppliers send updates at the same time. As a result, we
recommend that you add further reserves and use factors of safety.
Also, if you want to reduce the load of your system landscape directory, you could consider to reduce the
frequency how often data suppliers send updates to the system landscape directory and try to deconcentrate
the time when the single data suppliers send updates to the system landscape directory. For example, by
reducing the update frequency from twice to once a day, you halve the corresponding processing time to
handle data supplier data in the system landscape directory.
In our example, a system as proposed above could process the data of the data suppliers of
both over 1000 ABAP and 1000 Java systems, but only if the updates are sent spread over the
day. As this can hardly be guaranteed, you should restrict the number to several hundred
connected systems, reduce the update frequency or use a stronger host.
In addition, load is generated by UI access (browsing data in the system landscape directory) and clients that
read data from and write data into the system landscape directory (such as SAP NetWeaver Administrator,
SAP NetWeaver Process Integration, and SAP Solution Manager). The corresponding load is hard to judge
as it strongly depends on your system landscape and how you use the single clients that rely on the system
landscape directory.
38
July 2007
Planning Guide – System Landscape Directory
4 Overview of Connections to and from SLD
The 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, and
update system landscape data with SLD.
The following figure shows all communication paths that the following sections explain:
SLD Clients
Data Supplier
SLD System
SAP System
Java
Java
Application
SLD Client
HTTP/S
)
(WBEM
3
SLD Server
SLD Client
4
/S
TP
HT
SLD Bridge
SAP System
HTT
P/S
JCO RFC
ABAP
Application
5
JCO RFC
RFC
2
SAP Gateway
C
RF
ABAP
Application
5
SLD System
HTTP
Application
Application
1
SAP System
Java
Application
RF
C
ABAP
System not
based on
SAP
NetWeaver
LCRABAP API
LCRABAP API
5
sidreg
C++ Programm
Java
SLD Server
SLD Client
6
SLD Bridge
4.1 ABAP Data Supplier (1)
ABAP data suppliers must send their data to the SLD bridge by using RFC. The destination is a Java
Connector (JCo), which is registered with the gateway and provides the connection to the SLD bridge
running 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.
July 2007
39
Planning Guide – System Landscape Directory
4.3 External Data Supplier (3)
Applications not running on the SAP NetWeaver Application Server may use sldreg to send their
landscape 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 with
an RFC server (RFC destination LCRABAP-API) registered with a gateway. The LCRABAP server interfaces
with 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, you
can 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. For
more information, see section Automatic Forwarding of Landscape Data [page 16].
40
July 2007