This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

SAP SLD Change Log Cleanup Table Reorg

When you apply changes or content updates to the SLD (system landscape directory) in SAP, the change log grows.
It’s possible to see the change log entries from the SLD administrator page.
Due to this growth, the underlying database table will benefit from reorganisation at some point.
In our scenario, this was on DB2.
We decided to run the cleanup, but first here was the size of the table BC_SLD_CHANGELOG:

db2prd> db2 “SELECT TABNAME, NPAGES FROM SYSCAT.TABLES
ORDER BY NPAGES DESC”
TABNAME                       NPAGES
—————————- ——————–
BC_SLD_CHANGELOG              14162
BC_SLD_INST                   12830
J2EE_CONFIGENTRY              5870
BC_SLD_ASSINST                3905
EP_ATTR_VALUES3               3082
J2EE_CONFIG                   2163
DBH_STG_PKG_CACHE_METRICS     1421
SYSCOLDIST                    1193

Then delete the change log in https://<server>/sld
Select “Administration -> Maintenance -> Clean Up Change Log -> Remove Entries”.
I then scheduled a standard job to do this work from the “Cleanup Task Configuration” tab.
Finally, reorg the following tables to release the space:

db2 “REORG INDEXES ALL FOR TABLE SAPPODDB.BC_SLD_CHANGELOG”

db2 “runstats on table SAPPODDB.BC_SLD_CHANGELOG AND INDEXES ALL”

db2 “SELECT TABNAME, NPAGES FROM SYSCAT.TABLES WHERE TABNAME = ‘BC_SLD_CHANGELOG'”

TABNAME                       NPAGES
—————————- ——————–
BC_SLD_CHANGELOG              1205

That’s it.

Why You Should Never Use J2EE_ADMIN for SLD Access

If you have a SAP Java stack (either pure or part of a dual stack), you should never ever use the J2EE_ADMIN account (or any other high privileged account) to access the SLD.
This is because on most SAP systems, the standard out-of-the-box installation and configuration for the SLD does not use SSL for communications to/from the SLD.

If you use the J2EE_ADMIN account to access the SLD, then each authentication  request that the SLD issues to the client system (the SAP system querying or updating the SLD) will be sent unencrypted.
If the client system responds with the J2EE_ADMIN account username and password (if you put this in the NWA or RZ70) then the username and password are simply combined into a standard HTTP BASIC authentication response (https://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA).

Essentially the username (J2EE_ADMIN) and password are combined into a string like this:  <user>:<password> and then encoded (not encrypted) with BASE64.
This will then be sent in the clear (unencrypted) across the network to the SLD.
If you have Java stack full HTTP tracing turned on, you can see the authentication requests and responses and therefore see the password.
If you have a network packet sniffer installed, then you can see the authentication requests and responses and therefore see the password.

If you have a SAP PI system, you should really consider using SSL (HTTPS) for the SLD traffic.  Since it is possible to completely bring down a SAP PI system by causing mayhem in the SLD.

Connecting SAP Netweaver ABAP Stack To SAP SLD

If you’ve ever quickly needed to know the points to check for customising settings connecting your SAP Netweaver *ABAP* system to an SLD (System Landscape Directory), then here they are:

Transaction: SLDAPICUST
Transacion: RZ70
Transaction: SM59 – TCP/IP connections: SAPSLDAPI (Use by ABAP API)
                                                                 LCRSAPRFC  (Use to read the exchange profile)

Here’s the SAP Help article: https://help.sap.com/saphelp_nw04s/helpdata/en/be/6e0f41218ff023e10000000a155106/content.htm