Developers' Guide for SLD/LMDB Data Suppliers - SAP

Developers' Guide

SAP Solution Manager

Document Version: 2.0 – 2018-11-09

PUBLIC

Developers' Guide for SLD/LMDB Data Suppliers SAP Solution Manager

2

PUBLIC

© 2016 SAP SE or an SAP affiliate company. All rights reserved.

Developers' Guide for SLD/LMDB Data Suppliers

Document History

Document History

Version Date Change

1.0 2012 First version

2.0 03.2016 Completely revised and newly structured version.

Ensure that you have the latest version of this document, which is available at

http://go.sap.com/documents/2015/07/441c1812-537c-0010-82c7-

eda71af511fa.html

Improved and updated templates can be found in an extra zip file at

https://wiki.scn.sap.com/wiki/download/attachments/170754506/DataSupp

lierDevSources.zip)

http://go.sap.com/documents/2015/07/441c1812-537c-0010-82c7-eda71af511fa.html

http://go.sap.com/documents/2015/07/441c1812-537c-0010-82c7-eda71af511fa.html

https://wiki.scn.sap.com/wiki/download/attachments/170754506/DataSupplierDevSources.zip



Contents

PUBLIC

© 2016 SAP SE or an SAP affiliate company. All rights reserved. 3

Contents

1 About This Document ................................................................................................................... 4

2 Background Information .............................................................................................................. 5 2.1 System Landscape Directory (SLD) .................................................................................................... 5 2.2 Landscape Management Database (LMDB) ....................................................................................... 6 2.3 SLD Data Supplier Infrastructure ......................................................................................................... 6

2.3.1 Generic SLD Data Suppliers ................................................................................................. 6 2.3.2 Reusable Executable for the HTTP(S) Request.................................................................. 6

2.4 CIM Model ............................................................................................................................................... 7

3 Step-by-Step Procedure ............................................................................................................... 8 3.1 Finding a Test SLD ................................................................................................................................. 8 3.2 Creating the XML Template .................................................................................................................. 8

3.2.1 Data Synchronization Principles .......................................................................................... 9 3.2.2 Adapting the existing XML templates ................................................................................ 11 3.2.3 Source for CR Content ........................................................................................................ 12 3.2.4 Validating the XML Template ............................................................................................. 12

3.3 Instrumenting the Software ................................................................................................................ 13 3.3.1 XML Document Creation .................................................................................................... 13 3.3.2 Posting the document ......................................................................................................... 13

3.4 Validating and Shipping ....................................................................................................................... 14

4 Appendix ....................................................................................................................................... 15 4.1 Checklist ............................................................................................................................................... 15 4.2 XML Elements ...................................................................................................................................... 15

4.2.1 <sldinfo> .............................................................................................................................. 16 4.2.2 <group> ................................................................................................................................ 16 4.2.3 <rootclass> .......................................................................................................................... 16 4.2.4 <memberclass> .................................................................................................................. 17 4.2.5 <instance> ........................................................................................................................... 19 4.2.6 <property> ........................................................................................................................... 19 4.2.7 <value> ................................................................................................................................. 19 4.2.8 <class> ................................................................................................................................ 20

4.3 Using the Executable sldreg[.exe] ..................................................................................................... 20 4.4 Sending Data Directly via HTTP(S) .................................................................................................... 22 4.5 Contact Support .................................................................................................................................. 23

4

PUBLIC



About This Document

1 About This Document

This guide describes the instrumentation of “technical systems” to register automatically in the System

Landscape Directory (SLD) and/or Landscape Management Database (LMDB). System registration is done by an

“SLD data supplier”. The information is required for use cases in SAP Solution Manager and Process Integration

(PI/XI), for example.

This document presents a roadmap for the development of a product-specific SLD data supplier. In case of

questions regarding the content of this guide, create a ticket under SV-SMG-LDB.


Background Information

PUBLIC


2 Background Information

SLD and LMDB provide central information about the elements in a system landscape. Both directories use the

SAP extension of the Distributed Management Task Force (DMTF) Common Information Model (CIM). Typical

model elements are "systems”, "computers”, "products” and "software elements”. For more information about

