3 Configuring the System Landscape Directory
Finally we shall place the Sun himself at the center of the Universe.
—Nicolaus Copernicus
The System Landscape Directory (SLD) plays a critical role in an SAP system landscape. As a central repository, it manages information about all installable and installed elements of your system landscape in your organization. The repository includes a list of SAP and non-SAP systems from a technical and business perspective, and the information available is used by other SAP applications, such as SAP Process Orchestration (SAP PO), SAP Solution Manager, SAP NetWeaver Administrator, and the SAP NetWeaver development infrastructure.
You can access the SLD via http://<hostname>:<port>/sld, where <hostname> is the hostname of the SAP NetWeaver system and <port> is the port number of the SAP NetWeaver system. The SLD is a Java-based component that can be installed on an SAP NetWeaver Application Server for Java (SAP NetWeaver AS Java). The SLD is included in the SAP_JTECHT software component (SC) delivered by SAP.
3.1 System Landscape Directory Components and Features
To fulfill its role of central information repository for the entire system landscape, the SLD facilitates easy access to the information of different systems and software. In the System Landscape Directory landing page (see Figure 3.1), the information is categorized in the following sections or categories:
- Landscape
- Software Catalog
- Development
In the next sections, we’ll explore each of these categories in more detail.
3.1.1 Landscape
The Landscape category includes functionalities covering the maintenance of technical systems, landscapes, and business systems.
Technical Systems
Technical systems are SAP and non-SAP backend applications in your landscape. Any SAP components (SAP ERP Human Capital Management [SAP ERP HCM], SAP Customer Relationship Management [SAP CRM], etc.), SAP NetWeaver applications, third-party applications, or legacy systems in your landscape can be considered technical systems to be maintained in your SLD. If an application registers itself with the SLD (as discussed in Section 3.2), then a technical system will be created in the SLD to represent it.
Assume that an SAP CRM system has a system ID of ECD. In that case, a technical system with the name ECD will be created in the SLD. As demonstrated in Figure 3.2, a lot of information about the ECD system is maintained in the SLD. Some of this information includes the following:
- System name
- Hostname of the server
- Version number of the system
- Type of system
- When the data was last updated
- Details about the database (see the Database tab)
- List of existing clients (see the Clients tab)
- Details of the message server of the application
If a system wasn’t automatically registered in the SLD (especially in the case of a third-party system), then you can manually create a new technical system. To do so, click the New Technical System button (as shown in Figure 3.2) and follow the wizard. You’ll be required to specify the type of technical system to be created. The possible choices include the following:
-
SAP NetWeaver AS ABAP
Systems with an SAP NetWeaver AS ABAP. Most SAP backend systems will fit into this category. -
SAP NetWeaver AS Java
Systems with SAP NetWeaver AS Java. Such a system can consist of one or multiple instances. -
Standalone
Standalone Java applications. -
Third-party
Systems containing third-party (non-SAP) applications and products.
Landscapes
Landscapes provide the facility to group systems in a logical manner. A landscape can be seen as a development environment that includes a number of servers and applications intended for a specific stage in a release process.
For each landscape, you can create a group in the SLD and include all applications and systems belonging to that stage. To create a new landscape for the development stage, follow these steps:
- Choose Landscape from the System Landscape Directory landing page.
- Click on New Landscape to define a new landscape.
- Add all the relevant systems belonging to this stage (see Figure 3.3).
You can add systems to a particular landscape by performing the following steps:
- Select the desired landscape.
- Click the Systems tab.
- Click the Add System button.
- Choose the type of system from the Type dropdown.
- Select the desired system, and click OK.
Business Systems
A business system is a logical name given to a particular system or application. In general, the business system name is unique in the landscape and is used in an SAP PO scenario to represent the system or application as a sender or receiver. There is a direct relationship between a business system and a technical system. Every technical system can have at least one business system. For an SAP ABAP backend system, every client can have its own business system. This is only relevant for SAP NetWeaver AS ABAP systems because SAP NetWeaver AS Java-based systems aren’t partitioned in clients.
Figure 3.4 depicts a situation with a technical system called TS_A that has two clients (100 and 200). Each client is linked to a different business system—namely, BS_A and BS_B.
Note
The backend systems (ABAP) regularly retrieve their business system names from the SLD. If the SLD becomes unavailable, then the SAP backend system won’t be able to update its current business system name and might be using an outdated business system name that it keeps in its cache.
You can perform all management tasks from the SLD: create, update, delete, and search or filter on business systems. Compared to technical systems (which are created automatically when the application systems register themselves to the SLD), the business systems need to be manually created. To create a business system, follow these steps:
- From the System Landscape Directory landing page, choose Business Systems • New Business System to start the wizard.
- Select the type of technical system that the new business system will be linked with.
- In the next step of the wizard, you’ll be asked to choose the related technical system and client (for the ABAP system).
- Give your business system a logical name.
- Choose the products and SCs that are installed in your business systems.
-
Select the role of your business system. The following options are available:
-
Application System
This option will be used most of the time and is relevant whenever the business system to be added represents a backend application or system, in which case, it’s required to specify its related integration server. The related integration server represents the SAP Process Integration (SAP PI)/SAP PO system that will act as the enterprise service bus (ESB) for the business system in question (see Figure 3.5). -
Integration Server
This is relevant in cases in which the system in question is middleware: an SAP PI or SAP PO system.
-
Application System
A business system can be described by a number of attributes. After selecting a particular business system from the SLD, a few tabs are presented: General, Integration, Transport, and Installed Software (see Figure 3.6).
When dealing with business systems, it’s very useful to understand the concept of business system groups, which represent a grouping of business systems that belong to the same environment, thus effectively dividing your landscape into different controllable parts. Most organizations have the following four environments in their landscapes:
- Development
- Test
- Acceptance
- Production
In most organizations, systems belonging to the same group will often be named in similar ways. Of course, this depends very much on the organization’s naming conventions. For example, all systems of the development environment might have the format SYSTEMNAME_D, where D represents “development,” and all test systems might have the suffix _T. In this way, it’s easy visually to identify the environment that the system belongs to based on its name.
It’s common to have a group of business systems defined in the SLD for each one of the environments or stages of your landscape. SLD groups play an important role in managing transport targets. To manage groups, follow these steps:
- From the System Landscape Directory landing page, select Business System.
- From the Groups dropdown, choose Edit Groups.
- Select New Group.
- Give the group a name, and select an integration server responsible for all integrations in this group (this is basically the SAP PO server for this group).
You don’t have to add a business system to the group; it’s only required to link a group of business systems to an integration server. In addition, all the business systems linked to the same integration server automatically belong to the same group.
3.1.2 Software Catalog
The SLD is also equipped with a repository of SAP products and SCs (see Figure 3.7). This repository contains a catalog of SCs and their dependency relationships with each other. In the software catalog, you can differentiate products and SCs.
In the next sections, we’ll explore products and SCs in more detail.
Product
As illustrated in Figure 3.7, the intention is to group SCs in a logical way together into the same product. Therefore, a product called “Banking” assumes a grouping of various SCs related to banking services. To create a new product, follow these steps:
- From the System Landscape Directory landing page, select Products.
- Select New, and follow the wizard.
- You’ll be prompted to create a SC as part of this wizard. Be aware that it’s also possible to add more SCs later.
Software Component
A software component (SC) is a reusable module of a product. It can be upgraded or patched for bugs. A SC is the foundation on top of which an integration developer will develop his interfaces and mappings.
SCs can be dependent on other SCs. The dependency encourages reusability and is also called usage dependency. Usage dependency is used to define a relationship toward other SCs and therefore reuse their functionality.
When setting up dependencies, it’s possible to choose from among the following options:
-
InstallationTime
With this dependency type, a particular SC needs another SC to be installed. This SC can’t work without the dependencies being installed first. -
BuildTime
This dependency type defines the dependencies that are required during compilation of sources and archives. The SC’s sources need the resources of the SC that it depends on to be built and compiled. -
MetaDataRequest
This dependency type is used when the metadata of another SC is required during the installation time.
To create a new SC, follow these steps:
- From the System Landscape Directory landing page, select Software Components.
- Select New, and follow the wizard.
- Select the product version and product instance that this new SC should belong to.
- Specify the SC name and version.
- Click Finish.
- After successfully creating a SC, you can create dependencies by clicking the Dependencies tab.
- From the Context dropdown, select the desired dependency type: BuildTime, InstallationTime, or MetaDataRequest (see Figure 3.8).
- Select the Define Prerequisite Software Component Versions option and the required SC.
To properly manage the SCs in your landscape, you need to have a good approach for how to classify and organize them. This is also referred to as the SLD SC model. The SLD SC model helps you determine how many SCs should be used to represent a particular integration scenario. It’s important to think about the component model or strategy to be used and to choose one that fits best in your situation. The SLD SC model will typically be part of your development standard.
In general, three SC model strategies are widely used (see Table 3.1 for more details).
Model Name | Description |
---|---|
One SC model (also referred to as the horizontal approach) |
In this approach, a single SC is created for all interfaces of the entire organization. Namespaces are then used to separate the different domains or groups of objects. The obvious big disadvantage of this approach is that there is no reusable unit of software. |
Two SC model (also called the vertical approach) |
In this approach, two SCs are created: one encapsulating the sender and the other encapsulating the receiver. All objects and message structures belonging to the sender systems are placed in one SC. The same applies to the SC of the receiver system. The question to be asked with this approach is where to place common or shared objects (e.g., mappings) to make the translation between the sender’s message structure and the receiver’s message structure. |
Three SC model |
This approach uses three SCs: the first for the sender system, the second for the receiver system, and the third for all shared objects. This means that objects such as mappings should be placed in the third software component. This model represents a clear separation between the different SCs and encourages reusability. This model is the most commonly used. |
Note
You can also come up with your own SC model and a strategy that will best suit your own needs.
3.1.3 Development
This section of the SLD contains tools designed to facilitate SAP NetWeaver development activities: name reservation and Common Information Model (CIM) instances and classes. We’ll explore each of these tools and explain their roles.
Name Reservation
All organizations should have a naming convention. In addition to all the benefits stated in the previous section, a good naming convention allows the developers to create unique development objects and avoid name clashes and confusion between different objects. This is especially relevant when different developers and teams are working on the same project. In a typical project, not everyone is allowed to define the name of the development component (DC) as they wish. These names are predefined by an administrator, and the developers only need to use them. This approach introduces a high level of control and avoids inconsistent definition of DC names.
Name reservation (or the name server) enables the Java development team to define and reserve some names globally throughout the entire landscape. This guarantees the uniqueness of the reserved name. It’s also possible to use the namespace concept to reserve a unique name in the name server.
A namespace always starts with a namespace prefix. Namespace prefixes defined in a name reservation can later be used in the SAP NetWeaver development infrastructure. You should use your Internet domain names in the namespace definitions to make sure they are globally unique.
It’s important to note that the SLD isn’t automatically activated as the name server for your SAP NetWeaver development infrastructure developments. You can activate the name server role in the SLD used by SAP NetWeaver development infrastructure by following these steps:
- From the System Landscape Directory landing page, click on Name Reservation.
- Choose Enable This SLD as Name Server for NWDI.
After the name server has been activated for the SAP NetWeaver development infrastructure development, you can create prefixes in advance. To add a new prefix, follow these steps:
- From the System Landscape Directory landing page, click on Name Reservation.
- Make sure you’re in the Name Prefixes tab.
- Click the New Name Prefix button. You’ll see the screen shown in Figure 3.9.
- Choose the desired Name Category. Because this is for an SAP PO development, choose either Development Component Name or Software Component Name. What you choose depends on whether you want to reserve names for a SC or a DC. The concept of DCs is relevant for Java development and will be explored in Chapter 16.
- Specify the name prefix. You can specify a name up to 256 characters long. In our example, we used the name com.rojoconsultancy.finance. As you can see, this name contains an Internet domain name and department. In this way, you can categorize your namespaces.
- To complete the task, click Define.
Now that you’ve reserved a name prefix, you can predefine some DCs in the name server and make use of the previously reserved name prefix. To define a name (for a DC or SC), follow these steps:
- From the System Landscape Directory landing page, click on Name Reservation.
- Make sure to be in the Names tab.
- Click the New Name button. You’ll see the screen shown in Figure 3.10.
- Select the desired Name Prefix. In this case, the previously created com.rojoconsultancy.finance is selected.
- Specify the name of the DC by adding a name after the “/” character.
- Specify the Caption (a short description) for the DC name.
- Click Reserve.
Now, we’re ready to use this DC name during development in the SAP NetWeaver development infrastructure.
Common Information Model Instances and Classes
The Common Information Model (CIM) is a standard based on an object-oriented modeling approach. The standard is championed by the Distributed Management Task Force (DMTF). CIM is used to model hardware and software objects and elements. SAP uses the CIM to capture key properties to identify and to specify a product. It contains metadata information such as the name, vendor, description, and caption of a product. The CIM class and CIM instance are two key concepts of the CIM.
A CIM class represents a group of artifacts and objects with similar properties. A CIM class can be associated with one or more other CIM classes. For more information on the CIM standard, visit www.dmtf.org.
For the purpose of SAP PO, the CIM is used to hold the description of components, products, and the system landscape. To view and maintain the CIM Instance and classes in your SLD, select the CIM Instance and Classes link from the System Landscape Directory landing page.
You can update existing descriptions or CIM content in your SLD by using the import functionality. See Section 3.3 to learn more about how to update your existing CIM.