Disclaimer: This weblog is based on version 1.4 of the certification criteria for certifications based on NW-XI-CNT or NW-XI-CNT-IS. SAP can define new versions of the certification criteria at any time. 
The combination of namespace and repository object name should be a unique identifier for each object (even though technically the unique identifier is the assigned GUID). To ensure this uniqueness, some information that is common to our package (but may differentiate us from other packages) is incorporated into the namespace definition. Since products going for XI content based on industry standards certification are always based on an industry standard, SAP has decided to use some of the standard specific information in the definition of the namespace. Therefore the naming conventions for the two certification paths are different. 
The objects that need to be created in the integration repository and not in the SLD are not listed in this appendix, since there is already a lot of documenation available on how to create these objects.
1 Introduction
You know that you want to build an XI content package and that you want to get it certified from SAP either as XI content (SAP Process Integration - Content Certification (NW-XI-CNT)) or as XI content based on industry standards (NW-XI-CNT-IS). You also know the weblog SAP Partners Developing Content using XI3.0 from Prasad Illapani and from here you know that you have to start your development by creating your product (and versions), your software components (and versions), and your namespaces. These objects serve as your containers for all other objects you create in the integration repository. But how do you make sure that your product, software components, and namespaces are set up according to the certification requirements and follow the naming conventions laid out in the certification criteria? After all, you don't want to redo all your work just because you didn't follow some naming conventions. Besides checking the certification documentation itself you can continue to read this weblog. Here I try to answer all these questions.2 The Scenario
Let's assume we work for the company My Company which uses the internet domain www.mycompany.com. This company already has its own product called My Product. Now we want to build two more products using the SAP NetWeaver platform and have them certified by SAP.Product 1
Our first new product connects our existing product My Product with the SAP ERP backend using some proprietary interfaces and supports some forecasting functionality. More specific, the strategic forcasting for projecting anticipated product sales are supported with this product. The latest version of My Product is version 2.5. With this new product 1 we want to become XI content certified.Product 2
With our second product we want to offer a transformation from the BAPI interfaces used in the SAP ERP forecasting to the following standard RosettaNet interfaces:- PIP4A3 Version V02.02.00 (Notify of Threshold Release Forecast)
- PIP4A5 Version V02.00.00 (Notify of Forecast Reply)
3 Product Definitions
As a first step we need to define our products in the system landscape directory (SLD) providing the following information (see also the input screen below):- Vendor name
- Product name
- Product version
3.1 Vendor Name
The naming convention for the vendor name in both certifications, XI content and XI content based on industry standards, simply states to use the following definition:<Vendor Domain Name> In addition, the help in the SLD states to enter the vendor as a URL, for example sap.com. That means we can simply choose the name of our company as the vendor name in form of a URL. In our example we use our internet domain mycompany.com as the vendor name. 3.2 Product Name
The product name should describe on a high level the area our product is being used in. Since products going for XI content based on industry standards certification are always based on an industry standard (as the name already says), SAP has decided to reflect this special feature also in the product name. Therefore the naming conventions for the two certification paths are different.3.2.1 Product Name for NW-XI-CNT
The naming convention for the product name in XI content certifications states to use the following definition:<Area> It further specifies that the <Area> can be an application area like ERP, CRM, etc., but can also be an industry standard like RosettaNet. Since the XI content certification typically certifies the backend integration between a partner product and SAP (see also the following flashbook from Christoph Claus) the application area usually describes the key application of the partner product that is integrated to SAP. Since our first new product provides an integration between our existing product (My Product) and SAP in the area of forecasting, the name of this new product is Forecasting. 3.2.2 Product Name for NW-XI-CNT-IS
The naming convention for the product name in XI content based on industry standards certifications states to use the following definition:Package for <Standard> Since our second product provides transformations to the RosettaNet standard, we use the product name Package for RosettaNet. 3.3 Product Version
The naming convention for the product version in both certifications, XI content and XI content based on industry standards, states to use the following definition:<NetWeaver Version>.<Content Version> The <NetWeaver Version> depends on the XI release we choose for our development. Currently we have the following options: - NW04 for SAP NetWeaver 2004 (which contains XI 3.0)
- NW04s for SAP NetWeaver 2004s
4 Software Component Definitions
As the second step we need to define our software components in the system landscape directory (SLD) providing the following information (see also the input screen below):- Product name and version
- Vendor name
- Software component name
- Software component version
4.1 Software Component Name
The software component serves as a container for all repository objects. Therefore the software component name should contain some information that is common for a number of repository objects but that can be used to structure our products in a meaningful way. Since products going for XI content based on industry standards certification are always based on an industry standard, SAP has decided to use this information also in the software component name. Therefore the naming conventions for the two certification paths are different. It is also important to note that the definition of software component names consists of multiple parts:- The technical name that is defined in the first step. The technical name has some limitations (e.g. no white spaces are allowed) that limits its readability.
- The caption (short description) that is actually used for display in the integration repository. By default the technical name is also used as the caption but the caption can be changed in a second step. Chapters 7.2 and 7.3 describe in detail how to perform these steps.
4.1.1 Software Component Name for NW-XI-CNT
The naming conventions in XI content certifications state to use the following definitions:- For the technical software component name
<Vendor Name>_<Vendor Software> - For the caption (short description) of the software component:
<Vendor Name> <Vendor Software>
4.1.2 Software Component Name for NW-XI-CNT-IS
The naming conventions in XI content based on industry standards certifications state to use the following definitions:- For the technical software component name
<Vendor Name>_<Standard>_<Vendor Software Component> - For the caption (short description) of the software component:
<Vendor Name> <Standard> <Vendor Software Component>
4.2 Software Component Version
The naming convention for the vendor name in both certifications, XI content and XI content based on industry standards, states to use the following definition:<Vendor Software Version> The <Vendor Software Version> is a simple numbering to differentiate multiple versions and sub-versions of our software. The numbering can start with a new version number (like 1.0) or can be aligned to the existing product version of the product we want to integrate via the XI content package. In our case we want to align the version number of our first new product to the version number of our connected backend product (My Product), while we start the version numbering for our second new product from scratch. Therefore we use the software version number 2.5 for our first new product (that becomes XI content certified) and the software version number 1.0 for our second new product (that becomes XI content based on industry standards certified). 4.3 Dependencies to Existing Software Components
While the certification criteria for XI content give us some freedom if we want to utilize already existing software components, the certification criteria for XI content based on industry standards force us to utilize already existing software components in certain circumstances. XI content that is based on industry standards always uses standard interfaces that are defined and published by a standard organization (like RosettaNet). These interface definitions can already be available in one of the software components delivered by SAP. In this case we must use the definitions delivered by SAP by making our software component dependent to the SAP software component that contains the standard interface definitions. Our second product utilizes the RosettaNet standard interfaces PIP4A3 and PIP4A5. Both of these interfaces are already delivered by SAP in the software component ROSETTANET (version 1.0). Therefore we have to create a dependency from our software component version MY COMPANY ROSETTANET ERP 1.0 to the software component version ROSETTANET 1.0 that is delivered by SAP. In many cases we may not know if the standard interfaces we want to support are already included in a software component delivered by SAP. In this case we should contact SAP directly (via ICC) to get this information.5 Namespace Definitions
After the software components we just created have been imported into the integration repository, we need to define the namespaces we want to use in our development next (see also the input screen below). The combination of namespace and repository object name should be a unique identifier for each object (even though technically the unique identifier is the assigned GUID). To ensure this uniqueness, some information that is common to our package (but may differentiate us from other packages) is incorporated into the namespace definition. Since products going for XI content based on industry standards certification are always based on an industry standard, SAP has decided to use some of the standard specific information in the definition of the namespace. Therefore the naming conventions for the two certification paths are different. 5.1 Namespace Definition for NW-XI-CNT
The naming convention for the namespace in XI content certifications states to use the following definition:http://<;Vendor Domain Name>/xi/<Vendor Software>_<Vendor Software Version> Here the <Vendor Software> is specified identical to the <Vendor Software> used in the definition of the software component and the <Vendor Software Version> is specified identical to the <Software Version> in the definition of the software component version. Since our vendor URL is mycompany.com and the area for our first product is My Product we use http://mycompany.com/xi/MyProduct_2.5 as the only namespace for our first product. 5.2 Namespace Definition for NW-XI-CNT-IS
The naming convention for the namespace in XI content based on industry standards certifications states to use the following definition:http://<;Vendor Domain Name>/xi/<Standard>_<Standard Version> /<Vendor Software Component>_<Vendor Software Component Version> Here the <Vendor Software Component> is specified identical as in the software component definition. If an SAP component is being used instead we should contact SAP (via our ICC contact) to receive the exact naming conventions for the <Vendor Software Component Version>. Some of the commonly used software component names and versions are - For ERP
- ERP 46C for SAP R/3 Release 4.6C
- ERP 470 for SAP R/3 Enterprise Release 4.70
- ERP 500 for mySAP ERP Release 5.0
- ERP 600 for mySAP ERP Release 6.0
- For CRM
- CRM 400 for SAP CRM 4.0
- CRM 500 for SAP CRM 5.0
6 Integration Scenario Definitions
The integration scenario is the central object in the integration repository containing the complete picture of the scenario(s) delivered with the XI content package. The information from the integration scenario is also used in the partner catalog to describe the content of the particular package. For this reason SAP decided to specify specific naming conventions for the integration scenarios.6.1 Integration Scenario Name
Since products getting XI content certified are typically A2A scenarios, while products getting XI content using industry standards certified are often B2B scenarios, the naming conventions for the integration scenario names differs slightly for the two certification processes.6.1.1 Integration Scenario Name for NW-XI-CNT
The naming convention for the integration scenario name in XI content certifications states to use the following definition:IS_<Short form of process name> The short form of process name should describe the process supported with the specific integration scenario in form of a short headline. Note that no white spaces are allowed in the name. Our first new product contains only one integration scenario that supports the forecast of projected product sales. Therefore we choose IS_ForecastProjection as the name for this integration scenario. 6.1.2 Integration Scenario Name for NW-XI-CNT-IS
The naming convention for the integration scenario name in XI content based on industry standards certifications states to use the following definition:IS_<Short form of process name> or IS_<Short form of process name>_<Role> The first option is used in case of an A2A scenario while the second option is used in case of an B2B scenario. In case of an B2B scenario we need in addition to the short form of process name (used identical as in the XI content certification) also specify the role we assume in the B2B scenario. With our second product we plan to support all roles that are involved in the RosettaNet scenario, which are the customer and the supplier. Therefore we need to define two integration scenarios within this product. The first integration scenario is from the point of view of the customer and is named IS_ReleaseForecast_Customer, while the second integration scenario is from the point of view of the supplier and is named IS_ReleaseForecast_Supplier. 6.2 Integration Scenario Definition
The naming convention for the integration scenario definition in both certifications, XI content and XI content based on industry standards, states to use the following definition:Integration Scenario for <Process name> with <Main SAP software component of IS> [and <Main non-SAP software component of IS>] The naming convention for the integration scenario definition assumes that usually an SAP component is connected to a non-SAP component. If one of these pieces is missing in the scenario, the respective portion of the definition can be dropped or be replaced with another meaningful description. Our first new product supports the forcast of projected product sales and connects the SAP ERP system with our own backend system named My Product. Therefore we use the following integration scenario description for this scenario: Integration Scenario for Forcasting of Projected Product Sales with SAP ERP and My Product
Our second new product supports the release of forecasting information from a customer point of view as well as from a supplier point of view. It integrates only the SAP ERP backend via the RosettaNet standard. Therefore we use the following two integration scenario descriptions for our scenarios: Integration Scenario for Forecast Release as Customer with SAP ERP and RosettaNet Integration Scenario for Forecast Release as Supplier with SAP ERP and RosettaNet
7 Appendix
The appendix describes step-by-step how to create the necessary objects in the system landscape directory (SLD). The starting point for each of these step-by-step descriptions is the initial screen of the SLD that looks as follows: The objects that need to be created in the integration repository and not in the SLD are not listed in this appendix, since there is already a lot of documenation available on how to create these objects. 7.1 How to Create a Product
- Within the System Landscape Directory (SLD) select Software Catalog.
- Set the software type to Products (should be the default setting) and click on New Product.
- Enter the Vendor, Name, and Version based on the naming conventions discussed above and click on Create.
7.2 How to Create a Software Component
If you just created the product, the screen automatically switches to the creation of a software component with the product and vendor information already filled. In this case you can start with step 4.- Within the System Landscape Directory (SLD) select Software Catalog
- Set the software type to Software Components and click on New Component
- Select the Product and Vendor that are already defined (see previous step).
- Enter the Name and Version (of the software component) based on the naming conventions discussed above and click on Create. The name entered is used as the technical name as well as the short description (caption) of the software component.
7.3 How to Change the Name of a Software Component
Often the name of the software component that should be displayed (e.g. in the integration repository) is not identical to the technical name that gets created with the steps described above. Therefore it is necessary to change the short description (caption) of the software component in a second step described here.- Within the System Landscape Directory (SLD) select Content Maintenance.
- To change the name of the software component choose the subset Component Information and the class Software Component.
- In the list click on the software component you want to change (use the filter to reduce the number of items displayed in the list).
- Change the name in the field Caption and click on Save.
7.4 How to Create a Dependency to Another Software Component
In chapter 4.3 we discussed the need to create dependencies between software component versions in certain scenarios. These dependencies are also created within the system landscape directory.- Within the System Landscape Directory (SLD) select Software Catalog.
- Set the software type to Software Components and in the list displayed click on the version of the software component you want to create a dependency for. You can use the filter to restrict the list display.
- On the next screen click on the link Usage Dependencies.
- Change the dependency context to Installation Time and click on Define Dependencies.... You may want to use the filter to restrict the list of software component versions being displayed.
- Mark the software component versions you want to create a dependency to and click on Create.
4 Comments