SAP System Landscape Directory

SAP System Landscape DirectoryPurposeA modern computing environment consists of a number of hardware and software components that depend on each other with regard to installation, software updates, and demands on interfaces. The SAP System Landscape Directory (SLD) simplifies the administration of your system landscape.

The SLD is a server application that communicates with a client application by using the Hypertext Transfer Protocol (HTTP). The SLD server containscomponent information, alandscape description, and aname reservation, which are based on the standardCommon Information Model (CIM). The CIM standard is a general schema for describing the elements in a system landscape. This standard is independent of any implementation.

FeaturesThe component description provides information about all available SAP software modules. This includes version numbers, current patch level, and dependencies between landscape components. SAP makes this information available to its customers. You can download the current component description from SAP Service Marketplace, which then updates your local component description (see SAP Note 669669). It is also possible to add instances for third-party components to the component description.

The system landscape description represents the exact model of an actual system landscape. Together with the current component description, the system description provides information for various processes (the system administration and implementation, for example).The example below shows a possible scenario that illustrates how the component and system landscape description functions.

ExampleOn the left-hand side of the following graphic is the master description for all existing SAP software modules. SAP maintains this information. The local component description on the right-hand side (client side) can be updated in accordance with the master description.An installed mySAP.com component is registered in the System Landscape Directory. The component description contains information about the installed components. If, for example, a new Support Package is available for this component, SAP publishes this information using the master description. In this way, the customers receive all the latest information relevant for their system landscape promptly.

Architecture and System Landscape (BW-BPS)DefinitionThere are three basic possibilities for configuring BW and BW-BPS systems.

1. Centralized: BW system and BW-BPS share data, structure and database.2. Remote: BW-BPS (local) has a remote connection to the BW system (remote).3. Separate: Separation of BW system functions and BW-BPS functions.These configuration options do not restrict the functionality or the features of BW-BPS, they simply address different business requirements.

UseThere are three areas which need particular consideration when defining and implementing BW-BPS applications: System availability Performance Patches and upgradesIt is also important to remember that the BW system is also used by non-BW-BPS users. As a result, the following key issues arise:

Cost-efficiency, legal and security requirements Periodic usage of planning tools Data redundancies Data integration - combining and using plan data and non-BW-BPS data conjointly Routine work and work related to patches and upgrades Administration work and costs System costsChoosing the right system configuration is very important. It is possible to switch from one configuration to another but this involves a large outlay in terms of time, costs, and administrative efforts.The most important characteristics of the different system configuration options named above will now be listed.

Centralized The BW system and BW-BPS are on the same server/system; they use the same system landscape (DEV, QA, PROD). The data and structures are stored on the same server in the same database. BW patches and upgrades are implemented simultaneously for the BW system and for BW-BPS.Remote The BW system and BW-BPS are on different servers/systems. BW-BPS (local) has a remote connection to the BW system (remote). BW-BPS is configured in the local BW-BPS system. Data and structures are stored on the same database. BW-BPS only uses the structures of the remote BW system. BW-BPS reads and writes data straight from the remote BW system. BW patches and upgrades are implemented on the respective servers for the BW system and for BW-BPS and can therefore be implemented independently of each other.Separate The BW system and BW-BPS run on different systems that are independent of each other. Configuration, structures and data from the BW system and BW-BPS are stored on different (that is their own) servers and databases. Users of BW-BPS and the general BW systems use different (that is their own) system landscapes (DEV, QA, PROD). Data from BW-BPS and the BW system can be loaded to and from each system using BW data marts. BW patches and upgrades are implemented on the respective servers for the BW system and for BW-BPS and can therefore be implemented independently of each other.Advantages and Disadvantages of System Configuration OptionsThe following table offers an overview of the advantages and disadvantages of these three options:

following table offers an overview of the advantages and disadvantages of these three options:

CentralizedRemoteSeparateData integrationNo data redundancyEase of system maintenanceAccess to planning and reportingLow costs for system landscapeSeparation of BW and BW-BPSEase of security setup/maintenanceReduced release-dependencyAbility to fine-tune