System landscape directory vs portal system landscape editor
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.
I liked how clear and concise you made this but when you answer the question -
"So, why not try to synchronise the two?" you provide a means of duplicating it into the Portal which is cool but it's really a once only kind of synchronisation).
So coming back to your initial question, I would love to know if SAP ever plan to truly synchronise the two and possibly give total control to the SLD in the future. For example, how about providing a CIM attribute which is bound to a landscape tier (like in PI does with transport targets). This would allow the alias to be set within the SLD, and determined at runtime by the Portal so it could be the different systems could have the same alias in different tiers. No more directly changing the System Alias in production Portals!
I'm sure the answer is that there are plenty of other things SAP can be working on, but it is odd that the Systems still allow you to create this technical info rather than getting it from the SLD like your wiki code demonstrates...SLD has been around for quite some time now!
Anyway, again, very good blog, especially how clear you make it to understand unlike my reply!
Cheers,
Matt
Thanks for the feedback. I'm not sure I'd want the SLD to be required at runtime, a la PI, so I'd like to treat it more like SolMan does. Extra CIM attributes to handle ICM would be nice as would known portal aliases, as you mention.
Will it happen? Who knows, but I think it certainly a worthwhile concept!