Registering 3rd Party Systems in SLD - SAP
-
Upload
khangminh22 -
Category
Documents
-
view
1 -
download
0
Transcript of Registering 3rd Party Systems in SLD - SAP
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.
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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:
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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
Registering 3rd Party Systems in SLD
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).
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in 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).
Registering 3rd Party Systems in SLD
September 2012 13
Appendix
Appendix A: sldreg DTD
<!-- Version 1.2: DTD for generic buider - <!ELEMENT sldinfo (group*)> <!ATTLIST sldinfo supplier_name CDATA #REQUIRED supplier_vendor CDATA #REQUIRED supplier_version CDATA #IMPLIED model_version CDATA #IMPLIED > <!-- Data groups are used to set the synchronization rules for a data portion. The name of a group must be unique for each sldinfo. Attribute "group_type" is currently ignored by SLD bridge. --> <!ELEMENT group ((rootclass,memberclass+)|class*)> <!ATTLIST group name CDATA #REQUIRED group_type (GENERIC|SPECIFIC) "GENERIC" data_type CDATA #IMPLIED data_version CDATA #IMPLIED > <!-- Defines instances of an individual class, without information about associations to instances of other classes. Attributes: name = specify the CIM class name, e.g. SAP_ComputerSystem --> <!ELEMENT class (instance*)> <!ATTLIST class name CDATA #REQUIRED sync (TRUE|FALSE) "TRUE" merge_properties (TRUE|FALSE) "TRUE" clean (NONE|DELETE) "NONE" > <!-- The root class of a group (may be associated with members). Attributes: name = The CIM class name, e.g. SAP_ComputerSystem --> <!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" > <!-- A member class defines the association(s) and associated instance(s) which will be associated the root class instance in the same group. Attributes: name = The CIM class name, e.g. SAP_ComputerSystem mergeRootClass = The filter parameter (in association traversal) for the root class used to determine the set of instances that are evaluated for member merging. If
Registering 3rd Party Systems in SLD
September 2012 14
no value is specified, the class name of the root instance is used. For example, this value can be used to filter for a super class of the root class instead. mergeMemberClass = Analogous to "mergeRootClass" for the member class. mergeAssocClass = Analogous to "mergeRootClass" for the association class. --> <!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" > <!-- Use this tag for a CIM instance. Minimal you need the CIM key properties. --> <!ELEMENT instance (property*)> <!-- Use this tag for a single instance property or property array --> <!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
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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
Registering 3rd Party Systems in SLD
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
Registering 3rd Party Systems in SLD
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
Outdated Memberclass instance
Association1_Inst1Association1_Inst3
Class2_Inst2Class1_Inst1Association1_Inst2
Class2_Inst3
Rootclass instance
Class2_Inst1
Outdated Memberclass instance
Association1_Inst1Association1_Inst3
OtherClass_Inst1
OtherAssociation_Inst1
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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.
Structure of the Group:
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.
Attributes of the <rootclass> Element:
Set the name attribute to SAP_ApplicationSystem.
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.
Attributes of the <memberclass> Element:
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.
Registering 3rd Party Systems in SLD
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.
Structure of the Group:
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.
Attributes of the <rootclass> Element:
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.
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 FALSE, because each software component that is installed
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 name attribute to SAP_InstalledSoftwareComponent.
Set the association_name attribute to SAP_CollectedSoftwareComponents.
Set the root_role attribute to Collection.
Set the member_role attribute to Member.
Registering 3rd Party Systems in SLD
September 2012 22
Set the sync attribute to FALSE, because the instances are 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_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 name attribute to SAP_ApplicationSystem.
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.
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.
Structure of the Group:
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.
Attributes of the <rootclass> Element:
Set the name attribute to SAP_InstalledSoftwareComponent.
Set the sync attribute to FALSE, because you use the group only to establish an association
between two existing instances.
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 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.
Registering 3rd Party Systems in SLD
September 2012 23
Attributes of the <memberclass> Element:
Set the name attribute to SAP_SoftwareComponent.
Set the association_name attribute to SAP_SoftwareComponentType.
Set the root_role attribute to Dependent.
Set the member_role attribute to Antecedent.
Set the sync attribute to FALSE, because the instance must be present in the CR of the SLD
server.
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_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.
Structure of the Group:
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.
Attributes of the <rootclass> Element:
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.
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 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.
Attributes of the <memberclass> Element:
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.
Registering 3rd Party Systems in SLD
September 2012 24
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_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.
Structure of the Group:
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 name attribute to SAP_ApplicationSystem.
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
take effect, if the sync attribute is set to FALSE.
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.
Attributes of the <memberclass> Element:
Set the name attribute to SAP_DatabaseSystem.
Set the association_name attribute to SAP_ApplicationSystemUsingDB.
Set the root_role attribute to Dependent.
Set the member_role attribute to Antecedent.
Set the sync attribute to TRUE to register a new database system or update an existing one.
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_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.
Registering 3rd Party Systems in SLD
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
The name of the class for which you create instances. The correct value in this case is
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.
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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
The name of the class for which you create instances. The correct value in this case is
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
The name of the class for which you create instances. The correct value in this case is
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.
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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
Parameter Description
-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.
Registering 3rd Party Systems in SLD
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
Parameter Description
-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:
Registering 3rd Party Systems in SLD
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.
Registering 3rd Party Systems in SLD
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.