The system landscape directory application, normally referred to as the SLD, is hosted on any AS Java system in the customer’s site. It can be a central point to store data about the physical systems that are installed, plus details about the software products and software components that are available on those systems. It can be used by PI/XI and Solution Manager and also as a repository of JCo destinations for Web Dynpro Java applications.
The SLD is maintained by a system administrator using the /sld application, which nowadays is a Web Dynpro application. ABAP and Java systems can publish their information on a regular basis to the SLD via transaction RZ70 (ABAP) and the SLD data supplier (Java).
The SAP NetWeaver Portal can be used to provide single sign on to different applications. This can include ABAP based applications. The most flexible way to define access to ABAP based systems is by defining the system in the portal’s system landscape directory using the system landscape editor.
This is not the same as the SLD application! The portal’s system landscape directory is mainatined with the system landscape editor as an iView within the portal administration area. It stores the data in its own set of tables in the underlying AS Java database. It is not aware of the existence of an SLD application server.
So, why not try to synchronise the two?
This wiki page contains a portal component that can be used to create an entry in the portal’s system landscape directory based on details obtained from the SLD application.
It reads the SLD to find the known SID/client combinations and presents them as a dropdown list. Because the SLD does not know about hostnames containing domains, it also prompts for a domain name to be appended to the hostname.
For flexibility, it builds a system based on the load balanced template, and assumes a logon group called SPACE. The SLD does not know about ICM host and port information, so it points to the ICM on the central instance and uses port 80xx, where xx is the instance number.
No system alias is defined for the generated system in the portal, so this must be set afterwards. The SystemAlias property of the system object in the portal SLD is the logical system name. This confused me for some time!
Interestingly, the name of the client in the ABAP system as stored in table T000 does not seem to get populated into the SLD.