Skip to Content

Introduction

The SAP NetWeaver System Landscape Directory (SLD) is the main source of technical systems’ information in your landscape gathering data of installed systems via their data suppliers. To be able to handle this data the SLD CIM Model and CR Content need to be up-to-date (see SAP Note 669669). In most cases, this manual action is done on each SLD individually, many of which may exist in a landscape. Using the (Full Automatic) Content Synchronization mechanism and the SLD Namespace concept wisely, you can update one SLD manually and automate the CIM Model/CR Content update for all other SLD systems.

Using Full Automatic Sync to Distribute CIM and CR Content from a Dedicated Namespace

Note that this procedure should be tested by you in a sandbox and used very carefully – not fulfilling the prerequisites or performing the steps wrong, will cause data inconsistencies.

Full Automatic Synchronization (FAS) of SLD content keeps all data of connected SLD systems in sync; this includes CIM Model and CR Content data. However, FAS does not allow for filtering of data, nor does it give any control about the point in time when content is synchronized: All changes become active on the target of an FAS connection more or less at once. Therefore, you must not simply connect the DEV SLD to QA SLD to PRD SLD because all manually created data need to be synchronized in a controlled manner between SLDs with different roles – see How-to Handle Data in the SAP NetWeaver System Landscape Directory. On the other hand, there is data, which should be available on each SLD:

  • Technical Systems’ data should be available in the whole landscape – but this is easily handled by Bridge Forwarding of Data Supplier data.
  • Also, any SLD version can cope with any CIM Model and CR Content version.

The fastest mechanism that can be used to transport CIM/CR Content is the full automatic synchronization. However, FAS always transports all changes – to use FAS for the update of CIM/CR Content only, a specific configuration is needed:

To separate CIM/CR Content from all the other content (manually created content and technical systems’ data) you can utilize the SLD namespace concept – see figure 1:

CIM-CR_automated_update.png

Figure 1: SLD systems, namespaces and connections in a typical landscape to optimize SLD content maintenance by automation of CIM Model and CR Content update.

Note that there MUST not be FAS connections transporting back CIM/CR Content to SLD (PRD).

Prerequisites

  • All SLD systems, in which CIM Model and CR Content are to be updated automatically, need to be running on SAP NetWeaver 7.1 or higher to be able to retrieve data from another SLD by Full Automatic Synchronization.
  • This process needs not be installed at the beginning – it can be installed at any time, if the prerequisites explained below are adhered to when a new synchronization connection for CIM model and CR Content is added.
  • The unique-path-principle must be fulfilled (the same content must not reach any SLD on two different paths – for valid topologies see How-to Handle Data in the SAP NetWeaver System Landscape Directory or the Planning Guide – System Landscape Directory mentioned there.)
  • Most importantly, when adding such a new FAS connection for a target namespace that already contains CR Content, ensure the following:  Both the CIM model and the CR content version of the target namespace sld/active and the source namespace sld/cim_cr MUST be the same. Otherwise the CR Content in the target namespace will become inconsistent.

Steps

Automatically updating CIM Model and CR Content should not affect your SLD performance noticeably. In case that your SLD is working without some performance buffer near its maximum capacity, you should either strengthen the SLD system or plan the CIM Model/CR Content update for times when the load is small by planning the manual CIM/CR Content update in the central SLD accordingly. (if this cannot be achieved with FAS, keeping the manual process for such an SLD might be recommendable.)