CIM, see DMTF.

Figure 1: Big picture of SLD and LMDB data flow. The software catalog (CR Content) is mapped at SAP to CIM and

shipped via SAP Service Marketplace. The system data are mapped to CIM when being received by SLD/LMDB.

Technical systems are of type “application system” in CIM. They are composed of software and hardware

elements deployed on top of “computer systems”. Each technical system is installed, configured, and

administered as a unit and thus independent of other technical systems. A technical system can be started and

stopped, it offers services when running.

2.1 System Landscape Directory (SLD)

The SLD is part of SAP NetWeaver AS Java. The directory comprises information about all installable software

(“CR content”) and the software that is really installed in the system landscape (“LD content”). The CR content is

downloaded from SAP Support Portal, the LD content is automatically updated by SLD data suppliers and it

http://www.dmtf.org/

6

PUBLIC




describes the structure of the systems (change rate of the structure elements lies in the range of weeks or

higher).

For more information on SLD see http://scn.sap.com/docs/DOC-8042 and http://scn.sap.com/docs/DOC-

8516.

2.2 Landscape Management Database (LMDB)

The LMDB is part of SAP Solution Manager AS ABAP (release 7.1 and higher). The vast majority of the content is

supplied via content synchronization from the SLD to the LMDB. The SLD data is enriched in the LMDB by

information that is not available in the systems itself. In contrast to the SLD, the LMDB directly serves the SAP

Solution Manager applications. For more information on LMDB see https://wiki.scn.sap.com/wiki/x/oUS7Gg and

https://wiki.scn.sap.com/wiki/x/Diu7Gg.

2.3 SLD Data Supplier Infrastructure

For many system types, generic SLD data suppliers already exist. And if your software is an add-on installed on

such a system, you do not need to develop an own SLD data supplier.

2.3.1 Generic SLD Data Suppliers

The most prominent SAP products bringing along a generic SLD data supplier are AS ABAP, AS Java, and the SAP

HANA DB. When following SAP’s rules for software deployment, these systems register your add-on together with

the system itself. No separate SLD data supplier needs to be developed.

The SAP host agent registers some basic software generically, like operating systems (OS), databases (DB) and

Microsoft .NET applications. No separate SLD data supplier needs to be developed for this kind of software, too.

Cloud services can be accessed via Internet URLs only. The system(s) behind the URLs shall be invisible to the

consumer. Registering such services by an SLD data supplier to the service consumer would violate the cloud

architecture. An SLD data supplier only makes sense at service provider side. At consumer side, the required

URLs are configured manually in SAP Solution Manager.

For a detailed overview about the existing SLD data suppliers, see SAP Note 1869701. For any other software, you

need to develop an own SLD data supplier for the integration into SAP Solution Manager or into SAP Process

Integration (PI/XI).

2.3.2 Reusable Executable for the HTTP(S) Request

A typical hurdle for the implementation of an SLD data supplier is the required HTTP(S) request and the secure

storage of the user credentials. It is an option to use the SAP executable sldreg[.exe] to overcome such

difficulties. More details about sldreg can be found in SAP Note 1018839 and in appendix 4.3 of this document.

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



https://wiki.scn.sap.com/wiki/x/oUS7Gg

https://wiki.scn.sap.com/wiki/x/Diu7Gg

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




PUBLIC


2.4 CIM Model

A general CIM tutorial is offered at http://www.dmtf.org. It takes 30 minutes and is a good start to explore the

SAP extension of the CIM model, which can be viewed in the SLD on the CIM Classes page. Textual descriptions of

all classes, associations, and properties as well as CIM class diagrams in PDF format can be studied there.

The table below lists the small CIM model subset which is required for a standard SLD data supplier. Make

yourself familiar with these classes and associations.

Standard SLD data supplier entity CIM Class / Association

System with optional sub-systems SAP_ApplicationSystem and its sub-

classes, SAP_ComputerSystem

Installed software SAP_InstalledProduct,

SAP_InstalledSoftwareFeature,

SAP_InstalledSoftwareComponent

Associations to CR content SAP_InstalledProductImage,

SAP_SoftwareFeatureType,

