Registering Third-Party Systems in the System Landscape Directory (SLD)a248.g.akamai.net/n/248/420835/022a0713df2358cb287f… · · 2015-12-17in the System Landscape Directory (SLD)

SAP NetWeaver

How-To Guide

Registering Third-Party Systems in the System Landscape

Directory (SLD)

Applicable Releases:

SAP NetWeaver 7.0 and higher

Version 2.1

September 2012

i

© Copyright 2012 SAP AG. All rights reserved.

No part of this publication may be reproduced or

transmitted in any form or for any purpose without the

express permission of SAP AG. The information contained

herein may be changed without prior notice.

Some software products marketed by SAP AG and its

distributors contain proprietary software components of

other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are

registered trademarks 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, Informix,

i5/OS, POWER, POWER5, OpenPower and PowerPC are

trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader

are either trademarks or registered trademarks of Adobe

Systems Incorporated 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 the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame,

WinFrame, VideoFrame, and MultiWin are trademarks or

registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or

registered trademarks of W3C®, World Wide Web

Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

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.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP

NetWeaver, and other SAP products and services

mentioned herein as well as their respective logos are

trademarks or registered trademarks of SAP AG in

Germany and in several other countries all over the world.

All other product and service names mentioned are the

trademarks of their respective companies. Data contained

in this document serves informational purposes only.

National product specifications may vary.

These materials are subject to change without notice.

These materials are provided by SAP AG and its affiliated

companies ("SAP Group") for informational purposes only,

without representation or warranty of any kind, and SAP

Group shall not be liable for errors or omissions with

respect to the materials. The only warranties for SAP

Group products and services are those that are set forth in

the express warranty statements accompanying such

products and services, if any. Nothing herein should be

construed as constituting an additional warranty.

These materials are provided “as is” without a warranty of

any kind, either express or implied, including but not

limited to, the implied warranties of merchantability,

fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including

without limitation direct, special, indirect, or consequential

damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the

information, text, graphics, links or other items contained

within these materials. SAP has no control over the

information that you may access through the use of hot

links contained in these materials and does not endorse

your use of third party web pages nor provide any warranty

whatsoever relating to third party web pages.

SAP NetWeaver “How-to” Guides are intended to simplify

the product implementation. While specific product

features and procedures typically are explained in a

practical business context, it is not implied that those

features and procedures are the only approach in solving a

specific business problem using SAP NetWeaver. Should

you wish to receive additional information, clarification or

support, please refer to SAP Consulting.

Any software coding and/or code lines / strings (“Code”)

included in this documentation are only examples and are

not intended to be used in a productive system

environment. The Code is only intended better explain and

visualize the syntax and phrasing rules of certain coding.

SAP does not warrant the correctness and completeness of

the Code given herein, and SAP shall not be liable for

errors or damages caused by the usage of the Code, except

if such damages were caused by SAP intentionally or

grossly negligent.

Disclaimer

Some components of this product are based on Java™. Any

code change in these components may cause unpredictable

and severe malfunctions and is therefore expressively

prohibited, as is any decompilation of these components.

Any Java™ Source Code delivered with this product is only

to be used by SAP’s Support Services and may not be

modified or altered in any way.

ii

Document History

Document Version Description

2.01 New: chapter 6. Small text changes.

2.00 Added third-party data supplier for systems used by SAP Solution Manager

1.00 First official release of this guide

iii

Typographic Conventions

Type Style Description

Example Text Words or characters quoted

from the screen. These

include field names, screen

titles, pushbuttons labels,

menu names, menu paths,

and menu options.

Cross-references to other

documentation

Example text Emphasized words or

phrases in body text, graphic

titles, and table titles

Example text File and directory names and

their paths, messages,

names of variables and

parameters, source text, and

names of installation,

upgrade and database tools.

Example text User entry texts. These are

words or characters that you

enter in the system exactly as

they appear in the

documentation.

<Example

text>

Variable user entry. Angle

brackets indicate that you

replace these words and

characters with appropriate

entries to make entries in the

system.

EXAMPLE TEXT Keys on the keyboard, for

example, F2 or ENTER.

Icons

Icon Description

Caution

Important

Note

Recommendation or Tip

Example

Registering 3rd Party Systems in SLD

September 2012 1

Table of Contents

About this Guide ............................................................................................................................. 1

Background Information ................................................................................................................ 1

Roadmap ............................................................................................................................... 1

Introduction to the System Landscape Directory (SLD) ........................................................ 2

Registration of Third-Party Systems by Data Supplier ......................................................... 2

Third-Party Systems Model Descriptions .............................................................................. 3

Basic Third-Party System Model .................................................................................. 3

Optional: Model of Third-Party System Using a Database ........................................... 5

Prerequisites ................................................................................................................................... 6

Step-by-Step Procedure ................................................................................................................. 6

1. Check Completeness of PPMS and CR Content and Perform One of the Following

Activities... ..................................................................................................................... 7

Option A: Request PPMS Entry (Recommended) ....................................................... 7

Option B: Define CR Content for Third-Party Products and Software Components in

SLD on Your Own ............................................................................................ 8

2. Set Up the HTTP(S) Connection from sldreg to SLD ................................................... 9

3. Test Registration of System from Template in SLD .................................................. 10

4. Create your XML Payload .......................................................................................... 11

5. Instrument Your Third-Party System to Send Information to SLD ............................. 12

6. Automatic Synchronization with SAP Solution Manager ............................................ 12

Appendix ....................................................................................................................................... 13

About this Guide

This guide describes the instrumentation of third-party systems to register in the System Landscape

Directory (SLD). This is required if you need to consider third-party system information in SAP Solution

Manager and Process Integration (PI), whichrequire different parts of the SAP Common Information

Model (CIM) extension.

If you have questions about this guide, create a message under component BC-CCM-SLD.

Background Information

Roadmap

These are the basic steps to set up SLD data suppliers:

1. Get a basic understanding of SLD and CIM standard

Find out about how the SLD works and how the landscape and component repository data is

stored in SLD: http://scn.sap.com/docs/DOC-8042.

Get a basic understanding about Common Information Model (CIM) standards at

http://www.wbemsolutions.com/tutorials/DMTF/cim.html.

Install an SLD and download the latest SAP CIM model and SAP CR contentcontent as

described in SAP note 669669.

http://www.wbemsolutions.com/tutorials/DMTF/cim.html


September 2012 2

2. Identify appropriate template for SLD registration

By default, the SAP Solution Manager and PI use case must be supported and both templates

are used. If the use case is restricted, this limitation needs to be documented in the third-party

system, manually.

3. Clarify product model

Contact SAP to include your product definition into SAP PPMS or create your own product

definition in your test SLD.

4. Create sample SLD payload file

Create a sample XML file containing your product description with the templates or examples

attached.

Test the adapted XML with the attached test parser and with your test SLD.

5. Development of SLD data supplier

The SLD data supplier must be able to collect all required information from the system to

generate a payload XML document which looks like your sample XML file.

The SLD data supplier must be able to open an authenticated HTTP connection to the SLD

server to send the payload XML to the SLD. You can either use the sldreg executable or an

own HTTP client for this data transfer, whichmust meet the SAP security requirements.

A mechanism must be implemented that triggers the SLD data supplier when a change in the

system landscape occurs. Alternatively, you can send data periodically, for example twice a

day.

The setup of the SLD data supplier should be included in the installation routine of the system.

6. Automatic synchronization with the LMDB (Landscape Management Database) and transaction

