How to Handle SLD in PI landscape

In this WIKI, I want to share with you about the main mechanism of SLD in overall PI landscape, and how to resolve the SLD inconsistency issue. 

At the beginning, just show you some basic knowledge for the System Landscape Directory (SLD) in SAP XI.  

Please note that all the cases are relevant with the situation where you use the single SLD, which includes local SLD or central SLD, but not relevant with the
Multiple SLDs(several sub-SLDs and one master SLD). We recommend that you use a single SLD The cost of running the SLD infrastructure increases with
the number of SLD instances. Unless you have the special reasons(Legal constrains, Company rules, Network constrains), single SLD is preferred.

SAP XI has several SLD use cases, mainly as follows:

• The SLD acts as a server for application business system names for the receiver Determination in the Integration Directory. Therefore, all business systems must be available in SLD.
• The SLD acts as a server for application business system names for application systems to get their own business system name (Java Proxy Framework and SAP systems).
• The SLD provides the transport targets for Integration Directory content transports, such as from a business system in a development environment to a business system in a test environment.
• The SLD provides all systems and adapters for the end-to-end monitoring in the Runtime Workbench assigned to an Integration Server.
• The SLD provides the address for the transfer of adapter configuration data from the Integration Directory to the adapter cache.
• The SLD contains functions for software component version management.

Before we go through the SLD for XI, I will show you the SLD data supplier for normal Netweaver ABAP and JAVA system, since the supplier configuration is the same for PI. 
Any ABAP and JAVA system which connects to SAP is treated as a SLD Client, they should transfer their data periodically to SLD to make SLD up-to-date. 

• Auto-Registration at the system startup
• Periodical reporting of up-to-date system information via an SLD bridge
• Available for
  • SAP Web Application Server (ABAP)
  • SAP Web Application Server (Java) 
    
    

• The data supplier within an ABAP-based system periodically delivers collected system information.
• The SLD bridge transfers this information as CIM-compliant data to the SLD server.
• Data suppliers are available for SAP Web Application Server release ≥ 6.30

Data Supplier for ABAP-Based Systems – TA RZ70
 

If you schedule the background job, the destinations SLD_UC and SLD_NUC will be created automatically. Please note that we don’t need  SAPSLDAPI and LCRSAPRFC anymore.

For more details about the SLD connection between ABAP system and Java SLD, please check the following blog as well:

http://scn.sap.com/community/netweaver-administrator/blog/2011/02/23/how-to-push-abap-system-data-to-a-java-only-sld

For ABAP system, we can run TA SLDCHECK to test the SLD connection. If it is not successful, you should fix it at first, you can check the following troubleshooting notes for SLDCHECK:

#1143810 - Troubleshooting SLDCHECK - Releases 71X
#768452 - Troubleshooting SLDCHECK - Releases 640, 70X

For Java systems, we configure the SLD Data Supplier in NWA using HTTP destination. 

The SLD data bridge serves as a HTTP servlet which receives system data reported by Java data suppliers and forwards them to the SLD server.
Mainly it will collect the following Java system information: 

• System name and URL
• Database
• Instance: host name, instance number, nodes
• Deployed Objects: applications, services, libraries, interfaces
• Installed software components

 Data Supplier for Java-Based Systems should be configured by the HTTP destinations below in NWA:

OK, Let's go to the main point for SLD handling in XI.
For XI, the consistent SLD contents are important. If the SLD is inconsistent, there should many problems, for example, cache problem, message processing error and etc.

So what should the consistent SLD for XI system look like? I will show you separately for SAP XI/PI, PO(AEX), PI(Split Stack). As you know that, currently there
are three kinds of XI installation supported.

1. The classical ABAP+JAVA stack, according to the release, it is called XI or PI.
2. Java Only stack from 731, one is AEX, the other is AEX+BPM, which is called PO.
3. From PI 7.5, PI(Split Stack), which integrates another different Netweaver ABAP system if necessary.

If SLD contains inconsistent entries, this may be caused by manual changes or by temporary communication problems during the self-registration, but inconsistencies
can also occur during an update of Support Packages. This can have multiple effects at runtime, which do not immediately lead back to inconsistencies in the SLD.

For example:

• Error message in the XI directory: The relevant Adapter Engine cannot be found
• Error in the cache update: Association to the integration directory cannot be found
• Domain in component monitoring of Runtime Workbench does not contain an integration server
• Central Adapter Engine is not visible in component monitoring of Runtime Workbench
• Error message in the Runtime Workbench when configuring the end-to-end monitoring: Integration server does not exist or could not be found in the SLD.

Firstly, Check whether all XI components of the same XI domain are assigned and whether there are several XI domains for the server. Under some circumstances,
two domains with similar names are registered; one with a fully-qualified host name and one with a short host name. This represents an inconsistency.
Often, the integration server and another XI component (directory, repository, or adapter engine) are not assigned to the same domain either. And some entries are missing there. 

