SLD Landscape Design Question

[Former Member]

After reading the Planning Guide - System Landscape Directory, I am left with a question.

The Setup:

• Standard three system landscape
  • ECC 6.0 Ehp5 on NW 7.02
    • ECC Instances: DE1, QE1, PE1
  • PI 7.31
    • PI Instances: DP1, QP1, PP1
    • PI Business Systems: DE1CLNT100, QE1CLNT100, PE1CLNT100
    • Each PI Instance has a local SLD
• Management Landscape
  • Solution Manager 7.1 on NW 7.02
    • SolMan Instance: SP1
    • Local SLD
    • LMDB

Reading through the Planning Guide, the recommendation (pg. 45, picture below) seems to be to have all systems self-report to PP1. That is, without synchronization, only PP1 knows about any systems because they all report to PP1 and do not report in to their local SLDs. The data is then sent back to DP1 & QP1 via bridge forwarding. Business Systems are manually entered into their respective local SLDs, but then have to be manually exported/imported from DP1 --> QP1 --> PP1. Once it's all gathered into PP1 again, all data is pushed to SolMan's SLD on SP1 via a unidirectional content synchronization.

If I read this correctly, then all SLD's will end up "knowing" all systems and business systems: e.g. the sld of DP1 will have entries for QP1 and PP1 and for business systems QE1CLNT100 and PECLNT100.

Earlier in the guide, I gathered that there was value in not having all of the data in Development in that there is then clear separation between non-production SLDs and production SLDs. The above recommended setup seems to go against this idea of separation. Plus, it requires a significant amount of manual upkeep.

As an alternative (pictured below), what if each environment only reported to it's local SLD (DE1 --> DP1, QE1--> QP1, PE1--PP1). (Note that in the picture the SLD is drawn separate, but I've heard that most customers run their local SLD on PI, so the SLD depicted in each environment actually runs on the PI system in this scenario.) Further, what if the SLD's then synchronized sequentially in a full unidirectional content sync fashion. (DP1 does a full uni-directional Content Sync to QP1, QP1 does a full uni-directional Content Sync to PP1, and PP1 does a full uni-directional Content Sync to SP1.)

DP1 would only know about it's own systems. QP1 would know about it's own plus DP1 (which it needs). PP1 and SP1 would both have full visibility into all systems.  Furthermore, the manually entered business systems would also be automatically synchronized and the whold manual export/import process could be avoided or  a manual export/import could be implemented between Q and Production for safety with an automatic bridge forward of Data Supplier data.

Are there downsides to the second scenario that I am not seeing? Please comment!

Best regards,

  --Tom

[Former Member]

Although the guide states that Dev systems only needs to know about other systems in the DEV environment and QAS systems only needs to know about systems in the DEV and QAS environments and only PRD needs to know all systems, I am finding that I can't get the groups set up correctly when the DEV environment has no visibility to the QAS environment.

It seems that the recommended structure (where all systems are known in all environments) will facilitate the correct setup of the PI transports. So far, that is the biggest arguement I've been able to find against the second approach outlined above. Using full sync all the way through is also not an option if you're doing any development as any changes in the DEV system automatically flow through to PRD almost instantly. Using automatic bridge forwarding and import/export might be a usable alternative, but the recommended approach from page 41 of the planning guide does seem to have the best of all worlds.