SMSY in SAP Solution Manager.

Introduction to the System Landscape Directory (SLD)

The System Landscape Directory (SLD) is a central repository of system landscape information that is

relevant to manage the software lifecycle. The system landscape consists of systems, which form

visible entities for administrators and of the installed software components and its versions. The

complete information is called Landscape Description.

The SLD is also a repository for all theoretically installable software products and software

components available from SAP and partners. This kind of information is stored in the Component

Repository (CR) and is provided regularly by the software component SAP CR content. (The CR

content is derived from the SAP-internal PPMS system.)

Both Landscape Descriptions and CR content are based on the CIM model, which is stored in the SLD

as well. For more information about CIM, see www.dmtf.org.

Registration of Third-Party Systems by Data Supplier

With an SLD data supplier, a system registers information about itself on the SLD server and keeps

the landscape description automatically up-to-date.

http://www.dmtf.org/


September 2012 3

Any data supplier collects and sends data about the system to the SLD Landscape Description (1).

The system registration includes additional associations (2) to the corresponding entries in the

Component Repository.

For the SLD, applications that do not run on the SAP Application Server are third-party systems.

Non-ABAP and non-Java SAP systems with unspecified characteristics fall into the same category.

These systems register their current system landscape data in the SLD using an external data

supplier – the sldreg executable or an own HTTP client.

To register the CR associations shown above, the product definition must be included in the SAP

PPMS and/or the SLD Component Repository first. For more information, see Check Completeness of

PPMS and CR content and Perform One of the Following Activities.

The SLD receives data via the sldreg executable or another HTTP client in XML format. This XML

has to comply with the document type definition (DTD). The DTD must not be declared in the sent

XML, it is validated by the SLD server only.

For more information see the following documents:

Appendix A: sldreg DTD

Appendix B: XML Data Structure

SAP Note 1018839

Third-Party Systems Model Descriptions

Basic Third-Party System Model

CIM Model Used for SAP Solution Manager

The following model describes a third-party system with the information required by the SAP Solution

Manager:

https://service.sap.com/sap/support/notes/1018839


September 2012 4

Each third-party system that is used by SAP Solution Manager is an instance of the

SAP_UnspecificStandaloneApplicationSystem class. These systems are called "unspecific

systems" in this document. The third-party system model for data used by Process Integration (PI) is

described in the next section. By default, you must register the same system with both models.

The SAP_UnspecificStandaloneApplicationSystem is associated with a set of software

components that are installed: different instances of the SAP_InstalledSoftwareComponent

class. Each software component that is installed on an application system is part of one product that is

installed. In most cases, a third-party system includes one software component that belongs to

one product that is installed. However, the model also allows a more complicated case: a set of

software components to be part of more than one product that is installed.

The SAP_Product class, SAP_CoherentSoftwareUnit class, and SAP_SoftwareComponent

class are included in the SLD SAP CR content. Unlike SAP products and components, third-party

products and software components are not necessarily included in the CR. But only if these CR

instances exist, your data supplier can create the corresponding associations

(SAP_InstalledProductImage, SAP_SoftwareFeatureType and

SAP_SoftwareComponentType).

Because a data supplier is not authorized to create CR instances of third-party products and

components, the SLD CR contentcontent for third-party software has to be either provided with the

SAP CR contentcontent transport, or you have to define it in the SLD yourself. Self-defined CR

contentcontent can be exported and imported in any other SLD.

The registration procedure of third-party systems includes at minimum the creation of the

following instances:

one instance of the SAP_UnspecificStandaloneApplicationSystem class

one basic instance of the SAP_ComputerSystem class

one or more instances of the SAP_InstalledSoftwareComponent class

one or more instances of the SAP_InstalledSoftwareFeature class

one or more instances of the SAP_InstalledProduct class

For more information, see the UnspecificStandalone.xml sample file under Registration of Third-Party

Systems in SLD - Example Code at http://scn.sap.com/docs/DOC-8042.


September 2012 5

CIM Model Used for SAP Process Integration (PI)

The following is a simplified model that describes a specific third-party system with the information

that is required for SAP Process Integration (PI):

Each third-party system that is used by PI is an instance of the SAP_ApplicationSystem class.

This instance is associated with a set of software components that are installed: different instances of

the SAP_InstalledSoftwareComponent class. Each software component that is installed on an

application system is part of one product that is installed. In most cases, a third-party system

includes one software component that belongs to one product that is installed. However, the

model also allows a more complicated case: a set of software components to be part of more than one

product that is installed.

The registration procedure of third-party systems includes the creation of the following instances:

• one instance of the SAP_ApplicationSystem class

• one or more instances of the SAP_InstalledSoftwareComponent class

• one or more instances of the SAP_InstalledProduct class

• one basic instance of the SAP_ComputerSystem class

For more information, see the ThirdPartySystem.xml sample file under Registration of Third-Party

Systems in SLD - Example Code at http://scn.sap.com/docs/DOC-8042.

Optional: Model of Third-Party System Using a Database

A third-party system may use a database system in both use cases - SAP Solution Manager and PI.

The figure below shows a simplified version of such a model. It covers all classes and associations

that can be involved in addition to the basic third-party system.


September 2012 6

In many cases you also have to register the database system in the SLD. This means that you have to

create one instance of the SAP_DatabaseSystem class. You must associate each

SAP_DatabaseSystem and the SAP_ComputerSystem classes. In many cases the computer

system on which the instances of the SAP_DatabaseInstance class reside, can be different from

the computer system on which the third-party system is installed. Thus, the data supplier must provide

data about the computer system and host of the SAP_DatabaseInstance classes.

For more information, see the ThirdPartySystem_extended.xml sample file under Registration of Third-

Party Systems in SLD - Example Code at http://scn.sap.com/docs/DOC-8042.

Prerequisites

SLD server as of SAP NetWeaver 7.0 SPS07 or higher is installed and SAP CR contentis

updated to the latest version.

For use in SAP Solution Manager 7.1 SP0-4, see System Landscape Directory (SLD)

Requirements in the LMDB Setup Guide at https://service.sap.com/solutionmanager under

Media Library --> Technical Information.

For use in SAP Solution Manager 7.1 SP5 and higher, see Connect LMDB to SLD.

The SLD server is running

SLD has been configured to receive data

For more information, see the Post-Installation Guide of SAP NetWeaver 7.0 and the User

Manual of your SAP NetWeaver at http://scn.sap.com/docs/DOC-8042.

You have a user assigned to the DataSupplierLD security role.

Step-by-Step Procedure

To register third-party systems or unspecific SAP systems in the SLD, perform the following steps,

which are explained in detail subsequently:

1. Check completeness of CR content and perform one of the following activities:

Option A: Request PPMS entry (recommended)

Option B: Define third-party products and software components in SLD on your own and

export and import definitions (workaround)

2. Set up the connection to SLD

3. Test the registration of an XML template system at SLD

4. Create and test your own XML document

5. Instrument your third-party system

6. Synchronization of SLD and SAP Solution Manager will be done automatically.

https://service.sap.com/solutionmanager

https://help.sap.com/saphelp_sm71_sp05/helpdata/en/a5/971735dd184f5c8d943c6cf423d13a/frameset.htm


September 2012 7

1. Check Completeness of PPMS and CR Content and

Perform One of the Following Activities...

Option A: Request PPMS Entry (Recommended)

An SAP contact must enter the meta-data of your software in the SAP Product and Production

Management System (PPMS) to have the CR content updated. This informationregularly