To check the SLD contents, we go to the SLD main page: http://host:port/sld-> Technical Systems-> select the “Technical System Type” as “Process Integration”.
For the consistent SLD, there should be 6 entries, they are, Domain, Adapter Engine, Integration Server, RWB, Integration Repository, and Integration Directory.
It should like the following screen:

For the three types of XI, the screen above is the same with the total 6 entries.
If you have installed the Non-central Adapter Engine, there should be more than one Adapter Engine with different system ID and host as follows:
 

For the three types of PI, the main difference for SLD is in the Integration Server part. If you click on the corresponding application system. Moreover, for every Integration Server,
there should be one Business System with the name of INTEGRATION_SERVER_<SID> with the pipeline URL defined.  

For the classical XI system, the Integration Server is meaning for the ABAP Stack , so the corresponding business system is INTEGRATION_SERVER_<XI_SID>. 
And the pipeline url is the http://<XI_host>:<XI_port>/sap/xi/engine?type=entry, which means the messages will be sent to this url after it has been processed from Adapter Engine.  
It is always associated with the Central (double stack) Dialog Instance.

For AEX/PO, it is pure java only stack, the all the message processing happens in java stack. The corresponding Integration server name is INTEGRATION_ENGINE_JAVA_<PO_SID>
and pipeline url is http://<PO_host>:<PO_port>/XISOAPAdapter/MessageServlet. Please note that, a 'Java Integration Server' is associated with the SCS Instance, because only this instance
is unique in a distributed AS Java installation.

For PI 7.5(split stack), it also uses the ABAP Integration Server as the classical one, but it is from the integrated another ABAP system. So the PI system ID and the integrated ABAP
System ID is different one. For example, PI is J75, while the ABAP system is A75, so the ABAP Integration server name is INTEGRATION_SERVER_A75, and the pipeline url is that
http://<A75_host>:<A75_port>/sap/xi/engine?type=entry. 

For the new installed PI system, all the XI components should be registered correctly. If any inconsistency occurred, the reason should be various, and case by case, so we need know the
mechanism how XI components are registered. XI components are self-registration, and it is different from components. XI Tools, Integration Engine and XI Adapter Engine register their
URLs in the SLD in different ways:

XI Tools: Hostname and port used by the Tools (RWB, Integration Builder -Repository and -Directory) are stored in the Exchange Profile. During J2EE system restart they get self registered
in the SLD using the values defined there. The corresponding Exchange Profile parameters(For the Java Only system, they are under the service "XPI Service: AII Config Service") as follows：

Integration Server (Section 'Connections')

• com.sap.aii.connect.integrationserver.sld.name
• com.sap.aii.connect.integrationserver.r3.r3name
• com.sap.aii.connect.integrationserver.r3.mshost
• com.sap.aii.connect.integrationserver.r3.group

 Directory (Section 'Connections')

• com.sap.aii.connect.directory.mshost
• com.sap.aii.connect.directory.mshttpport
• com.sap.aii.connect.directory.mshttpsport

Repository (Section 'Connections')

• com.sap.aii.connect.repository.mshost
• com.sap.aii.connect.repository.mshttpport
• com.sap.aii.connect.repository.mshttpsport

Runtime Workbench (Section 'Connections')

• com.sap.aii.connect.rwb.r3.mshost
• com.sap.aii.connect.rwb.r3.r3name
• com.sap.aii.connect.rwb.r3.group

Please note the values should be different if your XI system is High Availability system, and you should follow the notes below in details:

#951910 - NW2004s High Availability Usage Type PI
#1052984 - Process Integration >=7.1 - High Availability

If all the parameters above have been configured correctly, but you still cannot find them from SLD, then you should check if the corresponding service users(PIAFUSER, PIISUSER,
PIDIRUSER, PIREPUSER, PIRWBUSER) have the correct password in SLD with the proper roles. For example, for Integration Directory, the service user PIDIRUSER(PIDIR<SID>) 
should be able to log on to SLD, and the role SAP_SLD_CONFIGURATOR should be assigned. For central SLD, the password for the service users should be consistent with PI.

XI Adapter Engine: In case of the XI Adapter Engine, these URLs are automatically entered to the SLD as part of the Adapter Framework self registration process.
Host and port are taken from the J2EE server. In most cases the host name in these URLs is not fully qualified whereas in cross-domain scenarios fully qualified host names are required.
For the Adapter Engine, the approach is different: Change the properties

• "SLD.selfregistration.httpPort"
• "SLD.selfregistration.httpsPort"
• "SLD.selfregistration.hostName"

of the J2EE service "SAP XI AF CPA Cache" (6.40, 7.0) or "XPI Service: CPA Cache" (7.1 and higher). Enter the fully qualified host name under which the Adapter Engine can be reached from all relevant network domains. Do this in the Visual Administrator of the J2EE Engine (6.40, 7.0) or NetWeaver Administrator (7.1 and higher). Then restart the applications "com.sap.aii.af.cpa.app" and "com.sap aii.af.app", or restart the complete J2EE engine. This triggers a new Adapter Engine self-registration.
 

When you send messages from the central Integration Server to the central Adapter Engine In this case, the runtime tries to determine the URL of the central Adapter Engine from sxi_cache
(go to adapter engine cache). Go in the Integration Server (IS) to transaction "SXI_CACHE -> Goto -> Adapter-Engine-Cache" and delete the old Adapter Engine cache entries. After that the
cache is refreshed from SLD as soon as a new message in sent to the respective Adapter Engine. If the SLD is not available the Central Adapter Engine URL is taken from the Exchange Profile
data of the Integration Server:

• The Adapter Engine URL is formed from the following Exchange Profile parameters:
  <HOST>      := "com.sap.aii.connect.integrationserver.name"
  <HTTP port> := "com.sap.aii.connect.integrationserver.httpport"
  <HTTPS port>:= "com.sap.aii.connect.integrationserver.httpsport"

• HTTP URL :=  http://<HOST>:<HTTP port>/MessagingSystem/receive/AFW/XI
  HTTPS URL := https://<HOST>:<HTTPS port>/MessagingSystem/receive/AFW/XI

You can check if Adapter Engine url is correct in SLD as follows:

Navigate in SLD through "Content Maintenance -> XI Adapter Framework" (6.40, 7.0) or "CIM Instances -> XI Adapter Framework" (7.1 and higher) to your Adapter Engine.  As part of the "associated instances" you find e.g. at "XI  Adapter Service XIRA -> Associated Instances -> Port for XIRA of af.<SID>.<hostname>" the new URL with the fully qualified host name.

For Integration server, Additionally, before doing SLD resolving, the IS name is read from Exchange Profile (EP) parameter: com.sap.aii.connection.integrationserver.sld.name.
If this parameter is available and contains valid IS name, it is directly used without doing further resolving from SLD. This is consistent with the JAVA code reads IS name.
This property reduces the amount of overall communication between XI/PI and SLD, avoids multi-threaded use of the CIM client, and may improve overall system performance considerably.

The name of the Integration Server in SLD is formed according to the following rule:

com.sap.aii.connection.integrationserver.sld.name = is.<system number of central app server>.<host name of central app server>

Please note that for AEX java only system, the rule is changed, and should be maintained under the service "XPI Service: AII Config Service":

• com.sap.aii.connect.integrationserver.sld.name = is.<SCS_Instance_no>.<SCS_Instance_host_normalized>
• com.sap.aii.connect.integrationserver.name = <Dialog_Instance_Host_Fully_Qualified>
• com.sap.aii.connect.directory.mshost = <SCS_Instance_Host_Fully_Qualified>
• com.sap.aii.connect.directory.mshttpport = <SCS_HTTP_Port_prefix><SCS_Instance_no>
• com.sap.aii.connect.repository.mshost = <SCS_Instance_Host_Fully_Qualified>
• com.sap.aii.connect.repository.mshttpport = <SCS_HTTP_Port_prefix><SCS_Instance_no>

<SCS_Instance_host_normalized>: This is the host name read from 'MSHOST' (Message Server Host Name). The Java Message Server always runs on the SCS Instance.
<SCS_Instance_no>: This is the instance number read from 'MSPORT'. MSPORT is a system variable provided by the CTC Framework. The default is 39<SCS_Instance_no>.<SCS_Instance_Host_Fully_Qualified>:This is the fully qualified SCS host name. It is used in the *.mshost parameters.
<SCS_HTTP_Port_prefix><SCS_Instance_no>:This is the SCS Instance number. The default is '81<SCS_Instance_no>'.

Following useful notes for SLD configuration and inconsistency issue, for your reference：

#804124- HTTP communication with XI Adapter Engine fails

#1093249- Reducing SLD communication in XI/PI High Availability Setup

#1282862 - SLD dependency for getting the XI connection params in AF

#1651999 - Incorrect hostname for SLD components - XI/PI/PO

#954820 - Compatibility of SLD in system landscape

(#764176 - Manual correction of XI content in SLD

#1117249 - Incomplete Registration of PI components in SLD)

For the note #764176 and #1117249, you should carefully use them, since it will make the issue worse if you delete the correct Integration Server from SLD, 
so please always contact SAP PI consultant before implementing these notes.  

Please do not hesitate to post any questions regarding this wiki.