SAP_SoftwareComponentType

The generic SLD data suppliers in AS ABAP, AS Java, and SAP HANA DB provide more information than standard

SLD data suppliers. The most important additional entities are listed in the following table.

Extended SLD data supplier entity CIM Class / Association

Services Sub-classes of CIM_Service

Service access points Sub-classes of SAP_ServiceAccessPoint

SAP Support Packages SAP_InstalledSupportPackage


8

PUBLIC



Step-by-Step Procedure

3 Step-by-Step Procedure

The time required for the implementation of a new SLD data supplier is in the range of three to six weeks,

depending on the start knowledge and system complexity. The implementation comprises the following steps:

1. Find a test SLD (any AS Java installation, SAP NetWeaver 7.2 or higher recommended).

2. Build your own data supplier XML template, based on the existing templates.

3. Instrument your software for

1. creating the XML document, and

2. posting the XML document.

4. Validate and ship your SLD data supplier.

3.1 Finding a Test SLD

This step must be done at first and is absolutely necessary for success. Stop your activities if you cannot get

access to a test SLD.

Any AS Java installation contains the software required for the SLD, the application is enabled by SLD-specific

configuration. For details about the post-installation and configuration steps see

https://wiki.scn.sap.com/wiki/x/syq7Gg. SAP NetWeaver version 7.2 or higher is recommended.

One user in group or role SAP_SLD_DATA_SUPPLIER is needed for testing the data supplier. Another user in

group or role SAP_SLD_ADMINISTRATOR is needed for validation and test data preparation.

3.2 Creating the XML Template

With the knowledge provided by the CIM tutorial offered at DMTF and a rough understanding of the SAP CIM

extension model, you can select the XML template matching your use case. The following templates are offered:

1. Template for the integration into SAP Solution Manager

2. Template for the integration into SAP PI/XI

3. Abstract template for any kind of system

All templates start with a “key instance” of type SAP_ApplicationSystem (CIM class itself or a sub-class of it),

which describes the technical system being registered. All other information is grouped around this key instance.

If you cannot identify a suitable key instance in the existing templates, consider requesting a template for your use

case via incident on SV-SMG-LDB. CIM model extensions have to be requested via incidents, too. Use the detailed

class and property descriptions that are offered on the SLD page CIM Classes, during the implementation. The

understanding of CIM is also leveraged by browsing some existing system data on the SLD page CIM Instances.

The existing XML templates demonstrate the structure and the content of an SLD data supplier XML. Each

template consists of file pairs, each pair consisting of

https://wiki.scn.sap.com/wiki/x/syq7Gg




PUBLIC


1. An XML file showing the required XML tags and attributes

2. A properties file showing the parameter values to be filled

By default, the template for SAP Solution Manager and the template for PI/XI must be used. If the use case is

restricted, this limitation needs to be documented in the system manual. In any case we recommend creating an

own XML template before instrumenting the software.

3.2.1 Data Synchronization Principles

The XML document of any SLD data supplier contains the new system data plus synchronization rules defining

the way how the current SLD/LMDB data is adapted to the new system data. The synchronization rules are

explained in this chapter.

The atomic elements being synchronized are “association groups”, each containing a single CIM “root element”

together with an arbitrary number of CIM “member elements”. All member elements are associated to the root

element with associations of the same CIM association class.

Figure 2: Typical elements affected by the synchronization of an association group

In Figure 2, the XML document contains an association group with root element R1 and member elements M1,

M2, and M3. Only three of these elements exist on the server yet, member element M2 does not exist. Also

association R1M3 does not exist on the server.

The white boxes in Figure 2 introduce some additional elements existing on the server, which are related to this

association group, but do not belong to it. An additional member element M0 together with association R1M0 was

created in the past. This additional member has an additional root element R0 associated with M0. The

association class of R0M0 may differ from the other associations, in other words, root element R0 may belong to a

10

PUBLIC




different kind of association group. Last but not least a different root element R2 is associated with M3 on the

server.

All additional elements in Figure 2 are candidates for implicit deletion and marked with red lines. The proper

processing of these additional data depends on the CIM model and the completeness of the data in the XML