published on the SAP Service Marketplace (SAP note 669669). Your SAP contact sends back

the product and software component identifiers to be used.

Note

Only products and software components with an PPMS entry can be used in the SAP

Solution Manager. Therefore, this activity is to be preferred to the next one.

https://service.sap.com/sap/support/notes/669669


September 2012 8

Option B: Define CR Content for Third-Party Products and

Software Components in SLD on Your Own

1. To create the third-party product and software component in the SLD, access the SLD

Welcome screen and choose Home Products.

Use capital letters for all names and dot-separated numbers for the versions. For all

parameters, set the same values as the ones that you have defined in the environment

settings (for more information, see Setting Up the HTTP(S) Connection from Third-Party

System to SLD). For the technical name of your software unit, you can set any value, for

example, UNIT1.

For more information, see Creating and Removing Third-Party Products and Creating and

Removing Third-Party Software Components in the User Manual - SLD of SAP NetWeaver

<your version> at http://scn.sap.com/docs/DOC-8042.

2. Data about products and software components from the PPMS (vendor = sap.com) already

exists in SLD. Choose a name and a version pattern that fits the PPMS conventions. Avoid

any name conflict with SAP products and software components to enable an easy migration

easily to the PPMS later.

3. From the Product dropdown box, select the product that you have created.

4. From the table with product versions, select the product and choose Export.

5. Choose Download Link and save the file to a directory of your choice.

Note

The ZIP file contains the instances of all classes that are related to one product version

(the product and its software components). If you want to export the data about more than

one product, you have to repeat the steps for each product.

6. Ensure that product and component definitions from the ZIP file are imported to all target

SLDs.

For more information, see Updating the Software Catalog in the User Manual - SLD of SAP

NetWeaver <your version> under http://scn.sap.com/docs/DOC-8042.


September 2012 9

2. Set Up the HTTP(S) Connection from sldreg to SLD

This section is only relevant if you send the XML document with sldreg to SLD. The executable

sldreg[.exe] and the required dynamic link libraries (DLL) can be downloaded as described in SAP

Note 1018839 or the binaries can be copied from any ABAP or J2EE-based system from directory

<Drive>:\usr\sap\<SID>\SYS\exe\run (UNIX: /usr/sap/<SID>/SYS/exe/run).

1. Create a new working directory and set the executable and library path in a way that sldreg

can be called. If you use the <sid>adm user, the environment is automatically set correctly.

Alternatively, you can use the executable directory or a copy of it as a working directory to

configure the SLD destination, execute the following command:

sldreg.exe -configure slddest.cfg -usekeyfile

You are prompted to enter the following HTTP connection information:

o User Name

o Password

o Server Host - the host on which the SLD server is running

o Port - the HTTP/HTTPS port on which the SLD server is running

o Use HTTPS

Note

The option HTTPS is not available in SAP NetWeaver 7.0.

You are prompted whether you want the information to be written to the slddest.cfg file

and the slddest.cfg.key file to be created. For security reasons, we recommend that you

use the key file. The default location of the slddest.cfg and slddest.cfg.key files in an

SAP installation is the <Drive>:\usr\sap\<SID>\SYS\global directory.

The slddest.cfg file contains the encrypted HTTP connection information: user name,

password, host, and HTTP/HTTPS port. The slddest.cfg.key file contains the key

information that is used for encryption and decryption. You have to protect this file from

unauthorized access. Set read and write permissions only for the <sid>adm user.

If you do not want to be prompted for the HTTP connection information, execute the following

command:

sldreg.exe -configure slddest.cfg -user <User name> -pass <Password>

-host <Host> -port <Port> -usekeyfile [-usehttps], the last parameter is not

available in SAP NetWeaver 2004s.

For more information, see the following documents:

Appendix F: Overview of sldreg Command Lines Parameters

Appendix G: Technical Notes on Using sldreg


September 2012 10

3. Test Registration of System from Template in SLD

1. Unzip the RegistrationThirdPartySystemExample.zip archive to your working directory.

2. In the third-party system, transfer the ThirdPartysystem.xml sample file in one of the

following ways:

To transfer the XML data as a file use the example file from the archive. In the command

line, execute the following command:

sldreg -connectfile slddest.cfg -file ThirdPartySystem.xml

To transfer the XML data directly with sldreg and the standard input, execute the

following command:

... | sldreg -connectfile slddest.cfg

3. When the data is registered on the SLD server, the HTTP response code is as follows:

HTTP response: Success. HTTP status code: 200

To check for any errors on the receiver side, choose Administration Log on the SLD Welcome

screen.

4. To view and remove information about the third-party system ExampleThirdPartySystem on

examplehost that you have registered, access the SLD Welcome screen and choose Technical

Systems Technical System Type Third Party (for Release 7.0) or Other (...) (for Release

7.10).


September 2012 11

4. Create your XML Payload

Prerequisites:

Third-party products and software components have been created in the SLD CR content.

The HTTP(S) connection from third-party system to SLD has been set up.

Procedure:

To create your third-party system information, create an XML with specific system information that can

be read by sldreg or by your own HTTP client to be transported to SLD.

You can choose one of the following two methods:

Generate an XML from template:

1. Unzip the RegistrationThirdPartySystemExample.zip archive at

http://scn.sap.com/docs/DOC-8042to your working directory.

2. Read the comments in the UnspecificStandalone.properties file.

3. Adapt this file to your specific third-party system data.

4. Call the sldreg with minimum version 7.11 to generate the XML document and

send to the configured SLD by executing the following command:

sldreg -file <Template file> –symbolfile <Parameters file> -

connectfile <connect file>

Example:

sldreg –file UnspecificStandalone.template –symbolfile

UnspecificStandalone.properties –connectfile slddest.cfg

Create an own XML:

1. To obtain the resulting ThirdPartySystem.xml (contained in the archive), replace the

placeholders in the template file with specific values.

Placeholders are, for example, ${ComputerName} or ${LocalSystemName}. They are

described in the properties file.

For more information, see Appendix B: XML Data Structure, Appendix C: Mandatory Data

Groups, and Appendix D: Optional Data Groups.

2. Create your XML data. Specify the appropriate values of the properties for each instance.

For more information, see Appendix E: Key and Normal Properties of the Classes.

3. Test your XML data by transferring it to the SLD.

For more information, see 5. Instrument Your Third-Party System to Send Information to

SLD.


September 2012 12

In both cases, check the SLD log under Administration Log for errors. To confirm that all

expected instances are created, access the SLD Welcome screen and choose CIM Instances

(Release 7.10) or Administration Content Maintenance (Release 7.0).

5. Instrument Your Third-Party System to Send

Information to SLD

The SLD registration needs to be integrated into the third-party system. Without such instrumentation,

the data in SLD will be outdated soon.

1. Transfer your data to the SLDwhen you start your application, and periodically, for example, twice

a day.

2. If this is not possible, the next best alternative is the registration at the startup of the operating

system. Absolute minimum is the registration during installation and upgrade of the system.

3. To transfer data to the SLD, use sldreg or your own HTTP client to transfer data (see Appendix

H: Supplying Data to the System Landscape Directory Directly via HTTP).

4. Use the XML document that you produced when you created the third-party system information as

template and substitute the hostname string therein at runtime. Alternatively, you can create the

XML document from scratch in your software and transfer the document to sldreg via stdin or

file. The value of the host name must be set dynamically in any case.

5. Provide the additional software, template, and documentation that your customers may need to

successfully register your system in the SLD.