Note: Once you are using this automated setup for CIM/CR-updates you MUST NOT perform manual CIM/CR-updates in the target SLDs anymore. This would lead to inconsistent data.

  1. Create a namespace for CIM Model and CR-Content on one SLD (probably your central SLD), where you keep CIM Model and CR Content up-to-date, naming it sld/cim_cr for example
  2. Create a FAS connection on every SLD which can be updated with latest CIM Model and CR Content (see “Prerequisites”) to namespace sld/cim_cr on the central SLD

    Note that on these target systems, no additional namespace is required: sld/active can be directly the target namespace for the update to take effect on technical systems data. When adding such a new FAS connection for a target namespace that already contains CR Content, both the CIM model and the CR Content version of the target namespace sld/active and the source namespace sld/cim_cr MUST be the same.

  3. For the source SLD containing namespace sld/cim_cr, there are two options to update CIM/CR-Content:

    a. You can automate the required update of namespace sld/active by creating a local uni-directional FAS to its own sld/cim_cr namespace.

    b. If you want to be in control of the CIM/CR-state of this SLD (which probably is your productive one) you can import it manually.

    Note: You can control the point of time to update CIM/CR-Content: Optionally, you can de-activate the FAS connection updating the CIM/CR-Content and activate it manually, if you want to perform an update.
    Make sure in this case that for each single update to the central CIM/CR namespace the connection is activated.

Result

CIM Model and CR Content will be updated automatically in any SLD reading the CIM-CR namespace.

Summary

Setting up your SLD landscape as shown will reduce the manual effort of keeping the CIM Model and CR Content in your SLD systems up-to-date. In the best case it can be reduced to one system where this data has to be maintained manually.

Additional Information

More information on the SLD is available at the SDN:

To report this post you need to login first.

