A couple of years ago, we installed a 3-tiered XI landscape. We also obviously needed an SLD landscape to support the environment and since we didn't want developers modifying the production SLD directly and we wanted to ensure that delta SLD transports did not break production, we settled on using the SLD installed as part of the XI install to support a 3-tiered SLD environment. Since then, we've installed NWDI, deployed new Web Dynpro ESS functionality and have the now prerequisite Solution Manager installed. It is now time to review this initial decision in light of these new applications in our landscape. Here's what I've found to date. First - Our requirements: 1. Up time for SLD is critical for us across multiple Netweaver components. i.e. XI is our most critical system in our landscape; but we are getting increasingly critical Web Dynpro applications that also require the SLD to be available. 2. We need a QA environment the same as production in order to ensure that transported changes from development are tested before being applied to production. THis also allows us to test the patching/upgrading of the application in a production like environment. 3. All systems will publish to the development SLD in order to support setting up track connections for XI/PI. This requirement alone complicates SLD discussions no end hence my statement below. 4. We need to support a DR solution for the SLD since it is obviously critical. 5. The development XI system needs to point at a development SLD so that developers can maintain non-published system landscapes for track connection purposes (Dev->QA->Production). Now some guiding recommendations from SAP and others: 1. In an SAP SLD Recommendation paper, there was the idea of separating out an NWDI SLD from the Development SLD. That said, I'm not sure of the value of this and hence am going to discount this as useful from my experience but this could just be ignorance on my behalf. 2. From the master guide, it's highly recommended that PI/XI, Solution Manager and SLD are at the latest version; so we need to consider the layout since this will impact any upgrade. 3. There was an interesting statement in the XI Boot Camp brochure in Amsterdam that the SLD and Solution Manager had to be at the same patch level, but I'm hoping this is just referring to something like CIM levels being in sync (or similar) as it was not an official SAP statement (did anyone go to this and have the answer to why?). 4. Master Guide recommends if you have multiple components depending on the SLD to separate the critical component SLDs onto their application server and to export content from the master there. This is fine provided you keep the CIM fo each SLD in sync. 5. There is additional functionality coming in the future to manage automatic updates of SLD content. That said, I'm not considering this until release dates are announced and descriptions of how you maintain CIM levels across a multi release Netweaver landscape is published. So based on this, it seems that I need to make one more statement/assumption in order to make a decision: I believe current JAVA stacks (and I'm not a basis person so I'm allowed to be wrong) can only publish to and point at one SLD. So it would seem that if I want to do some PI/XI development against the Portal; I would need to point the Portal at the development SLD to set it up with all the required software component versions and allow it to be set-up with track connections for XI development. That said, this will obviously never work as this would mean that Web Dynpro applications on the portal would be impacted by a development SLD outage, hence my assumption right now is that the best option for the development SLD is to set-up the JAVA production systems in the development SLD manually and point production and production. New functionality may address this in time but I don't believe it is a possibility to export just the configuration of a production system in the production SLD into the development SLD (though that would potentially solve my dilema if it could be regularly and automatically published). Further note - I believe (a.k.a - I've been told) ABAP systems can have 2 types of connections , a publish SLD connection and an SLD link so in ABAP this is not an issue. So what you've finally been waiting for; my recommendation: Well 2 options which come to mind:Leverage the SLD on Solution Manager If you have a 2-tier (or greater) Solution Manager landscape then utilise the development and production SLD available as part of the JAVA stack install. AdvantagesSol Man should start to become one of your critical applications if your monitoring the landscape with it hence the SLD will automatically benefit from any hardening of this landscape. It is easier to keep both the SLD and Sol Man at the greatest release all the time (I reckon PI/XI can fall just behind Sol Man a little regardless of the recommendation). It's not tied in with JAVA applications that can cause crashing in general (those dodgy JAVA application guys out there can really cause a mess with memory when they're not careful) Performance is pretty well independent of what's happening so SLD performance should be fairly constant.DisadvantagesMakes Sol Man your most critical application; hence requires appropriate spending to make it a 24x7 system. Development Sol Man would typically be sized very small so SLD may actually be taken into account in sizing. Leverage PI/XIWell we're back with what we started but stability around PI/XI is not an issue anymore so for us there's only a couple of hurdles which I've highlighted in the disadvantages.AdvantagesThe good thing here is that you'll probably invest in HA concepts around PI/XI if you're like us and this will mean that the SLD will benefit from this automatically.DisadvantagesUpgrades to PI/XI are not as simple as Solution Manager (in terms of regression testing) but as the Master Guide states; it's a prerequisite to be at the latest version so we might as well bite the bullet on this. Varied PI/XI traffic can impact SLD performance. Also prone to rogue JAVA programmers developing adapters/user modules and sending 100 Meg files or greater that the blueprint said wouldn't happen. Anyway, I'm sure there's lots more pros and cons and multitude of flavours to this (especially if your company has unlimited budget) but this is just where I've got to in our organisation. Have fun, Matt