6. Automatic Synchronization with SAP Solution Manager

From the SLD, third-party system information is automatically forwarded to the Landscape

Management Database (LMDB) and to transaction SMSY in SAP Solution Manager. How to set up the

SLD connection to SAP Solution Manager is described here:

For SAP Solution Manager 7.1 SP5 and following:

https://help.sap.com/solutionmanager71 Application Help select release and language

SAP Solution Manager Operations Managing System Landscape Information Set Up

the Landscape Management Infrastructure Connect LMDB to System Landscape Directory.

For SAP Solution Manager 7.1 SP0-4:

https://service.sap.com/solutionmanager Media Library Technical Information Setup

Guide Landscape Management Database (LMDB) (select a release).

https://help.sap.com/solutionmanager71

https://service.sap.com/solutionmanager


September 2012 13

Appendix

Appendix A: sldreg DTD

 <!ELEMENT group ((rootclass,memberclass+)|class*)> <!ATTLIST group name CDATA #REQUIRED group_type (GENERIC|SPECIFIC) "GENERIC" data_type CDATA #IMPLIED data_version CDATA #IMPLIED >  <!ELEMENT class (instance*)> <!ATTLIST class name CDATA #REQUIRED sync (TRUE|FALSE) "TRUE" merge_properties (TRUE|FALSE) "TRUE" clean (NONE|DELETE) "NONE" >  <!ELEMENT rootclass (instance)> <!ATTLIST rootclass name CDATA #REQUIRED sync (TRUE|FALSE) "FALSE" merge_roots (TRUE|FALSE) "TRUE" merge_properties (TRUE|FALSE) "TRUE" clean (NONE|LONE|ALL) "NONE" >  <!ELEMENT memberclass (instance*)> <!ATTLIST memberclass name CDATA #REQUIRED association_name CDATA #REQUIRED root_role CDATA #REQUIRED member_role CDATA #REQUIRED mergeRootClass CDATA #IMPLIED mergeMemberClass CDATA #IMPLIED mergeAssocClass CDATA #IMPLIED sync (TRUE|FALSE) "TRUE" merge_members (TRUE|FALSE) "TRUE" merge_properties (TRUE|FALSE) "TRUE" clean (NONE|LONE|ALL) "NONE" optional (TRUE|FALSE) "FALSE" >  <!ELEMENT instance (property*)>  <!ELEMENT property (value*)> <!ATTLIST property name CDATA #REQUIRED sourceformat CDATA #IMPLIED > <!ELEMENT value (#PCDATA)>

Appendix B: XML Data Structure

According to the sldreg.dtd (see Appendix A: sldreg DTD), the building elements of the XML data

are the following:

Attributes of the <sldinfo> Element

supplier_name

This is the unique name of the data supplier that is used. The standard registration procedure,

provided by SAP for third-party systems, sets the attribute to ThirdPartySystem.

supplier_vendor

Set the attribute to sap.com, because the feature is provided by SAP.

supplier_version

Specifies the version of the data supplier that is used. Set the attribute to 1.0.

model_version

Specifies the model version that is required. Set the attribute to 1.4.30 or higher.

Attributes of the <group> Element

The <group> element is used to separate the data into logical units. The groups are processed in the

order in which they appear. Each <group> element has the following attributes:

name


September 2012 15

All groups that are included in the <sldinfo> element must have a unique name. We recommend

that you use meaningful group names and, thus, provide information about the purpose of the group.

group_type

Always set the attribute to GENERIC.

Attributes of the <rootclass> and <memberclass> Elements

Each group contains one <rootclass> element and one or more <memberclass> elements.

The <rootclass> element always includes only one <instance> element. The <memberclass>

element can include an arbitrary number of <instance> elements.

Both elements, <rootclass> and <memberclass>, have the following attribute:

name

Specifies the exact CIM class name of the corresponding instance(s). For more information, see Third-

Party Systems Model Description.

The only instance of the <rootclass> element is associated with the instances of the

<memberclass> elements. An association between the instances is defined by the following

attributes of the <memberclass> element:

association_name

Specifies the class name of the association.

root_role

Specifies the role of the root class in the association.

member_role

Specifies the role of the member class in the association.

Both elements, <rootclass> and <memberclass>, have the following attributes that manage the

synchronization with the current state of the SLD server:

sync

This attribute allows you to synchronize the instances with the state of the SLD server.

To improve performance, only set the sync attribute to TRUE in the first group in which an instance is

included. In the other groups in which the instance is used, set the sync attribute to FALSE.

merge_properties

The properties of an instance can be key and normal. The key properties clearly identify the instances

of a class. The normal properties are optional. We recommend that you include normal properties only

if the instance is synchronized.

Many classes and their instances have the Caption normal property. This property is a short

description of the instance and has a maximum length of 64 characters. We recommend that you

always set the Caption normal property for every instance with this property.

The merge_properties attribute handles the additional properties that are not provided by the data

supplier.

Note that the merge_properties attribute does not take effect if the instance is not synchronized,

that is, if you set the sync attribute to FALSE.

If you set the merge_properties attribute to TRUE, the values of all additional properties of the

instance(s) in the SLD repository remain unchanged. If you set the attribute to FALSE, all values of the

properties that are not specified are deleted.

merge_roots and merge_members

These attributes are similar. They specify how the existing associations are treated.

The merge_roots attribute is used with the <rootclass> element, whereas the merge_members

attribute is used with the <memberclass> element.


September 2012 16

To keep the associations that exist in the SLD repository, set both attributes to TRUE.

Sometimes, however, you have to set these attributes to FALSE. For example, if a <memberclass>

instance can be associated with only one <rootclass> instance, set the merge_roots attribute to

FALSE.

mergeRootClass, mergeMemberClass and mergeAssocClass

These attributes are used with the <memberclass> element.

Use mergeRootClass filter parameter (in association traversal) for the root class to determine the

set of instances that are evaluated for member merging. For example, this value can be used to filter

for a super class of the root class instead.

If no value is specified, the class name of the root instance is used.

mergeMemberClass and mergeAssocClass are analogous to mergeRootClass for the member

class or the association class.

Examples with Detailed Explanations

Association with Restricted Cardinality

The figure above shows two classes - Class1 and Class2. The association, Association1,

introduces the relation between these classes. It also shows that the association has a restricted

cardinality on the side of Class1. Thus each instance of Class2 can be associated with only one

instance of Class1. You have to observe the restricted cardinality by correctly setting the

merge_roots and merge_members attributes in the group in which these associations are

established. Let us assume that Class1 is a <rootclass> and Class2 is a <memberclass> of the

group. The <memberclass> instances can be more than one. To observe the restricted cardinality,

you have to set the merge_roots attribute to FALSE. Thus, all existing associations between the

corresponding <memberclass> instances and any instance of Class1 are deleted. Let us assume

that the group includes one instance of Class2, Class2_Inst1, which is already associated with

one instance of Class1, Class1_Old. To ensure that the instance of Class2 cannot be associated

with a second instance of Class1, you have to set the merge_roots attribute to FALSE. Thus, the

existing association, Association1_Old, is deleted. If the <rootclass> instance that is specified

is Class1_Old, the association is created again every time. If, however, the <rootclass> instance

that is specified is different from Class1_Old, for example, it is Class1_New as it is shown in the

following example, the obsolete association is deleted and replaced with a new association every time.

In both cases, if you set the merge_roots attribute to FALSE, you observe the restricted cardinality.

Usage of the merge_roots Attribute to Observe the Restricted Cardinality

