With the new version of the Planning Guide - SLD, we provide a new general recommendation how to set up the system landscape directory of SAP NetWeaver (SLD) in a landscape. This new recommendation does not invalidate previous approaches, so there is no reason to change your SLD landscape if you are fine with it - it rather provides a good starting point for an SLD landscape discussion if you have to think about how to run SLD in your landscape. This weblog outlines the basic new concepts - please check out the guide itself for more details!
General Recommendation
Our general recommendation should be the best choice for the majority of typical SLD landscape use cases and that is accepted by a wide base of customers.
In this example landscape shown in the first figure, there are non-production systems (both SAP NetWeaver Process Integration and other application systems) in a non-production environment to the left including one or several SAP NetWeaver Development Infrastructure (NWDI) systems. For these non-production systems, you use a central design-time SLD.
To the right, there is a second environment comprising production systems. For these production systems, you use a central runtime SLD.
In addition, front-end applications (such as SAP NetWeaver Developer Studio) and management systems (such as SAP Solution Manager) complete the landscape.
To ease the operation of your landscape, we recommend that you configure all SLD data suppliers to send their updates to the runtime SLD, from where the corresponding information about technical systems gets forwarded to the design-time SLD (for example, by using automatic bridge forwarding). Apart from having just one unified system SLD configuration, you can also profit from being able to create and administrate SLD data supplier users in the user management of only one SLD (as each SLD data supplier should have a dedicated user in SLD).
In addition to the forwarding of technical landscape data, you transport individual objects (such as business systems, products, and software component versions required by SAP NetWeaver PI) from the design-time SLD to the runtime SLD on demand. For this, you could for example use the export/import synchronization method.
From SLD client side, the runtime SLD is used for production purposes, whereas the design-time SLD is used for all other SLD client systems (such as all DEV and QA systems including all NWDI systems and all SAP NetWeaver Developer Studios) and for the definition of software, products, and software components in the Java development context. This way, you have separated and safeguarded the production systems. Access to the production systems can be restricted to technical administration users running the production systems. On the other side, development and QA systems, as well as the respective staff for development and QA, are only allowed to access the design-time SLD. In addition, NWDI only uses the design-time SLD.
Reasonable Alternative
Our general recommendation outlined above offers a generic approach, as you can further extend it according to your requirements. That is, you can set up additional local SLDs, such as to improve the availability of SLD data for certain use cases (such as for Web Dynpro Java applications using adaptive RFC calls, for SAP NetWeaver Process Integration, or for SAP Solution Manager).
The second figure shows the recommended SLD landscape extended by a local SLD for a Web Dynpro application. In addition, the Planning Guide - SLD also contains information about possible exceptions to our recommendations outlined above. These further SLD landscape approaches are normally only applicable for specific use cases. For example, if you strive for simplicity, you could run only one single central SLD in your landscape or you choose one of the distributed SLD landscapes if you face special requirements. The guide provides information about these additional options and their possible drawbacks, so that you are able to decide on the best SLD strategy for your requirements.
Where to Run the SLDs?
Please be aware that the SLDs in the figures above are only logical SLD systems. The question on which physical hosts to run these SLDs should be answered after having identified your logical SLD landscape, as the identification of the logical SLD landscape is the most important step in setting up an SLD landscape strategy. The last figure shows an example landscape based on an extension of our general landscape recommendation with three SLDs (a central runtime SLD on your production SAP NetWeaver PI system, a central design-time SLD on a non-production SAP NetWeaver PI system, and one additional local SLD on your SAP Solution Manager system).
Here is an assessment of this example:
- You would profit from an increased availability for your critical PI processes, as the production PI system uses a local SLD.
- In addition, you could profit from a possible high-availability setup of your production PI system that would also increase availability of the central production SLD for other use cases.
- You would profit from an increased availability for SAP Solution Manager, as SAP Solution Manger would use a local SLD – this could be crucial in case of issues with your production SLD/PI system.
- You would face a release dependency between SLD and PI. If you want to profit from new SLD features only available with a higher SAP NetWeaver release, you might have to upgrade your PI system.
- You would face a release dependency between the local SLD and SAP Solution Manager. If an upgrade to a required release is not yet available for SAP Solution Manager, you cannot profit from new features for your local SLD.
- Possible downtimes of your PI system would affect other applications that use this SLD as well.
- You would have a clear separation between your non-production and production environments. For example, your developers would only use the SLD running in the non-production environment.
- You would have a clear separation between your management system (SAP Solution Manager) and managed systems in your landscape. SAP Solution Manager would not rely on an SLD running in the production environment.
Summary
Altogether, the new version of the Planning Guide - SLD should provide you a good starting point for your SLD landscape discussion and will hopefully help you to easily plan and set up the SLD landscape you require. In addition, the new version of the guide provides information about how to transport SLD objects with the enhanced Change and Transport System (CTS) on request, which could be a valid alternative for the export/import functions of SLD – especially if you use the enhanced CTS anyhow already for other transports in your landscape to which also the SLD objects belong (such as transports occurring in the context of SAP NetWeaver PI development).
Check out the new version now!
28 Comments