document. Data processing is specified by synchronization rules for each association group with XML attributes.

The most important attributes are described in the following table.

XML Attribute Value Effect

sync TRUE Create this element (root or member) if it does not exist yet. Set the CIM

properties to the values in the XML document.

FALSE Do not create or change the element (root or member), just synchronize

the association.

merge_members TRUE Do not cut member associations of the same CIM association that exist

on the server (SLD/LMDB), but are not present in the data. In the figure

above, association R1M0 will be kept.

FALSE Cut member associations of the same CIM association that exist on the

server (SLD/LMDB), but are not present in the data. In the figure above,

association R1M0 will be deleted.

merge_roots TRUE Do not cut associations of members to other root elements (same CIM

association class) that exist on the server (SLD/LMDB), but are not

present in the data. In the figure above, association R2M3 will be kept.

FALSE Cut associations of members to other root elements (same CIM

association class) that exist on the server (SLD/LMDB), but are not

present in the data. In the figure above, association R2M3 will be deleted.

clean NONE Do not touch the root or member element when the association was cut.

In the figure above, M0 and R2 will be kept.

LONE Remove the root or member element when the association was cut and

the element has no other association of any kind. In the figure above, M0

will be kept, but R2 will be deleted when R2M3 is deleted.

ALL Remove the root or member element when the association was cut.

Remove all other associations of any kind this way. In the figure above,

M0 will be deleted when R1M0 is deleted and R2 will be deleted when

R2M3 is deleted. The deletion of M0 implies the deletion of R0M0, but R0

will be kept, because M0 is not a member of the association group

anymore.

From the use case perspective of the data supplier, the following synchronization patterns can be mapped to the

XML attributes listed above:

• An element is created in the XML document (sync = TRUE) and later on listed again in another association

group

o In the second group, specify only the CIM key properties and set sync = FALSE

• The list of members in the association group of the XML document is complete:

o Specify merge_members = FALSE.



PUBLIC


• The maximum cardinality of the association at member side is 1:

o Specify merge_members = FALSE.

• The maximum cardinality of the association at root side is 1:

o Specify merge_roots = FALSE.

• The member elements exclusively belong to the root element of the association group, a member without

such root element would not make sense:

o Specify merge_members = FALSE and clean = ALL.

For a better understanding of the XML attributes, make a sketch of the concrete association group during

template development like it is done in Figure 2. Further information about all defined XML elements can be found

in the appendix 4.2 of this document.

3.2.2 Adapting the existing XML templates

The selection of the best start templates for your XML template depends on your use case.

• Integration of an “unspecific” technical system into SAP Solution Manager:

o Use template folder SolMan.

• Integration of a third-party technical system into PI/XI:

o Use template folder PI.

• Integration of a specific technical system into SAP Solution Manager:

o Use template folder Abstract.

Unpack the template ZIP archive at

https://wiki.scn.sap.com/wiki/download/attachments/170754506/DataSupplierDevSources.zip to any

directory. In the standard use case select one template in folder SolMan and use the template in folder PI as

starting point. If no PI/XI integration is requested, just select the appropriate SAP Solution Manager template to

start with.

All folders contain a README.TXT and the properties and XML files contain comments, which guide you through

the template usage. Do not deviate from the suggestions for structure and content, such as the following, without

need:

• A Caption property shall be always defined for a new CIM instance.

• The uniqueness of the CIM key properties must be guaranteed. It must not be possible that two systems in a

network with different hostnames collide with their CIM key.

• Do not set additional properties for classes which may be included in other SLD data suppliers. Class

SAP_ComputerSystem is the most prominent example for this case. Every SLD data supplier includes

instances of SAP_ComputerSystem, but only the SAP host agent shall set all properties of the CIM class to

avoid conflicting data which would lead to toggling values in SLD/LMDB.

Create your own XML template to become familiar with the XML elements and to validate your template before

instrumenting your software.


12

PUBLIC




3.2.3 Source for CR Content

The content of the SLD data supplier templates contains links to CR content. It is not possible to include the CR

