SLD (CIM) Namespaces

[Former Member]

Hi there,

I have read the SLD documentation which says that 'SLD supports the namespace concept that implements namespaces as logical areas for different purposes'.

To my fully understanding, does that means that I can for instance; define multiple SLD namespaces and use them to implement different virtual system landscapes.

For example, I could use one as test, acceptance and another for production environments...Am I getting the right picture?

If that is the case, then I would like to know how to move/switch from one namespace environment to another without loosing your previous changes, and finally is there a /restriction or maximum number of namespaces that you can declare on your SLD system?

Thanks for your feedback!

Rob.

[Former Member]

I did some testing of this late last week, and sure enough, you can create landscape entries in alternate namespaces. (I created one called "sld/sandbox", for example.)

However, entries in my alternate namespace were not accessible in the XI design-time environment. (There's probably a setting buried somewhere, but that should indicate that the intent is to put the entire landscape in a single namespace.)

One thing to be mindful of is how this will all tie in to CMS for managing the configuration across platforms. Right now, it looks like CMS will rely on dev/test/prod landscapes being in a single (or mirrored) SLD, and the migration path (dev, test, or prod) will be defined in the "Transport target" groups in the SLD. Since it looks like those entries can't be linked across namespaces -- at least in XI -- you run a risk of creating problems down the road. Of course, I haven't actually seen CMS yet; this is just extrapolation of the management components that SAP has already built in to the SLD.

--Dan King

Capgemini

[Former Member]

Any ideas?, on my previous question?

Thanks, Rob.

[Former Member]

Rob,

Your idea with using a namespace to represent virtual landscapes are correct. However, you would rather use it to model a new (planned) or changes to an existing landscape rather than changing your active landscape.

I believe you should use your active landscape to represent the whole of your real environment including DEV and test environments. You could use groupings to group these together rather than using another namespace.

I am not aware of any restrictions in the number of namespaces.

If you are loosing info when switching I suggest you consult the service marketplace for the appropriate fixes.

Regards

Christiaan