Skip to Content

SLD: General recommendation how to set up the system landscape directory

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

General SLD 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.

Extension of the General RecommendationReasonable 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).

Example Where to Run SLDs?

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.


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!

You must be Logged on to comment or reply to a post.
  • Boris,

    Thanks for the wonderful blog. You have mentioned …
    >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).

    What i understood was that the non production systems would be in design time SLD & production systems in runtime SLD.
    So in the above case what possible information could be updated by the Data Supplier bridge?
    Since in production SLD there wont be any Dev/QA Systems.


    • Hello Sumit,

      Thanks for your feedback! According to our general recommendation, you would recommend to set up ALL SLD data suppliers to send their data only to the runtime SLD – from there, the technical information about all systems would be forwarded to the design-time SLD. As a result, both SLDs would contain technical landscape data of both environments. The advantages of this recommendation would be that you could use one common system configuration for all systems in your landscape and use the user management of only one SLD to administrate the dedicated users for the SLD data suppliers. If you think of SAP NetWeaver PI, also the runtime SLD has to have the data of the technical systems from the design-time environment (to be able to map transport targets from DEV to PROD).

      Concerning the SLD clients, there would be a clear separation between runtime and design-time.

      So, the recommended general approach focuses on providing the normally required SLD data with minimum effort for setup + operation. If you face different requirements (that is, want to have different views in your design-time and your runtime SLD), you should consider a different SLD data supplier configuration that should also fit into the overall SLD landscape recommended here (depending on your use case, you might only face extended effort concerning synchronization, setup, and operation).

      Best regards,

  • Boris,
    thanks for your effort,
    but i want to get your opinion in this design
    i have solution manager and i used it as centeral SLD for solution manager and the PI dev, qas
    now i want to make another SLD for PI prod, coz the PI prod will be high available nad also i don’t need more load in my Solution manager.
    so how can i make the all data suplier send thier informations to PI prod SLD , and they already registerd in soluton manager sld
  • Fantastic article!!!   Ok – one question.  Our Central Monitoring system (CEN) runs on Solution Manager.  So it would make sense to have a local SLD on SolMan as the “administrative SLD” for NWA (Netweaver Administrator)… do you agree with that?
    • My apologies – the answer is clearly explained in the Planning Guide.  Sorry Boris, I should have read that first.  Guess I was a little too excited by this article … answers all our questions (along with planning guide!)  :p
      • Hello Jason,

        Thanks for your positive feedback! If further questions should arise, do not hesitate to contact me again! 🙂

        Best regards,

  • Does it make sense to have a primary/secondary SLD configuration for the production side and a primary/secondary SLD for the pre-production side + an SLD for Solution Manager = 5 total SLD’s?

    Or would it be better to put the SLD as a stand alone instance, on the same server as something like a current EP instance, and cluster that as well for high availability purposes (both EP and the SLD would be clustered).  Instead of 5 SLD’s, it would be a pre-production clustered SLD and a production clustered SLD = 2 total SLD’s. 

    Does SAP support stand alone clustered SLD’s that are dual clustered with EP?

    Is the primary/secondary approach still a “best practice?”  Was it ever a best practice?

    • Hello Ronald,

      I would recommend to go for your second approach – that is, run your runtime + your design-time SLDs together with an application that uses the SLD, such as EP or PI. This way, SLD would profit as already described in your comment from an HA setup of your application system. SAP supports to run SLD together with an application, that would not be an issue.

      An alternative could be to run SLD completely standalone to achieve maximum flexibility, but at the expense of having to run additional systems and most propably even in HA mode.

      Besides those two SLDs running on your EP systems, you should still consider a third SLD if you want to use end-to-end root cause analysis with Solution Manager Diagnostics as described in the planning guide of SLD.

      Having something like a standby SLD (that is what I would interpret from your primary/secondary SLD approach) would have several drawbacks, like effort for synchronizing them and the challenge of switching them in case of issues, which normally can’t be accomplished in a short amount of time. Therefore, I would recommend to use the HA approach you have outlined with your EP system.

      I hope this helps.

      Best regards,

  • Great Blog, good content…one follow up question
    Sounds like SAP recommends min 2 SLDs (1 production & 1 non production). Is it also a recommendation if I have Solution Manager E2E solution I should have a local SLD? (this would bring the total SLDs to 3). Thanks
    • Hello Kai,

      Thanks a lot for your positive feedback!

      You are right, our general recommendation that should fit most requirements would be to have two central SLDs (adavantages: clear separation between design-time + runtime, possibility to test changes [such as the import of CIM model updates] first in a second SLD before performing it in the runtime SLD). If E2E root cause analysis is used, we recommend to have an additional local SLD for SAP Solution Manager. So, this would for this use case sum up the number of SLDs to three – but in most cases, the operation effort to run those three SLDs should be rather small (use of bridge forwarding, selective synchronization only of PI objects from design-time to runtime SLD – with CTS+, as part of normal transport management of PI development, CIM model update to be performed in three SLDs [not more often than once a month], …). Depending on your use case, you would still have the option to take a different approach as outlined in the planning guide (for example, use only one SLD in your landscape), but our general recommendation would be to have two central SLDs and one local SLD for SAP Solution Manager if you use E2E root cause analysis.

      I hope this clarifies things a little bit.

      Best regards,

  • Hello Thomas,

    Thanks for your feedback! Concerning the SLD inside the SAP Solution Manager: you can use this local SLD for the SAP Solution Manager use case – nevertheless, you should not use it as central SLD in the landscape, as then, you would no longer have a clear separation between management and managed systems in your landscape (as runtime systems like SAP NetWeaver PI would rely on the availability of your SAP Solution Manager system – for more information about the recommendation for SLD + SAP Solution Manager, please see the detailed description in the planning guide for SLD). So, you still have the option to use a local SLD dedicated for SAP Solution Manager in addition to a central SLD. If you are using end-to-end root cause analysis, it is even recommended to have a local dedicated SLD. So, only deactivate your SLD if you do not intend to use end-to-end root cause analysis offered by SAP Solution Manager Diagnostics. If this is the case, we would recommend to proceed as described by you (use SLD inside your runtime PI system as central SLD).

    I hope this helps.

    Best regards,

  • I think things are getting more complex here. Everything is integrated into Java and lots of dependencies … It is nowhere clear about the installation of SLD which mentioned the details of the packages getting installed with SLD. So many imports while installation of SLD…..
    • Hello Prashant,

      Thanks for your feedback. This blog does not cover the real installation aspects, so I don’t think that installation is getting more complex by this recommendation – so, I guess you are talking about general SLD/AS Java aspects not explicitly covered here. If you are interested in this topic, any feedback/input would be highly appreciated. Please send it to my colleague Wolf Hengevoss ( Thanks in advance for your support!

      Best regards,

  • Hello and thank you for your blog. For the reasons you state, and which are clearly explained in the Planning Guide, we have decided to follow the “General Recommendation” and have stand-alone SLD’s, one design time and one Productive. We will have separate local SLDs for Solman and PI.

    The problem is that to use the fully automatic synchronization (planning guide pg 18), the SLD must be on NW 7.1. However, it seems that a stand-alone Java Stack with only SLD is not released on NW 7.1. SAP is only delivery NW 7.1 with PI or CE for the moment.

    Do you know when the version will be available for stand-alone SLD (Java-only stack)? If it is soon, we will probably prefer to wait to avoid implementing manual processes for synchronizing PI business systems etc. Also I believe the upgrade from NW 7.0 to 7.1 java stack involves changing the version of the Java JVM, so it would be basically reinstalling thsi environment.

    • Hello Kim,

      Thanks for your message! First of all, the general recommendation is not intended to give a recommendation to run a standalone SLD, it rather proposes to have a central runtime SLD, a design-time SLD and an additional SLD for your SAP Solution Manager system, whereas the question where the runtime SLd should run is discussed later. For example, it would be a valid option for the runtime SLD to run on the PI system. Please see section “3.4.2 Where to Run an SLD in Your System Landscape” in the Planning Guide for aspects that play a role for the decision if to run the runtime SLD standalone or together with an application (such as the PI system). For example,  the SLD would profit from a possible high-availability setup of the PI system, if it is run on the production PI system as well.

      Concerning the delivery of a standalone AS Java 7.1 system, you are right – there is currently no option to install a standalone AS Java 7.1 system in that sense. Nevertheless, also SAP NetWeaver CE 7.1 comprises a complete SLD 7.1 – so, if you have decided to really run a standalone SLD system (see section avobe :-), the installation of an SAP NetWeaver CE 7.1 system would be the only valid option for now. With this CE 7.1 system, you would on the one side profit from a lightweight Java system comprising SLD, on the other side you would run/operate a CE system in your landscape. This should normally not be a challenge at all (as CE is focussed on providing lean life-cycle management processes), I just want to make you aware that you will have a system in your landscape that will behave (at least for some time) slightly different from other SAP systems (for example, you will patch the CE system with the Update Manager, not with SAP Solution Manager). Not an issue at all, you should just be aware of it :-). Also, you have the option of installing additional usage types to an existing system, such as EP or BI Java, to a standalone AS Java system. With a CE 7.1 system, you would not have this option. Concerning the update of our release strategy, I contacted colleagues and will forward you their answer. Apart from that, you should be able to find the lastest information about SAP’s release strategy in SAP Service Marketplace at

      One additional aspect you should consider: besides the other advantages of SLD 7.1 (mainly improved performance, caching in a clustered environment, …) you mention the full automatic synchronization. Here, my question would be if you really want to use this feature especially in the context of SAP NetWeaver PI 7.1 – there, I would guess that the enhanced Change and Transport System would be the better option to propagate changes, as customers normally want to be in control when development artifacts get transported from DEV to PROD. Don’t get me wrong, full automatic synchronization is a neat new feature of SLD, I just want to raise the question if propagation of PI development artifacts is the right use case for this feature (you see, I am also missing experience here). So, if my answer now raises more questions than providing answers, please do not hesitate to drop me an email at :-).

      Best regards,

        • Hello Buddhike,

          As this question would not be that easy to answer (depending on your exact landscape and requirements), I recommend that you open a support message under the component BC-CCM-SLD to get guidance here.

          Best regards,

  • Hi Boris,
    Thanks for the blog and guide. This is an area that sorely needs clarification.
    I have always used what I think is the simplest landscape:
    ALL systems report their technical information to the central SLD on the XI Production system (XIP).
    ALL systems that consume SLD data are configured to read from the local one (e.g SolMan Dev and Prod).
    The central SLD on XIP forwards the information back to all systems that have a local SLD.
    I transport (export/import) products, components, business systems etc.

    It means updating the CIM content on a couple more systems but the simplicity of making changes in one Dev system’s SLD and not impacting the other Dev systems, or even the QA/Training/Test systems far outweighs the little extra time of importing content.

    The problem now arises with PI 7.1. When I run the template installer on XI development (XID) it doesn’t give me the option to send technical data to XIP but use the local SLD to create business systems, products etc. It’s all or nothing; you are using a Central SLD for everything or a local for everything. Previously I could use the Visual Administrator and point the http settings to XIP but leave the CIM Client pointing at XID. It seems more complicated now. How can I do this?
    Well thanks again Boris and take care,

    • Hi David,

      Sorry for my late answer, but I was on vacation the last two weeks :-). Thanks for your feedback – your approach is also absolutely valid and I understand the advantages you gain with it. As we wanted to keep operation efforts low, we decided to take this different approach for our general recommendation, as less effort for manual export/import is required.

      Concerning your question: the handling really changed from SAP NetWeaver 7.0 to SAP NetWeaver 7.1. Now, you use the SAP NetWeaver Administrator to configure most of the stuff formerly configured in the Visual Administrator. For example, you can go to Configuration Management �¨ Security Management �¨ Destinations to configure SLD clients. I recommend that you take a look at the SAP Library for SAP NetWeaver 7.1 to get more information about the latest changes about the configuration of SAP NetWeaver PI 7.1. If you are facing problems to find the right documentation, please drop me a line ( and I will ask colleagues to send you the corresponding link.

      Thanks for your feedback and best regards,

  • Boris-

    I first want to thank you for your insight. I learned more in 20 minutes reading this than in hours of conversation with others.

    I do however still have a couple of questions and would appreciate greatly your insight. First, I was under the impression that NWDI should have it’s own SLD for the purpose of seperating systems from namespace. Does this still makes sense?

    Also, we are about to begin a project to introduce ACC (Adaptive Computing Controller) in our landscape and as I understand it the ACC requires its own SLD also (7.1 rev).

    Given my two inquiries, how would you manage this?

    • Hello Todd,

      Thanks a lot for your positive feedback – really appreciated :-)!

      It is an option to separate nameserver and landscape directory to have a clear separation of those two SLD ‘roles’, but this is not a must. In our recommendation, we tried to find the right mix of flexibility and low number of systems, so we decided to propose only one design-time SLD. Nevertheless, if you want to have a clear separation here, this still would be a valid setup (pros: clear separation, cons: an additional SLD in your landscape), no question about it. But as you have already safeguarded your runtime SLD, I would tend to use the design-time SLD also as name server.

      Concerning ACC 7.1, you are right that it requires an SLD with version 7.1. Nevertheless, this SLD 7.1 does not have to run locally on the ACC system itself – ACC could also use a remote SLD (such as an SLD 7.1 running on an SAP NetWeaver PI 7.1 system). If you do not have a runtime SLD 7.1 already in place, we recommend to use a local SLD for ACC 7.1, that is correct.

      I hope this helps.

      Best regards,

  • Hi all,

    I just want to point out that there is a new version of the SLD Planning Guide available. There, we slightly adapted the general recommendation in that sense that there must be a local SLD for SAP Solution Manager in any case. Please see the latest version of the guide at


  • Boris,

    I found the article and all of the responses very positive, but I wanted to ask you opinion on a design that does not include PI in the landscape.  Should I use Solman as the central? Should I do as someone else discussed and use EP?  I appreciate your thoughts.

    Thank you,


    • Hello Dennis,

      Thanks for your reply – I recommend that you take a look at the recommendation in the SLD planning guide, section “ SLD Landscape: General Recommendation”: if you are not using SAP NetWeaver Process Integration and/or Web Dynpro Java applications today and also do not plan to do so in the near future, run your central SLD in your SAP Solution Manager system. If you are using Web Dynpro Java applications (but no PI), you can run your central SLD in your portal system. This is the general recommendation, but the guide provides more insights and information about possible exceptions to this recommendation. I hope this helped to answer your question.

      Best regards,

  • Hi Boris,

    I could see lots of docs saying about SLD and its usefulness. But could not find any doc saying what if you have not selected the option while installing ” No SLD destination required”?

    Do we have any good doc. saying how to go about it even if you have not selected SLD?

    Appreciate if any such docs. present and shared across.


    • Hi Prash,

      If it’s about configuring/changing the config of an SLD, I recommend to take a look at the post-installation guide. If it is about how to connect existing systems to an existing SLD, please check the SAP Library (for example, – in practice, it depends on the actual task you want to perform and the release of the corresponding system, as the documentation evolved over the last years according to my knowledge, but you should be able to find more information in one of the mentioned sources.

      Best regards,