View
116
Download
1
Category
Preview:
Citation preview
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
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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.
Planning Guide – System Landscape Directory
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.
Planning Guide – System Landscape Directory
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]
Planning Guide – System Landscape Directory
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.
Planning Guide – System Landscape Directory
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].
Planning Guide – System Landscape Directory
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…)
Monitoring & Management Connectivity Layer(JMX, Agents…)
Productive Landscape
Central Monitoring& Administration
System
SAP NetWeaverAdministrator
SLD SolutionManager
ABAPSystem
JavaSystem
Non-SAPComponent
Monitoring & Management Connectivity Layer(JMX, Agents…)
Monitoring & Management Connectivity Layer(JMX, Agents…)
Productive Landscape
Central Monitoring& Administration
System
SAP NetWeaverAdministrator
Central Monitoring& Administration
System
Central Monitoring& Administration
System
SAP NetWeaverAdministrator
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:
Planning Guide – System Landscape Directory
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>.
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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.
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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)
Planning Guide – System Landscape Directory
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.
Planning Guide – System Landscape Directory
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:
Extranet (World Wide Company Network)
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.
Planning Guide – System Landscape Directory
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).
Planning Guide – System Landscape Directory
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.
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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.
Extranet (World Wide Company Network)
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.
Planning Guide – System Landscape Directory
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:
Extranet (World Wide Company Network)
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-EndSystemsBack-EndSystems
Back-EndSystemsPCs
runningIDE
Back-EndSystemsBack-EndSystems
Back-EndSystemsPCs
runningIDE
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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
Planning Guide – System Landscape Directory
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.
Planning Guide – System Landscape Directory
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:
Planning Guide – System Landscape Directory
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.
Planning Guide – System Landscape Directory
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:
Non-Critical Applications
SAPSystem
SAPSystem
SLD
SAP NetWeaver Application Server
Non-Critical
Application
Master SLD
Planning Guide – System Landscape Directory
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:
Non-Critical Applications
SAPSystem
SAPSystem
Central Administration and Monitoring
CUA
SAPNetWeaver
Admini-strator
SLD
SLM
SAPSolutionManager
SAP NetWeaverApplication Server
SAP NetWeaverApplication Server
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:
Non-Critical Applications
SAPSystem
SAPSystem
Critical Application(For Example SAP NetWeaver XI)
SLD
SAP NetWeaver Application Server
SAPNetWeaver
XI
Planning Guide – System Landscape Directory
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
SAP NetWeaverApplication Server
SAPNetWeaver
XI
Critical Application(For Example, NWDI)
Critical Web DynproApplication
SLD
SAP NetWeaverApplication Server
NWDI SLD
SAP NetWeaverApplication Server
WebDynpro
MasterSLD
SAP NetWeaverApplication Server
Central Master SLD
Non-Critical Applications
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].
Planning Guide – System Landscape Directory
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
SAP NetWeaverApplication Server
SAP NetWeaverApplication Server
Critical Application –(For Example,
SAP NetWeaver XI)
SLD
SAP NetWeaverApplication System
SAPNetWeaver
XI
Critical Application –(For Example, NWDI)
Critical Web DynproApplication
SLDNWDI SLDWebDynpro
Non-Critical Applications
SAPSystem
SAPSystem
Manual consolidation and synchronization:
1) All data you require globally is mergedinto the master SLD
2) Consolidated data is distributed
SAP NetWeaverApplication System
SAP NetWeaverApplication System
With several SLDs, you require a synchronization concept for your SLD data. For more information, seesection Synchronization Strategies [page 17].
Planning Guide – System Landscape Directory
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.
Planning Guide – System Landscape Directory
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].
Recommended