Class2Class1Association1

*0..1

Class2_Inst1Class1_Old

Association1_Old

Class1_New

Memberclass instance

Association1_New


September 2012 17

If the <rootclass> instance must be related to only one instance of the <memberclass> element,

you have to set the merge_members attribute to FALSE. We recommend that you have exactly one

<memberclass> instance in the group.

The usage of the merge_roots and merge_members attributes to observe the maximum value of

the cardinality is a rare case. The more common case is when the <memberclass> instances are an

arbitrary number and they form the full set of instances that must be associated with a <rootclass>

instance. In this case, any existing associations with the <memberclass> instances that are not

included in this set are considered obsolete and, therefore, unnecessary. To delete them, you have to

set the merge_members attribute to FALSE. This case is shown in the following example.

Usage of the merge_members Attribute to Provide the Full Set of Instances

The figure above shows the state of the SLD repository after new data is sent by sldreg. Let us

suppose that the <rootclass> instance, Class1_Inst1, has been initially associated with two

<memberclass> instances, Class2_Inst1 and Class2_Inst2. Sometimes the SLD repository

might be outdated and, therefore, has to be updated. For example, if the Class1_Inst1 instance has

to be associated only with the Class2_Inst2 and Class2_Inst3 instances, the Class2_Inst1

instance becomes outdated and the association to it has to be deleted. Therefore, you have to set the

merge_members attribute to FALSE. Thus, the existing associations, Association1_Inst1 and

Association1_Inst2, are deleted. The association, Association1_Inst2, between

Class1_Inst1 and Class2_Inst2 is created again. The association between Class1_Inst1 and

Class2_Inst3 is created for the first time.

As a result, the following rules apply:

If the <rootclass> instance that is specified must be the only instance that is associated

with each <memberclass> instance that is specified, you have to set the merge_roots

attribute to FALSE.

If the set of <memberclass> instances that is specified forms the full set of instances that

must be associated with a <rootclass> instance that is specified, you have to set the

merge_members attribute to FALSE.

The clean Attribute handles the instances which have been previously associated and which are not

specified anymore. These instances are called lost instances. In the figure above, Class2_Inst1 is a

lost instance.

The clean attribute has the following possible values:

NONE

Class2_Inst2Class1_Inst1

Association1_Inst2

Class2_Inst3

Rootclass instance

Class2_Inst1

Outdated Memberclass instance

Association1_Inst1Association1_Inst3


September 2012 18

If you set the attribute to NONE, all lost instances remain in the SLD repository. This case is

shown in the figure above.

LONE

If you set the attribute to LONE, all lost instances, which do not have any remaining

associations after data processing, are deleted. Only the isolated lost instances are deleted. In

the figure, Class2_Inst1 is presented as an isolated lost instance, because it remains

without any associations, after the deletion of the Association1_Inst1 association. To

delete the isolated lost instance Class2_Inst1, you have to set the clean attribute to LONE.

The result is shown in the following figure:

Usage of the merge_members Attribute and clean = LONE

ALL

If you set the attribute to ALL, all lost instances in the SLD repository, both those that are still

associated to other instances and those that are not, are deleted. If the lost instances are not

isolated, all their existing associations are implicitly deleted. In figure 7 below, the

Class2_Inst1 instance is not isolated, because after the obsolete association

Association1_Inst1 is deleted, an association to one instance of the

OtherClass_Inst1 class still exists. In this case, the only way to delete the Class2_Inst1

instance and all its remaining associations is to set the clean attribute to ALL. The result is

shown in the following figure:

Usage of the merge_members Attribute and clean = ALL

Note

Note that the clean attribute only takes effect if you set the corresponding merge_roots

and merge_members attributes to FALSE.

Class2_Inst2Class1_Inst1

Association1_Inst2

Class2_Inst3

Rootclass instance

Class2_Inst1



Class2_Inst2Class1_Inst1Association1_Inst2

Class2_Inst3

Rootclass instance

Class2_Inst1



OtherClass_Inst1

OtherAssociation_Inst1


September 2012 19

Appendix C: Mandatory Data Groups (for PI Use Case)

This section describes only the data groups that are mandatory to specify a third-party or unspecified

SAP system. The approach that is applied is called "from inside to outside". The core class of the

model is the SAP_ApplicationSystem class. An inner class is a class that is closer to the core

class. To apply the "from inside to outside" approach means to use the "inner" class as a

<rootclass> element and the "outer" class as a <memberclass> element.

Note

The data groups described here are mandatory for the data supplier using CIM Model for SAP

Process Integration (PI). Data suppliers using CIM Model used for SAP Solution Manager

have additional mandatory data groups, e.g. for supplying data for installed software features

(Product Instances) and additional associations. Please have a look to the example payload

XML file “UnspecificStandalone.xml) as reference here.

SystemHost Group

Use this group to specify the instance of the SAP_ApplicationSystem class. This instance

represents the third-party system which is described. The group also registers the instance of the

SAP_ComputerSystem class, which is used as a host of the third-party system. The dependency

between both instances, the SAP_ApplicationSystemHost association, is also created.

Structure of the Group:

The <rootclass> element includes an instance of the SAP_ApplicationSystem class. You have

to fully describe and synchronize it with the SLD repository.

The <memberclass> element includes one instance of the SAP_ComputerSystem class. The

computer system can already be registered by the data supplier of the J2EE Engine. It is possible,

however, that the data supplier is not configured on the host. You only have to specify the key

properties and the Caption normal property of the instance.

For more information about the key and normal properties of all classes, see Appendix E: Key and

Normal Properties of the Classes.

Attributes of the <rootclass> Element:

Set the name attribute to SAP_ApplicationSystem.

Set the sync attribute to TRUE, because this is the first group in which the instance is

included. You can update the normal properties of a third-party system which is already

registered. You have to specify the key properties and the Caption normal property.

Set the merge_properties attribute to TRUE to keep the values of the normal properties

that are set in the SLD repository and that are not specified in the group.

Set the merge_roots attribute to TRUE, because many application systems can be installed

on one computer system.

Set the clean attribute to NONE, because there are no lost instances of the

SAP_ApplicationSystem class that have to be deleted.

Attributes of the <memberclass> Element:

Set the name attribute to SAP_ComputerSystem.

Set the association_name attribute to SAP_ApplicationSystemHost.


September 2012 20

Set the root_role attribute to Dependent.

Set the member_role attribute to Antecedent.

Set the sync attribute to TRUE to register the instance if the data supplier is not configured on

this host.

Set the merge_properties attribute to TRUE to synchronize the instance with a property

merge.

Set the merge_members attribute to FALSE, because the model allows each third-party

system to be dependent only on one computer system.

Set the clean attribute to LONE to delete an isolated computer system that is not specified in

this group, but which may exist, from the SLD repository.

InstalledSoftwareComponents

Use this group to specify all software components that are installed and associated with the third-party

system which is described. The software components that are included in this group are the full set of

components that are installed on the third-party system. Use the group also to create a set of

associations between the software components that are installed and the third-party system which is

described, that is, associations of type SAP_InstalledSWComponentOnApplicationSystem.


The <rootclass> element includes the instance of SAP_ApplicationSystem, which is already

described and synchronized in the previous group. To identify this instance, you have to set only its

key properties.

The <memberclass> element includes one or more instances of the

SAP_InstalledSoftwareComponent class. They appear for the first time and, therefore, you have

to fully describe and synchronize them in this group. Besides the key properties, you have to specify

some normal properties and the Caption normal property.



