In my last blog entitled What’s in a Namespace, I discussed the value of developing deliverable custom solutions in a reserved unique namespace.    In this blog, I will discuss how a namespace is related to a software component.   I will also discuss the typical product lifecycle, the software component version, and the convention which we use for establishing the software component version release increments.

DataXstream, an SAP Solution Partner, builds, packages, and distributes custom solutions for our clients.  We develop all of our custom add-on products in our own reserved and unique namespace /XSTREAM/.  But, we also need to reserve a separate unique namespace for each add-on product that we package and deliver using the SAP Add-on Assembly Kit.  So, we have a single development namespace /XSTREAM/ and a separate “packaging and delivery” namespace for each add-on product.  Why is that?

Software Component Name and Software Component Version

Let’s begin with the software component name.  A software component name references a set of objects that are always delivered together.  It contains all of the programs, classes, function modules, tables, message classes, BADIs, basic types, transaction codes, … etc. – all of the objects which constitute a custom add-on product.   We try to make our software component names meaningful, so if we are building a product named PRODUCTA, we will try to create its software component name also as PRODUCTA.

This product has a product lifecycle which begins with its initial major release at version 1.0.  As bugs are discovered and fixed or as small enhancements are made, minor updates are released, let’s say at version 1.1, version 1.2, etc.  And after some serious product re-engineering, the product is then distributed as major release 2.0.  So, the software component name represents all of the objects which constitute the product, and the software component version represents the context of the product within its own product lifecycle.  The complete picture is provided by the combination of the software component name and the software component version.  For example, we might refer to PRODUCTA at release 1.3, which is different from PRODUCTA at release 1.2, which is different from PRODUCTB at release 2.5.

At DataXstream, we build and distribute several add-on products, so you can imagine that each product currently exists at a different release level within its own product lifecycle.  PRODUCTA may be at release level 1.3, while PRODUCTB may be at release level 2.5, and PRODUCTC may still be under construction and not yet released.  If we fix bugs in or make minor enhancements to PRODUCTA, then we need to bump the software component version of PRODUCTA (and only PRODUCTA) from release 1.3 to 1.4.

Let me add another degree of complexity to this picture.  We build and deliver the same add-on product to different SAP environments.  For example, we have clients who are running SAP in the 4.7, the ECC 5.0 and the ECC 6.0 environments.  Since these environments are different, it is possible that the same product may exist at different releases in its lifecycle across all of these three SAP environments.

To help us manage this complexity, the actual software component version release names that we actually use are a bit more descriptive than 1.0, 1.1, 2.5, etc.   This will be explained in detail later on in the section Maintaining the Software Component Version.

Maintaining the Software Component Name and its link to a Namespace

The software component name is derived directly from a valid namespace that has already been registered on your SAP system.  It is, in fact, the namespace name without the two enclosing ‘/’ characters.  This establishes a relationship between the software component name and the namespace.  SAP checks and enforces this relationship when maintaining software component names.  We try to make our software component names meaningful, so if we are building an add-on product named PRODUCTA, we will reserve and register namespace /PRODUCTA/.   This allows us to then create the software component name PRODUCTA.

In SAP, we establish our software component name using transaction SSDC.  This is the Software Delivery Composer which is part of the SAP Add-on Assembly Kit.  From the initial screen in SSDC, the menu path is Environment -> Create/Update Add-on Software Component.

On this next screen, you enter the software component name that you wish to maintain.  The software component name must be derived from an already-registered valid namespace.  For example, if you have already registered the namespace /ABCD/, then you can create a software component that is named ABCD.  SAP checks this relationship, and issues an error message if you try to create an invalid software component name that cannot be derived from an already existing namespace.

SAP allows as many as ten characters for the software component version or release name.  This allows us to build meaningful release names, which really helps to sort things out when you are dealing with many products over several SAP environments.  Here are a few demonstrative examples of how we build our release names:

Maintaining the Software Component Version

On this screen, you enter the software component version or release name, and a description, then press the SAVE icon.

Another Piece of the Puzzle – the Package

We want each of our products to have its own unique software component, because each software component or product has its own unique set of objects and needs to exist at its own software component version within its own product lifecycle.  We need to allow all of the development objects for PRODUCTA to be at release 101_470 and all of the development objects for PRODUCTB to be at release 103_500. But, if we perform all of our development for all of our products in the /XSTREAM/ namespace, how do we assign all of the /XSTREAM/ development objects for PRODUCTA to software component PRODUCTA, and all of the /XSTREAM/ development objects for PRODUCTB to software component PRODUCTB?

The answer is in the package or development class.  When creating a package, you must specify the software component that the all of package objects will be assigned to.  The example below shows the creation of a package or development class /XSTREAM/PRODUCTA.  One of the parameters of the package is the software component.  We would assign software component PRODUCTA to this package.

So, when building the product PRODUCTA, we create many development objects (programs, classes, tables, etc.) in the /XSTREAM/ namespace, we assign those objects to the /XSTREAM/PRODUCTA package, which in turn, assigns those objects to the software component PRODUCTA which exists at a particular release level in its lifecycle.

Summary

To summarize, because of the dependencies between namespaces, software components, packages, and development objects, these actions must occur in the following order: