SAP System Landscape Directory

SAP System Landscape Directory

Purpose
A 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 contains component information, a landscape description, and a name reservation, which are based on the standard Common 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.

Features
The 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.

Example
On 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)

Definition
There 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.

Use
There are three areas which need particular consideration when defining and implementing BW-BPS applications:
· System availability
· Performance
· Patches and upgrades
It 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 costs
Choosing 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 Options
The 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:

Centralized
Remote
Separate
Data integration
No data redundancy
Ease of system maintenance
Access to planning and reporting
Low costs for system landscape
Separation of BW and BW-BPS
Ease of security setup/maintenance
Reduced release-dependency
Ability to fine-tune