Set the sync attribute to FALSE, because the instance is already synchronized with the SLD

repository in the previous group.

Use the default value, TRUE, of the merge_properties attribute, which, however, does not

take effect if the sync attribute is set to FALSE.

Set the merge_roots attribute to FALSE, because each software component that is installed

can be installed only on one application system. If obsolete associations to other application

systems exist, you have to delete them.

Set the clean attribute to NONE, because you do not have to delete any instances of the

SAP_ApplicationSystem class.


Set the name attribute to SAP_InstalledSoftwareComponent.

Set the association_name attribute to

SAP_InstalledSWComponentOnApplicationSystem.

Set the root_role attribute to System.

Set the member_role attribute to Software.

Set the sync attribute to TRUE to register in the SLD all software components that are

installed.

Set the merge_properties attribute to TRUE to synchronize the instances with a property

merge.


September 2012 21

Set the merge_members attribute to FALSE, because the set of software components that are

installed is the full set of components that are associated with the third-party system. You

have to delete any software components which have been previously installed and which are

not included in this set.

Set the clean attribute to ALL to delete from the SLD repository all obsolete software

components that are installed.

InstalledProduct

Usually all software components that are installed belong to only one product that is installed.

However, software components that are installed can belong to several products that are installed.

Even if each software component that is installed is part of only one product that is installed, if you

apply the "from inside to outside" approach, you can have many groups. For example, if N software

components that are installed belong to one product that is installed, the number of groups is N. You

can reduce the number of groups, if you revert the <rootclass> and <memberclass> elements.

This is an intentional violation of the "from inside to outside" approach. Then many groups of this type

appear only if the software components that are installed belong to several products that are installed.

In the simplest case when only one software component that is installed exists, we recommend that

you apply the "from inside to outside" approach.

Use the group(s) to register all products that are installed. Use the group(s) to create a set of

associations of type SAP_CollectedSoftwareComponents, which specify the membership of the

software components that are installed to the corresponding products that are installed.


The <rootclass> element includes an instance of SAP_InstalledProduct class, which you have

to fully describe and synchronize in this group.

The first <memberclass> element includes one or more instances of the

SAP_InstalledSoftwareComponent class. These instances are already synchronized with the

SLD repository in the previous group. You have to specify only their key properties.

The second <memberclass> element includes the instance of SAP_ApplicationSystem, which is

already described and synchronized in the previous group. To identify this instance, you have to set

only its key properties.


Set the name attribute to SAP_InstalledProduct.

Set the sync attribute to TRUE because this is the first group in which the instance is included.




can be part of only one product that is installed. If obsolete associations to other products that

are installed exist, you have to delete them.

Set the clean attribute to NONE, because you can delete the obsolete instances of the

SAP_InstalledProduct class only in the SLD.

For more information, see Cleaning Up Data in SLD User Manual under

http://scn.sap.com/docs/DOC-8042.

Attributes of the first <memberclass> Element:


Set the association_name attribute to SAP_CollectedSoftwareComponents.

Set the root_role attribute to Collection.

Set the member_role attribute to Member.


September 2012 22

Set the sync attribute to FALSE, because the instances are already synchronized with the

SLD repository in the previous group.


take effect, if the sync attribute is set to FALSE.

Set the merge_members attribute to FALSE, because the set of software components that are

installed is the full set of components that are associated with a product that is installed.

Set the clean attribute to NONE, because the obsolete software components that are installed

are deleted from the SLD repository in the previous group.

Attributes of the second <memberclass> Element:


Set the sync attribute to FALSE, because the instance is already synchronized with the SLD

repository in the previous group.


take effect if the sync attribute is set to FALSE.


can be installed only on one application system. If obsolete associations to other application

systems exist, you have to delete them.

Set the clean attribute to NONE, because you do not have to delete any instances of the

SAP_ApplicationSystem class.

InstalledSoftwareComponentToComponentRepository

The number of the groups of this type is N, where N is the number of the software components that

are installed. Use the group(s) to establish an association between a software component that is

installed on the third-party system which is described and the corresponding software component that

is registered in the SLD repository.


The <rootclass> element includes one of the instances of the

SAP_InstalledSoftwareComponent class, which is already specified in the previous groups.

The <memberclass> element includes the corresponding instance of the

SAP_SoftwareComponent class which belongs to the CR. Only if this instance does exist in the CR,

the association of type SAP_SoftwareComponentType can be established.

To identify the instance of the SAP_SoftwareComponent class, you have to specify only its key

properties.



Set the sync attribute to FALSE, because you use the group only to establish an association

between two existing instances.



Set the merge_roots attribute to TRUE, because each software component from the CR can

be represented by many software components that are installed. So all existing components of

the same type that are installed have to remain in the SLD repository.

Set the clean attribute to NONE, because the obsolete instances of the

SAP_InstalledSoftwareComponent class are deleted in another group.


September 2012 23


Set the name attribute to SAP_SoftwareComponent.

Set the association_name attribute to SAP_SoftwareComponentType.



Set the sync attribute to FALSE, because the instance must be present in the CR of the SLD

server.



Set the merge_members attribute to FALSE, because each software component that is

installed can be associated with only one software component that is registered in the CR.

Set the clean attribute to NONE, because sldreg does not have authorization to delete

instances of third-party products and components from the SLD CR.

InstalledProductToComponentRepository

The number of groups of this type is N, where N is the number of products that are installed. Use the

group(s) to establish an association between a product that is installed and the corresponding product

that is registered in the SLD CR.


The <rootclass> element includes one of the instances of the SAP_InstalledProduct class that

is already specified in the previous groups.

The <memberclass> element includes the corresponding instance of the SAP_Product class that

belongs to the CR. Only if this instance does exist in the CR, the association of type

SAP_InstalledProductImage can be established.

To identify the instance of the SAP_Product class, you have to specify only its key properties.


Set the name attribute to SAP_InstalledProduct.

Set the sync attribute to FALSE, because you use the group only to establish an association

between two existing instances.



Set the merge_roots to TRUE, because each product that is registered in the CR can be

represented by many products that are installed. So all existing products of the same type that

are installed have to remain in the SLD repository.

Set the clean attribute to NONE, because you can delete the obsolete instances of the

SAP_InstalledProduct class only in the SLD.


Set the name attribute to SAP_Product.

Set the association_name attribute to SAP_InstalledProductImage.

Set the root_role attribute to Collection.

Set the member_role attribute to Product.

Set the sync attribute to FALSE because the instance must be present in the SLD CR.


September 2012 24



Set the merge_members attribute to FALSE, because each product that is installed can be

associated with only one product from the CR.

Set the clean attribute to NONE, because sldreg does not have authorization to delete

instances of third-party products and components from the SLD CR.

Appendix D: Optional Data Groups

Use the optional groups after the mandatory groups only if a third-party system depends on a

database system.

DatabaseSystem Group

Use the group to create a dependency for a third-party system on a database system because the

database system also has to be registered in the SLD repository.


The <rootclass> element includes the instance which represents the third-party system that is

descibed. This instance is fully specified in the previous groups and, therefore, you only have to set its

key properties.

The <memberclass> element includes an instance of the SAP_DatabaseSystem class. You have to

fully describe and synchronize this instance in this group. Besides the key properties, you can also set

some normal properties. You have to add the Caption normal property.

For more information about the key properties and normal properties of all classes, see Appendix F:

Key and Normal Properties of the Classes.

Attributes of the <rootclass> Element


Set the sync attribute to FALSE because the instance is synchronized in another group.