content itself in the data supplier XML (CIM instances of SAP_Product, SAP_SoftwareFeature or

SAP_CoherentSoftwareUnit, and SAP_SoftwareComponent). Only the installed software shall be registered

by the system, the software catalog data must be delivered separately. For this reason, writing CR content needs

more permissions than those provided by role SAP_SLD_DATA_SUPPLIER. There are two ways to deliver CR

content:

• The preferred way to deliver the CR content instances is the definition of the product in the internal Product

and Production Management System (PPMS) at SAP. Contact SAP to include your product definition into

SAP PPMS. The required key properties of the CIM classes described above will be sent back to you. The

product definition is then shipped to all SAP customers with the next SAP CR content update (SAP Note

669669).

• Alternatively, you can create your own product definition in your test SLD and to export this into a ZIP file.

This ZIP file needs to be included into your shipment and needs to be imported into SLD at customer site. Go

to the SLD page Products and press New… to create a third-party product, product instance, and software

component in your test SLD. Use capital letters, numbers, and underscores for all names. Enter dot-

separated numbers for the versions. Use an Internet domain owned by your company for the vendor. When

the data are saved, select the new product and choose Export to create the ZIP file.

Besides the different vendor value, an own product description contains CIM class SAP_SoftwareFeature for

the product instance instead of SAP_CoherentSoftwareUnit.

3.2.4 Validating the XML Template

The XML file and property file are used to test the system registration with the executable sldreg[.exe]:

sldreg -connectfile <connect file> -logfile <log file> -symbolfile <properties files>

-file <XML file>

Validate the result in the SLD by three checks:

1. Browse the registered data on CIM Instances.

2. Check Administration -> Log to be free of errors and warnings at registration time.

3. Check Administration -> Changes to be free of deletions at registration time.

The last check prevents any undesired state toggling, which happens if your XML contains contradictory data, for

example first create, then delete, and afterwards re-create again. Such toggling must be avoided because each

system registration would flood the database with unwanted change log entries for toggling values.

In addition to a single test registration, call sldreg twice shortly after each other at the end of your validation.

This procedure forces the SLD to process the XML even if no data have changed in the XML. Afterwards in

Administration -> Changes, you should only see modifications of the key instance and the “data supplier

collection” instance (CIM class SAP_SuppliedElements). Any other change indicates contradictory data in the

XML, which needs to be fixed.





PUBLIC


3.3 Instrumenting the Software

The goal of the software instrumentation is the automation of the registration process. Once configured, the

system is initially registered and afterwards any configuration change is automatically updated in SLD/LMDB:

• A simple approach is the regular registration once or twice a day together with a registration at system

startup. Many configuration changes need a system restart and the systems typically offer a trigger for

system startup. Most SLD data suppliers follow this approach.

• If the software offers a trigger for configuration changes, an immediate registration of changes is possible.

However, fast value toggling must be taken into account, the maximum registration rate shall be 10 minutes.

• A third variant regularly compares the current configuration with a previous state, for example every 10

minutes. Only in case of a parameter change the registration is executed. In this variant, use a minimum

registration rate, for example once per day. This allows the detection of outdated system data in SLD/LMDB.

And the maximum registration rate shall not be higher than 10 minutes.

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

3.3.1 XML Document Creation

Each parameter in the properties file of the XML template needs to be retrieved from your system at runtime.

Special consideration is required in the following cases:

• Error during parameter retrieval:

o Decide between complete abort, omit <group>, omit <instance>, or omit <property> tag

o Key properties must not be omitted

o The first <group> must not be omitted

o Omitting a <group> keeps the current state of this association group in SLD/LMDB

o Omitting an <instance> changes the state of the association group, even when no <instance> remains

in the XML document

• Empty value retrieved:

o For key properties, treat it like an error during parameter retrieval

o For non-key properties, supply an empty <value>

• List of values is retrieved:

o One <group>, <instance>, or <value> tag per retrieved value

The XML document generated at runtime typically contains the parameter values, no symbols anymore. When

possible, the generated XML document should be written into a file on the file system. This allows simple tracing

at data supplier side in case of errors. The tracing capabilities at SLD side are described in SAP Note 1143398.

3.3.2 Posting the document

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[.exe] executable or an own HTTP client for this data