11 Comments

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

  1. Bernie Krause

    Wolf – nice writeup.  One question that our Basis team has though is whether or not we would run into issues if our Solution Manager SLD had a different (newer ) CIM/CR versio than our PI SLD.  We’re unfortunately not yet running a central SLD, so we have this to contend with – they are running their updates to teh PI SLD on a different schedule than our SM SLD.

    Thanks!

    Bernie

    (0) 
    1. Wolf Hengevoss Post author

      Dear Bernie – thanks a lot. And: Having SAP Solution Manager’s on a higher CIM/CR level should not cause problems: Received Data Supplier data directly or by forwarding from the SLD dedicated to PI will be integrated correctly.

      Best Regards,

      Wolf

      (0) 
      1. Bernie Krause

        Is there a document/note anywhere that describes CIM/CR relationships between separate SLDs and how different versions/levels can co-exist?  our Basis guys are being strangely paranoid about this.  Experience, perhaps..  🙂

        (0) 
        1. Wolf Hengevoss Post author

          Dear Bernie,

          thanks for the question – it is answered in SAP Note 954820 – Compatibility of SLD in
          the system landscape
          .

          Also, keep in mind that with SLD systems interchanging information the role of the CIM/CR versions are different: While in case of forwarding of data these versions do not play a role (because data supplier data are forwarded as if sent to the target system directly) in other cases CIM and CR versions need to match. For details see
          SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?

          How to Reduce Manual Effort in CIM model and CR Content Update of SLD Systems

          and other blogs on http://scn.sap.com/docs/DOC-8516.

          Hope that helps!

          Best Regards,

          Wolf Hengevoss

          (0) 
          1. Bernie Krause

            I’m beginning to see where some of the confusion comes from.  Note 954820 says “Note that the same CIM model version is prerequisite in all SLDs.”  yet the SLD planning guide says

            “Since the SLD bridge forwards data without interpreting or changing it, automatic forwarding works independently of releases, patch levels, and installed CIM data models and SAP Component Repository

            content versions of the involved SLD instances.” 

            It is not at all clear when to apply which set of guidelines..

            (0) 
            1. Wolf Hengevoss Post author

              Dear Mr. Krause,

              thanks for pointing this out. Here is your answer: The note is focussing on compatibility and gives a clear recommendation to have the latest CIM Model/CR Content thoughout the landscape and doing that, you’re on the safe side. To make this easier to achieve, I also wrote a blog how to automate the CIM/CR Content update in the landscape: “How to Reduce Manual Effort in CIM model and CR Content Update of SLD Systems

              However, there are cases were it is not required to have the same CIM Model/ CR Content in all SLDs, so the Planning Guide – SLD pointing this out for the forwarding of SLD data is correct and more complete here.We will update the note to reflect this. Use case, where CIM/CR Content need to be identical are described here: http://scn.sap.com/docs/DOC-8516.

              I hope that helps.

              Best Regards.

              Wolf Hengevoss

              (0) 
  2. Brian McQuillan

    Hi Wolf,

    I’ve read through many of your articles and they are very informative. Thankyou.

    One thing I’m not clear on however is the best approach to adopt when performing support package/upgrade type actions on a given landscape that uses the Full Automatic Sync feature.

    My current client had a PI 7.3 Dev, QA & Production landscape in place before I got involved with their project. The SLD configuration uses the FAS feature to sync the SLD from Dev to QA & Prod. The sync to prod is deactivated and only activated when the PI development team need the SLD data in production.

    Dev & QA sync is active all the time.

    We are looking to update to the latest PI 7.3 Support Package Stack soon. I can’t find any documents on the SLD documentation areas that would suggest what the approach would need to be.

    Would it mean syncing up fully production then deactivating the syncs from Dev to QA & Prod just before the Dev PI 7.3 system has the Support Package update process performed (SLD updated and latest CIM CR Content uploaded). Then when QA has the same SPS applied enable the sync again – but would this be correct as the SLD docs say the CIM model & CR Contents need to be the same to initiate.

    Sorry if my question seems daft but I’m a bit concerned that the QA & Production SLD’s could become inconsistent.

    This is the first PI 7.3 support package stack update on this landscape since the initial installation and configuration of the sync’s from the Dev PI 7.3 SLD to QA & Prod.

    Regards,

    Brian.

    (0) 
  3. Sorin Stancu

    Hello Wolf,

    Thank you for providing this document – it is an elegant way of updating cim & CR content across landscape.

    I do have one question for which I would need more clarifications:

    – Do I have to create the namespace sld/cim_cr in PRD and start propagating the cim and CR content upgrade from here (=PRD) downwards to QAS and DEV ?

    – Or, can I create the sld/cim_cr in DEV and propagate the cim CR content upgrade using unidirectional FAS to QAS and the to PRD (DEV->QAS + DEV->PRD) ?

    The reason for this question is that I would like to test the cim/CR content upgrade in DEV first, then activate the FAS to QAS, then activate FAS to PRD: I am not sure I want to upgrade the cim/CR content in PRD first. Also, at the same time I do have the forwarding of technical data going from PRD-> QAS and PRD-> DEV.

    Thank you,

    Sorin

    (0) 
    1. Wolf Hengevoss Post author

      Dear Sorin,

      It is not a problem having the initial dedicated namespace on DEV instead of on the PRD system, provided that no other prerequisites for exchange of landscape data is violated (see SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?). Please note, that controlling the sync by activating/de-activating can make the benefit smaller the procedure offers, since you can easily forget to activate prior to the update.

      Best Regards,

      Wolf Hengevoss

      SAP SE

      (0) 
  4. Gadde Subhash

     

    Hi ,

     

    Can we have 2LMBD  where one LMDB connected to one SLD like non-prod SLD and another LMDB connected to PROD SLD, both prod and Non-Prod SLD are in full sync , please comment.

    (0) 
    1. Wolf Hengevoss Post author

      Dear Gadde Subhash,

      thanks for your question. If I’m not mistaken, in this scenario, non-POD and PROD SLD systems will have identical content being in full-sync, so it would make no difference… to check my assumption, I recommend reading  to learn about the options available I recommend my blog post SLD-LMDB Topology – Connections, Valid, and Invalid Data Exchange Between SLD and LMDB of SAP Solution Manager

      Also. for the use of full, automatic sync between PROD and non-PROD SLD read my blog post SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape? -> Description of figure 1 Full Automatic Synchronization

      To give the full picture, with the Maintenance Planner having replaced the MOpz, a 3rd blog post is important: Topology of SLD, LMDB, and Customer Profile – How to Get Reliable Landscape Data in SAP Support Portal as a Basis for Planning

      I hope that helps.

      Best Regards,

      Wolf Hengevoss

      SAP SE

      (0) 

Leave a Reply