Use the default value TRUE of the merge_properties attribute, which, however, does not


Set the merge_roots attribute to TRUE because many application systems might depend on

the same database system.

Set the clean attribute to NONE, so that obsolete application systems do not appear after data

processing.


Set the name attribute to SAP_DatabaseSystem.

Set the association_name attribute to SAP_ApplicationSystemUsingDB.



Set the sync attribute to TRUE to register a new database system or update an existing one.



Set the merge_members attribute to FALSE because each third-party system only depends

on one database system.

Set the clean attribute to ALL to delete an obsolete database system from the SLD

repository, if it appears after data processing.


September 2012 25

Appendix E: Key and Normal Properties of Classes

Key Properties

SAP_ApplicationSystem Class:

CreationClassName

The name of the class for which you create instances. The correct value in this case is

SAP_ApplicationSystem.

Name

A compound string which is formed using the following pattern: <Internal

value>.<Property name>.<Property value>. The first part is the internal name of the

application system, for example, ExampleThirdPartySystem. Each system which is

installed is associated with one main computer system. The name of this computer system is used in the second part to guarantee different systems names. You have to replace

<Property name> with the constant SystemHome, and <Property value> with the name

of the corresponding computer system, which is also known as a host name. By default, host names in the SLD are written in lower case without any network domain, for example

ExampleHostname.sap.corp is written examplehostname. As a result, the value of the

Name property can be: ExampleThirdPartySystem.SystemHome.examplehostname.

SAP_ComputerSystem Class

CreationClassName


SAP_ComputerSystem.

Name

A unique identifier for the computer system. You can use any type of network name. It must be unique in the system landscape otherwise the network cannot work. By default, host names in the SLD are written in lower case without any network domain. For example

ExampleHostname.sap.corp is written as examplehostname. This means that you have

to use different SLD for network domains which have name conflicts at this level.

SAP_InstalledSoftwareComponent Class:

Name

Has the same value as the Name key property of the corresponding

SAP_SoftwareComponent instance, for example, EXAMPLE_ISC. You can see the key

properties of the SAP_SoftwareComponent class below.

SoftwareElementID

Identifies the different software components on a system. It is a 128-bit MD5hash value and is generated by the SLD.

Note This key property is automatically generated. The SLD calculates its value using the key properties of the instance and the associated system.

SoftwareElementState

The only possible value for a software component that is installed on an application system is

3 and means that the state is RUNNING.


September 2012 26

TargetOperatingSystem

Specifies the operating system environment of the software component. We recommend that

you set its value to 0.

Version

Has exactly the same value as the Version key property of the corresponding instance of the

SAP_SoftwareComponent class, for example, 1.2.0C.

Note According to the Common Information Model (CIM) standard, you can add further properties such as the BuildNumber property, which is a string with 64 characters.

SAP_InstalledProduct Class:

CollectionID

A 128-bit GUID which distinguishes installed products of the same type.

Note This key property is automatically generated. The SLD calculates its value using the other key properties of the instance.

ProductIdentifyingNumber (numeric type value)

This key property is propagated from the corresponding SAP_Product instance. It identifies

SAP products. Third-party products might not have this number. For third-party products, use

the default value 0.

ProductName

This key property is propagated from the corresponding SAP_Product instance and is an

abbreviation of the product name. The value must exactly match the value of the Name

property of the associated SAP_Product instance, for example, Example_Product.

ProductVendor

This key property is propagated from the corresponding SAP_Product instance and is the

name of the software vendor. We recommend that you use the vendor's name as a URL to

avoid naming conflicts. The value of ProductVendor must exactly match the value of the

Vendor property of the associated SAP_Product instance, for example, example.com.

ProductVersion

This key property is propagated from the corresponding SAP_Product instance and is a

version identifier of the product. The value of the property includes alphanumeric characters

which are separated by dots (.). The value must exactly match the value of the Version

property of the associated SAP_Product instance, for example, 1.2.0C.

SystemID

The value of this key property is the same as the value of the Name property of the

SAP_ApplicationSystem instance, for example,

ExampleThirdPartySystem.SystemHome.examplehostname. The system must be

additionally associated with the product that is installed. The installed products are associated indirectly with a third-party system by associations of type

SAP_InstalledSWComponentOnApplicationSystem between the system and the

software components that are installed.

SAP_SoftwareComponent Class:

Name

An abbreviation of the software component name, written in upper case, for example,

EXAMPLE_ISC.


September 2012 27

Version

A version identifier of the software component. The value of the property includes

alphanumeric characters, which are separated by dots (.), for example, 1.2.0C.

Vendor

The name of the software vendor as a URL, for example, example.com.

ElementTypeID

A vendor-specific ID for this software component. Set the value to 0 for each third-party

software component.

SAP_Product Class:

IdentifyingNumber

Identifies SAP products. Third-party products might not have this number. For third-party

products, use the default value 0.

Name

An abbreviation of the product's name, for example, Example_Product.

Vendor

The name of the software vendor. We recommend that you use the vendor's name as a URL

to avoid naming conflicts, for example, example.com.

Version

A version identifier of the product. The value of the property includes alphanumeric characters,

which are separated by dots (.), for example, 1.2.0C.

SAP_DatabaseSystem Class:

CreationClassName


SAP_DatabaseSystem.

Name

The name of the database system is formed as a compound name like the names of the other system classes. The first part is the internal database name, for example,

ExampleDBSystem. The internal database name has to be a value of the DBName normal

property. The second part consists of two pairs of <Property name>.<Property value>.

The first pair concerns the DBTypeForSAP normal property, which specifies the type of the

database system, and the second pair concerns the SystemHome normal property, which

specifies a computer name for this database. The normal properties of the

SAP_DatabaseSystem class are described below. As a result, the value of this property

would be: ExampleDBSystem.DBTypeForSAP.SAP.SystemHome.exampledbhost.

SAP_DatabaseInstance Class:

CreationClassName


SAP_DatabaseInstance.

Name

The name of the database instance is formed as a compound name in the same way as the

Name property of the corresponding SAP_DatabaseSystem instance. If the database system

includes only one database instance, the Name key property of the SAP_DatabaseSystem

and SAP_DatabaseInstance instances can be identical. For example, both of them can be:

ExampleDBSystem.DBTypeForSAP.SAP.SystemHome.exampledbhost.

If more than one database instance exists, only the first part of the name varies for the

different database instances, for example, you can replace ExampleDBSystem with

ExampleDBSystemInstance1, ExampleDBSystemInstance2, and so on.


September 2012 28

Normal Properties

You can specify normal properties for all classes except for the SAP_Product and

SAP_SoftwareComponent, which are classes from the SLD CR.

All other classes have the following common normal properties that have the same meaning:

Caption

A short textual description of the object with a maximum length of 64 characters. We

recommend that you set the Caption normal property for all instances.

Description

A textual description of the object with no length restriction.

Besides the common normal properties, some classes can have the following normal properties, which you can set or update:

SAP_InstalledSoftwareComponent Class:

Vendor

A string value which must be exactly the same as the value of the Vendor property of the

associated SAP_SoftwareComponent instance.

InstallType

A string value which specifies the way in which the first version of the software component has

been installed. The correct value is Other.

UpdateType

A string value which specifies the way in which this software element has been updated. The

correct value is Other.

SAP_InstalledProduct Class:

Name

An alias for the installed product. This alias may change over time. The maximum length of the alias is 256 characters.

InstallType