transfer. An own HTTP client must meet the SAP security requirements, see appendix 4.4 for details.


14

PUBLIC




The SLD server responds with an HTTP return code on successful receiving of the payload XML. Response code

200 does not indicate that the XML has been processed successfully, this happens asynchronously in SLD.

Typical error response codes are:

• 400 Bad Request: the XML may be invalid

• 401 Unauthorized: authentication invalid

• 403 Forbidden: permissions insufficient

• 503 Service Unavailable: the SLD application has not been started

3.4 Validating and Shipping

Validate the instrumentation in the same way as described for the template (chapter 3.2.4). The three checks

described there guarantee that the XML is free of errors and free of delete + re-create patterns.

The software should be shipped together with the product at best. In addition, the configuration of the SLD data

supplier as part of the product installation is recommended.


Appendix

PUBLIC


4 Appendix

4.1 Checklist

The following checklist can be used for the validation of your SLD data supplier implementation.

Action Result

□ Find a test SLD (AS Java installation plus

SLD-specific configuration)

Access to an SLD in group or role

SAP_SLD_ADMINISTRATOR with one user and group or

role SAP_SLD_DATA_SUPPLIER with another user.

□ Build your data supplier XML template

based on the existing templates

CIM meta model and CIM system model are understood

(use CIM tutorial). The SAP term “technical system” is

understood.

Existing data supplier templates are understood. Own

system components are mapped to the SAP CIM model

extension. Your data supplier XML template can be sent

to SLD using sldreg[.exe].

□ Instrument your software – XML

document creation

All parameter values can be retrieved at runtime.

Potentially missing values have been identified.

The XML document is created at runtime and fits to

your XML template. Missing values or errors during

data retrieval are treated in the right way.

□ Instrument your software – Posting the

document

The XML can be sent to SLD, either directly by an HTTP

POST request or by calling sldreg[.exe].

□ Validate and ship your SLD data supplier XML document content is validated. The system

registers changes automatically and reliably at latest

after 24 hours. The data supplier configuration is

documented.

4.2 XML Elements

All XML elements described in this appendix are also described in file data_supplier.dtd, which can be found

at https://wiki.scn.sap.com/wiki/download/attachments/170754506/DataSupplierDevSources.zip.

The synchronization principle for association groups is explained in chapter 3.2.1 of this document.


16

PUBLIC



Appendix

4.2.1 <sldinfo>

The top level element of the payload XML has a few attributes which shall be defined to specify the product

specific data supplier. Either keep the SAP template values or define your own supplier name, vendor, version,

and minimum model version.

<sldinfo>

Attribute Value Details

supplier_name <name of the data

supplier>

The data supplier name must be unique. Follow the

instructions given in the XML templates to specify this

name

supplier_vendor <vendor of the

data supplier>

“sap.com” or an Internet domain owned by your

company

supplier_version <version of the

data supplier>

The version corresponds to the version of the data

supplier. Start with version 1.0.

model_version <minimum CIM

model version>

This is the minimum CIM model required in SLD. Take

the model version in your test SLD as value.

4.2.2 <group>

Each <group> element contains either an association group or a simple list of CIM instances. The groups are

processed in the order in which they appear. The only attribute to be set is name and it must be unique in the XML

document. If several groups with different root elements have to be specified, add a counter suffix to the group

name. Further XML attributes are defined in the DTD, but ignored by SLD/LMDB.

<group>


name <group name> The name of the group which is used for tracing

purposes. Therefore, the value should be meaningful

and unique in the XML document.

4.2.3 <rootclass>

Each association group contains one <rootclass> tag which defines the root element. All member elements in

this group are referring to this root element.


Appendix

PUBLIC


<rootclass>


name <CIM class name> Specifies the CIM class name of the root element.

sync TRUE|FALSE Create or change the root element (TRUE) or

presume the root element to be already

synchronized (FALSE).

merge_roots TRUE|FALSE Keep additional associations of the member

elements to other root elements (TRUE) or cut those

additional associations on the server (FALSE).

clean NONE|ALL|LONE Specifies the handling of the root element side of

associations being cut. Other parameter values than

NONE make only sense, if <merge_roots> is set to

FALSE.

NONE: Do not delete such elements

LONE: Delete root elements being cut from member

elements if they are not associated to any other CIM

instance

ALL: Delete all such elements

merge_properties TRUE|FALSE Specifies the handling of root element properties

which are not contained in the XML document.

Typically those properties should not be touched

(TRUE). Setting value FALSE will delete all additional

properties of the root element. The parameter makes

only sense, if <sync> is set to TRUE.

4.2.4 <memberclass>

Each association group contains one or more <memberclass> tag(s), each of them defining the list of member

elements being associated to the root element with one specific association. An empty list of member elements

does make sense if all existing associations to members shall be cut.

Specifying several <memberclass> tags for one <rootclass> tag is equivalent to several <group> tags with the

same <rootclass> and a single <memberclass> tag.

<memberclass>


name <CIM class name> Specifies the CIM class name of the member

element.

18

PUBLIC



Appendix

association_name <CIM association

name>

Specifies the CIM association name between the root

element and all member elements.

root_role <CIM association

role of the root

element>

Specifies the role of the root class in the association

member_role <CIM association

role of the member

element>

Specifies the role of the member class in the

association

sync TRUE|FALSE Create or change the member element (TRUE) or

presume the member element to be already

synchronized (FALSE).

merge_members TRUE|FALSE Keep additional associations of the root element to

other member elements (TRUE) or cut those

additional associations on the server (FALSE).

clean NONE|ALL|LONE Specifies the handling of the member element side of

associations being cut. Other parameter values than

NONE make only sense, if <merge_members> is set to

FALSE.

NONE: Do not delete such elements

LONE: Delete member elements being cut from the

root element if they are not associated to any other

CIM instance

ALL: Delete all such elements

merge_properties TRUE|FALSE Specifies the handling of member element properties




properties of the member element. The parameter

makes only sense, if <sync> is set to TRUE.

mergeRootClass <Root CIM class

name for merge>

Specifies the CIM class name of other root elements

read from the server. The attribute is needed in the

rare case that a parent class of the root element has

to be used for merging the XML document with the

server state.

mergeMemberClass <Member CIM class

name for merge>

Specifies the CIM class name of additional member

elements read from the server. The attribute is

needed in the rare case that a parent class of the

member elements has to be used for merging the

XML document with the server state.

mergeAssocClass <Association CIM

class name for

merge>

Specifies the CIM association name referring to

further root or member elements read from the

server. The attribute is needed in the rare case that a

parent class of the association class has to be used

for merging the XML document with the server state.


Appendix

PUBLIC


optional TRUE|FALSE Specifies error handling for non-existing member

elements, when <sync> is set to FALSE. A missing

member element normally leads to the error

message that the association could not be created

(optional = FALSE). Set optional = TRUE to suppress

this error message, for example for CR content

member elements.

4.2.5 <instance>

Each CIM instance is described by this XML element. All CIM key properties must be specified at least. For

synchronized CIM instances (create or update), also specify the "Caption" property. The maximum length of a

caption is 64 characters. Attribute inst_id is deprecated and should not be specified.

4.2.6 <property>

Contains a single CIM property or property array. Only a property array may include several values.

<property>


name <CIM property

name>

The name of the CIM property.

sourceformat <date format

descriptor>

Specifies the format for date strings. Only a small

sub-set of date string formats is supported. The

recommended value is yyyy-MM-dd HH:mm:ss.

4.2.7 <value>

Contains a single CIM property value. Escape XML control characters in the character data:

• '&' -> "&"

• '<' -> "<"

• '>' -> ">"

