Skip to Content

Do you still remember the day when you had to create your first domain in the SAP NetWeaver Development Infrastructure (NWDI)? And do you still remember that first and fatal popup informing you that you are about to create a customer domain (with a 3-character domain ID) or a partner domain (with a 4-character domain ID that you had to register with SAP)?

Who of you wondered what to do next and turned either to a consultant or to SAP’s support organization for help and information?

Who of you dared to simply confirm the message and boldly pressed “Save”?

 

With NetWeaver 2004s this will be in the past because SAP has eased the installation process of NWDI considerably. Using the template installer, all the post installation steps will be done for you automatically. NWDI will be preconfigured right down to the first track so that you can start developing right away.

In this context the template installer uses the system ID (SID) of your Web AS Java to set up the domain in NWDI, creating a 3-character domain ID by default.

However, even though this eases the installation and configuration of NWDI considerably, one might ask about the validity of the naming convention for NWDI domains given in the SAP Library (see Naming Conventions).

This naming convention was originally established to ensure the uniqueness of software component archives (SCAs) that are produced by the NWDI assembly process.

Note:
The assembly function of NWDI provides a packaging function that allows customers and partners to ship software development in the standard SAP format. The SCA always contains a complete version of one software component. Typically it only contains the deployables, but it can also hold the source code and build archives.

By restricting the shipment of sources to customers to registered 4-character domains only, the uniqueness of SCAs was ensured worldwide, provided that the domain ID was registered with SAP!

The technical reason for this is as follows: The domain ID, together with the track ID, comprises the keylocation property of an SCA which – together with keyname, keyvendor and keycounter – make the version of a software component globally unique.

In NW 2004s and the template installer process, the configuration of 3-digit domain IDs becomes the default setting. This introduces the possibility that a delivered SCA of a partner conflicts with an SCA of the same name if – and only if – the domain ID and track ID are the same in both NWDI environments.

The possibility of such a conflict, however, is very theoretical. The partner company needs to ship its SCAs with source code content and the customer of this partner must modify this source code within their own NWDI using the same domain ID and track ID as the partner. Such a scenario can easily be avoided if the partner company tells its customers not to use the same domain ID.

Since the possibility of SCA conflicts between partners and their customers is very small and the post installation with the template installer is very easy, we recommend that you use the template installer to setup NWDI and that you tell customers which domain IDs not to use.

Note:
The conflicts described here have nothing to do with conflicts on the development object level. These conflicts can also occur if you only deliver deployables and must in any case be avoided by useing a nameserver and a registered namespace.

To report this post you need to login first.

2 Comments

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

  1. Jan Van Achte
    Hi Guenter,

    I respectfully disagree with you that the the template installer is a good basis to start with. In my experience it gives you a false sense of assurance that everything is set up correctly.

    Our sandbox system was setup manually, as we are running usage types EP and NWDI in one instance, and SAPINST does not provide for multiple usage types (as far as I know). Although setting up NWDI manually was a lot of work, it helped me to understand the necessary configuration.

    In our production NWDI system, I did use the template configurator, and I now very much regret doing so. Notably:
    – I could not choose the domain name to make it fit our naming conventions
    – A “demo” track was set up, which I deleted from CMS, but is still in DTR (which the auditor will ask questions about).
    – Object server was not correctly set up
    – Name server was not correctly set up
    – Default roles did not conform with our naming conventions, so I had to reverse-engineer some of them.
    – Some (technical) users were created with the default security profile, so their passwords would need to be reset after 90 days. Because of the “wizard” effect of the template installer, you are unlikely to know or have documented were to change these passwords.

    Basically, in any environment where change management is important (because of company policy and/or regulatory requirements), the template configurator is not such a good idea, as it will be very difficult to document the changes that have been executed, which makes maintenance more difficult.

    Regards,

    Jan Van Achte

    (0) 
    1. Guenter Schiele Post author
      Hi Jan,

      thank you for your candid opinion. Your comment is the best statement that the easy way is not always the best way to do things. It is also good to see that there are experienced users of NWDI.

      Unfortunately, the target group of the template configuration of NWDI are people with no experience, who don’t want to deal with the configuration giant in the back but start to develop as fast as possible.
      At SAP we were often blamed that NWDI is too complicated to set up and that it takes much too long to get it ready for usage. The template configuration is the answer to these accusations.
      But hiding the complexity by automating most of the necessary configuration steps also means that there need to be certain generalizations and restrictions. Otherwise the template configuration wouldn’t bring any improvement at all.
      The template configuration is intended to
      significantly lower the entry barrier to NWDI and to reduce the time until people can work with it. Thus they are faster to see NWDI’s benefits rather than loosing interest because the set up is too complex.

      Seen from this angle you are right: The template configuraton is “a proof of concept”. The way to make NWDI fun to work with and get its users to know it along the way.

      I’m  sorry that this approach came too late for you and that the template configuration created obstacles for you instead of removing them. You have learned the hard way what we assumed implicitly: Use the template configuration to set up NWDI for tests and quick development. When you know your way around configure an NWDI for “serious” use.

      I know that this is no consolation for your troubles, but I want to thank you for your valuable insight. I will see to it that the positioning of the template configuration is adjusted accordingly.

      Best regards,
      Günter

      (0) 

Leave a Reply