A string value which specifies the way in which the first version of the product was installed. The correct value is Other.

SAP_DatabaseSystem Class:

DBName

The internal name of the database system. Its value is the first part of the compound value of

the Name key property.

DBTypeForSAP

A three-character abbreviation for the database type. It is used as part of the value of the

Name key property. The possible values are: ORA, MSS, DB2, DB4, DB6, SAP, ADA, and INF.

Manufacturer

The official manufacturer of the database. The possible values are: Oracle, Microsoft,

IBM, Informix, SAP, and Unknown.

SystemHome

Specifies the name of the main computer for the database system. The property forms the last

component of the value of the Name key property. By default, host names in the SLD are

written in lower case without any network domain, for example

ExampleHostname.sap.corp is written examplehostname.


September 2012 29

Appendix F: Overview of sldreg Command Line Parameters

The following tables offer an overview of the sldreg command line parameters.

Data Parameters

Parameter Description

[-file <xml-file>]

This parameter is optional. It specifies the XML file that contains the transfer data. If it is not specified, the registration program uses the standard input instead.

[-stdin]

This parameter is optional. This is the default setting for the data input when no input file is set. If this option is specified, it overrides the file setting.

[-oldtransferdtd]

This parameter is optional. If it is specified, the XML file that is transferred to the SLD is structured in accordance with an older DTD. Only use this parameter if you want to transfer data for an SLD of a release lower than 2004s or if you are using the SAPOSCOL as a data source.

[-symbolfile <file>]

Optional file in the 'Properties' format (text lines in the format '<name> = <value>'). In the text data and the attribute values of the XML document (see option file '-file <file>'), all symbols of the type '${<name>}' are replaced with the relevant '<value>'. You can log the result of the text replacement with the options -datatrace and -httptrace. Available as of Enhancement Package 1 7.1 (7.11).

HTTP Connection Parameters


-connectfile <file> Specifies the file that contains the encrypted HTTP user, password, host, and port information. The data encryption standard (DES) is used to encrypt the HTTP connection information.

-user <http-user> Specifies the J2EE user for the HTTP connection. You can use this parameter as an alternative to specifying the HTTP connection parameters in a file.

[-pass <password>]

This parameter is optional. Specifies the password of the J2EE user for the HTTP connection. If it is not specified, the program uses an empty string.

-host <http-host> Specifies the host on which the HTTP connection is established.

-port <http-port>

Specifies the number of the port on which the HTTP connection is established.


September 2012 30

Note You can specify either a connection file or a valid set of HTTP user, password, host and port information. If you specify both, the connection file has priority over the set of HTTP information.

Configuration Parameters


-configure <file>

This parameter starts the configuration of the connection file. The connection information is encrypted and is stored in the file you specify

and you can use it in future together with the -connectfile parameter.

You have to use this parameter once to save the connection information to a file.

[-usekeyfile]

This parameter is optional. You can only use it in combination with the -

configure parameter. If you use this parameter, the system does not

use a fixed internal DES key to encrypt the data, but a randomly generated key instead. The key is automatically stored together with the file that contains the connection data. The name of this KEY file is created using a combination of the name of the connection parameter file and a KEY file extension. You also have to use this parameter if you set up an HTTP connection and if you want to specify the key for an external file.

Additional Parameters

Parameters Description

-help Displays help information.

-datatrace Activates a full data trace.

-httptrace Activates a trace for the HTTP connection.

-logfile <logfile>

Specifies the log file to which the program writes outputs, in addition to

the standard outputs. By default, the file is named stdout.

Note If you specify an unknown parameter, it is ignored.

Appendix G: Technical Notes on Using sldreg

The sldreg program is only a wrapper for the sldreglib.<dll|sl|so|o> dynamic link library

(DLL). Note that the actual library extension depends on the operating system (OS) platform that you

are using. sldreglib is not the only DLL that is required by the sldreg registration program.

The list of DLLs that are required includes the following files:


September 2012 31

SLD registration library: sldreglib.<dll|sl|so|o>

SAP STL port library: sapcpp46.<dll|sl|so|o>

SAP XML parser library: xml63d.<dll|sl|so|o>

Depending on the OS platform, the system searches for the DLLs in the following ways:

Microsoft Windows The system searches for the DLLs in the following order:

1. Directory of the sldreg executable.

2. Current working directory. 3. Microsoft Windows system directory, which is specified in the system properties by

the windir\system32 environment variable.

4. Microsoft Windows directory, which is specified in the system properties by the

windir environment variable.

5. Directories which are specified in the system properties as search directories by the

Path environment variable. The individual directory names are separated by a

semicolon (;).

AIX, HP Tru64 UNIX

The directories which contain the DLLs are specified by the LIBPATH environment variable.

The individual directory names are separated by a colon (:).

Other UNIX systems

The directories which contain the DLLs are specified by the LD_LIBRARY_PATH environment

variable. The individual directory names are separated by a colon (:).

Appendix I: Supplying Data to the System Landscape Directory Directly

via HTTP

The System Landscape Directory (SLD) provides a generic HTTP servlet to process data sent by data

suppliers. The servlet is used by the executable sldreg, for example. This chapter describes how you

can send data to SLD as a data supplier using any HTTP client in any programming language.

Note Readers are expected to be familiar with the HTTP protocol (RFC 2616).

2 HTTP Request

A data supplier request sent to SLD must fulfill the following requirements:

1. Send an HTTP POST request to the URL http://<host>:<port>/sld/ds.

Alternatively HTTPS can be used if the AS Java is configured accordingly.

2. Specify header Authorization using basic authentication.

The specified user must at least have J2EE security role DataSupplierLD. For a typical installation this can be achieved by assigning the user to group SAP_SLD_DATA_SUPPLIER.

If the AS Java is configured accordingly, a different authentication scheme may be used, for example certificate-based authentication for HTTPS.

3. Specify header dsxmlversion with value 2.0.

4. Specify header Content-Type with value application/xml; charset=utf-8.


September 2012 32

Recommendation

Optionally you may want to specify header User-Agent to identify your data supplier.

5. Add valid SLD data supplier XML encoded in UTF-8 as message body to your POST request (specifying additional HTTP headers appropriate for your transfer coding such as header Content-Length.)

Note

Additional HTTP headers (Accept headers, for example) may be specified, but are

ignored by the server currently.

3 HTTP Response

If your request is accepted by the server, an HTTP response with response code 200 will be returned.

Note Response code 200 does not indicate that your request has been processed successfully. It only indicates that your request has been parsed and queued for (asynchronous) processing. Whether data has been written successfully or not, can be checked with a WBEM client asynchronously only.

Your request may be rejected for various reasons. In such a case typical return codes are as follows:

400 Bad Request: For example, your XML may be invalid or was sent in other encoding

than UTF-8.

401 Unauthorized or 403 Forbidden: You have not specific valid authentication data or

the specified user does not have the necessary permission to supply data to SLD.

503 Service Unavailable: The SLD application is not active on the target server.

Note Starting with SAP NetWeaver 7.10, the next major SAP NetWeaver release, any response will

include header Server with value SLD/<version> Bridge where "version" indicates the

version of the SLD server (the lowest SLD server version setting this response header is 7.10.115). By checking this response header you can assure that the request has been sent to the correct URL.

http://scn.sap.com/docs/DOC-8042

Documents

Registering Third-Party Systems in the System Landscape Directory (SLD)a248.g.akamai.net/n/248/420835/022a0713df2358cb287f… · · 2015-12-17in the System Landscape Directory (SLD)