• ''' -> "'"

• '"' -> """

If characters need to be escaped and sldreg[.exe] is used, a minimum version of sldreg[.exe] is

recommended, see SAP Note 1382650.


20

PUBLIC



Appendix

4.2.8 <class>

A class element defines instances of an individual class, without information about associations to instances of

other classes. With this XML element it is possible to create, update, or delete individual CIM instances. The class

element is rarely used because association groups typically fit better to the use cases.

<class>


name <CIM class name> Specifies the CIM class name of the CIM instances.

sync TRUE|FALSE Create or change the CIM instance (TRUE) or

presume the instance to be already synchronized

(FALSE).

clean NONE|DELETE Specifies whether the CIM instance should be

created/updated or deleted.

NONE: Change/update all instances

DELETE: Delete all instances

merge_properties TRUE|FALSE Specifies the handling of root element properties




properties of the instances. The parameter makes

only sense, if <sync> is set to TRUE.

4.3 Using the Executable sldreg[.exe]

Use a new version of sldreg[.exe].The availability, configuration, and error analysis is described in SAP Note

1018839 and SAP Note 1382650.

The typical usage of sldreg[.exe] consists of two command line calls:

1. sldreg –configure slddest.cfg –usekeyfile

o You are prompted to enter the HTTP connection parameters.

o The files slddest.cfg and slddest.cfg.key are written.

2. sldreg –connectfile slddest.cfg –file mydata.xml

o The content of file mydata.xml is sent to the SLD.

Besides these typical calls, the executable offers further options which are listed by the program usage (sldreg

-help) and in the following table. Older versions (< 7.2) do not offer all options listed here.





Appendix

PUBLIC


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 and must be specified only if you are using

saposcol –b as data source.

[-symbolfile <file>] Optional properties file (text lines in the format “<name> = <value>”). In the

XML text data and attribute values, all symbols in format “${<name>}“ are

replaced with the relevant <value>. You can log the result of the symbol

replacement with the options -datatrace and -httptrace.

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

information.

[-user <http-user>] Specifies the SLD user for the HTTP connection. You can use this parameter

together with the next three parameters as an alternative to specifying the

HTTP connection parameters in a file.

[-pass <password>] Specifies the password of the SLD user for the HTTP connection.

[-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.

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. Use this file with

the -connectfile parameter later on. Many data suppliers specify

slddest.cfg as filename.

22

PUBLIC



Appendix

[-usekeyfile] This parameter is optional, but recommended. 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 adds the

file extension .key to the connection filename.

-showconnect <file> Display the content of a connection file besides the password.

Additional Parameters

Parameters Description

-help Displays help information.

-datatrace Activates a 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, the help information is displayed.

Note

HTTPS is not supported in SAP NetWeaver 7.0

4.4 Sending Data Directly via HTTP(S)

The SLD provides a generic HTTP servlet to process data sent by data suppliers. The servlet is used by the

executable sldreg[.exe], but can also be used by any other HTTP client in any programming language.

Readers of this appendix are expected to be familiar with the HTTP protocol (RFC 2616).

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.

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

2. Specify header Authorization using basic authentication.

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.

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


Appendix

PUBLIC


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). Additional

HTTP headers (Accept, for example) may be specified, but are ignored by the server.

If your request is accepted by the server, an HTTP response with code 200 is returned. 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.

Note: In case of returned HTTP response with error code, the data supplier should not retry to send the data

immediately. The standard, regular registration according to the configured time interval (default: 12 hours) is

sufficient, also for error situations. Otherwise the target system would be flooded with data supplier requests.

Starting with SAP NetWeaver 7.1, the response includes header Server with value SLD/<version> Bridge

where <version> stands for the version of the SLD server. By checking this response header you can assure that

the request has been sent to an SLD.

4.5 Contact Support

Search for SAP Notes before contacting SAP support. Especially SAP Note 1382650 might be helpful.

If notes do not help, create an incident under SV-SMG-LDB.


www.sap.com/contactsap


No part of this publication may be reproduced or transmitted in any

form or for any purpose without the express permission of SAP SE

or an SAP affiliate company.

SAP and other SAP products and services mentioned herein as well

as their respective logos are trademarks or registered trademarks of

SAP SE (or an SAP affiliate company) in Germany and other

countries. All other product and service names mentioned are the

trademarks of their respective companies. Please see http://www.

sap.com/corporate-en/legal/copyright/index.epx#trademark for

additional trademark information and notices.

http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark

http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark

Developers' Guide for SLD/LMDB Data Suppliers - SAP

Documents

Transcript of Developers' Guide for SLD/LMDB Data Suppliers - SAP