In most cases a BW development landscape consists of three systems: the development, the acceptance, and the productive systems. How can you handle central development for a company in which several BW systems are in place? A common strategy is to use a central development system, which delivers the applications to several acceptance systems. This strategy works as long as the application is used identically on all target systems. If only the core application is identical on the target systems and you need to adapt it on each system to correspond to local requirements, then introducing a central content system is a useful strategy.

With a central content system, you can:

• Transport a BW application developed as content to several target systems
  
  
• Activate part of the content in the target system and adapt or enhance it to local requirements
  
  
• Develop and deploy a new content version without influencing activated content used in production on the target system
  
  
• Merge features from a new version of the delivered content with activated, adapted, or enhanced content from an older version

I’ll explain the technical details of the central content system configuration and how it differs from a regular development system. First, I’ll go over the configuration involved in switching to a central content system. This includes a discussion about object versions and the transport systems. I’ll then provide tips for using namespaces and external content objects. Finally, I’ll show you how to activate roles and set up content development in an online transaction processing (OLTP) system. When complete, the system landscape looks similar to the one shown in Figure 1.

Figure 1

Central content system landscape

Central Content System Configuration

Use transaction RSOCONTENT to change the content system setting (Figure 2). Selecting the System is a Content Development System check box switches the system to content development mode. This causes the system to behave differently from a regular system — this mainly affects the object versions and transport system. Let’s look at these in more detail now.

Figure 2

Activate content development system

Object Versions

When developing in a regular BW system, each object exists in two versions: the active (A) and the modified (M) versions. When changing an object (e.g., an Info-Object), only the M version is affected. The A version is updated when you activate the object, and the changes made to the object are applied to the database.

In a central content system, this mechanism is the same. In addition to the A version, the system creates a delivery (or content) version (D). Figure 3 illustrates the entries in the InfoObject table RSDIOBJ for the InfoObject TESTCONT1 in a content system. Three versions of this object exist, whereas in a regular system, you would find only the A and M versions.

Figure 3

Object versions in a content system

Transport Systems

The additional D version for each object is really the only difference between a regular and a central content system. This difference becomes obvious when transporting objects from a content system to other BW systems. Let’s take a look at an InfoObject transport request in a regular system. Figure 4 shows that the system uses object type IOBJ to transport the InfoObject TESTCONT1.

Figure 4

InfoObject transport request in a regular system

When importing such a request into the target system, the system creates the M version of the object. After the import is complete, the system executes the “after import” methods — they have the same effect as activating an object (i.e., generating all Data Dictionary objects and creating the A version). The same transport request in a central content system looks similar to what is shown in Figure 5.

Figure 5

InfoObject transport request in a central content system

Instead of IOBJ, the system uses object type DIOB to transport the D version of the object. After importing this request into a target system, no after import methods are executed. All you can find in the system after import is the inactive content version. The transport objects used to transport BW objects are called TLOGO objects (logical transport objects). Two versions exist for each object, A- TLOGO (to transport active versions of the object) and D-TLOGO (to transport content).

To use an object that was imported via a D-TLOGO transport object, you must first activate it from the Business Content by following menu path Administrator Workbench>Business Content. Business Content uses the same technique and allows you to import a new version of a content object into the target system, even if an older version is active and used in the productive environment. The diagram in Figure 6 illustrates a typical evolution of an object in a central content system.

Figure 6

Object evolution in a central content system

When you finish developing the central content system, the next step is to transport all the objects to the target system. In a regular BW system, you use the transport connection functionality of the Administrator Workbench to assemble transport requests. This method also works in a central content system; the only difference is instead of A-TLOGO objects, the system writes D-TLOGO objects to the request.

Nevertheless, SAP recommends that you activate the standard Change and Transport Organizer (CTO) by following menu path Administrator Workbench>Transport Connection>Edit>Transport>Switch-On Standard. Activating the CTO results in a pop-up window in which you enter the package and transport request for each object created. This guarantees that the system creates a consistent and complete content transport. In principle, you can use the system to develop and deploy content by activating CTO, but you must ensure that no conflicts occur between object names because you can deliver customer content developments to BW systems in which other local developments exist. You can accomplish this by using a unique namespace for the content objects.

Namespaces

In most cases, companies decide to use a central content system because they have a BW application delivered to several target systems. Objects in a central content system could interfere with objects that they developed locally on the target systems. For that reason, I recommend that you use your own namespace for the central content system.

You can reserve namespaces via the SAP Service Marketplace (alias/namespaces). In contrast to the namespaces used in ABAP development, you must reserve two namespaces for a BW content system: the development and the generation name-spaces. After registering the namespaces at SAP Service Marketplace, maintain them in BW via transaction SE03>New entries.

Whereas the development namespace (e.g., /EVX/ on my system) has the role P (producer), the generation namespace (e.g., /B33/ on my system) has the role C (consumer). Therefore, you need only a repair license, rather than a development license, to maintain the namespace. After introducing the namespaces, maintain the relationship between all of them in transaction RSNSPACE.

In this example, in which you can create BW objects in the development namespace /EVX/, the system creates all Data Dictionary objects related to a BW object with the generation namespace prefix (e.g., data element /B33/OICCTEST01), as shown in Figure 7.

Figure 7

InfoObject created with the development namespace /EVX/

The development namespace should be as short as possible because of the restricted length of the technical names of BW objects. For InfoObjects, the maximum length for a technical name is 14 – N, in which N is the length of the namespace, including slashes. In my example, the maximum length is nine characters. The generation namespace must start with B, followed by numeric characters. Now that I have described the basic concepts of the customer content technology, the next section shows how SAP Business Content can be used together with customer content.

External Content Objects

In a central content system, you cannot change or activate external content delivered to it (i.e., SAP Business Content). Changing any BW object also changes the D version of the object, so objects delivered as content to the system are locked against changes — the Business Content button on the left side of the Administrator Workbench is inactive.

Nevertheless, you may need to use Busi­ness Content objects. For example, if the InfoObject 0CUSTOMER fits your requirements, you do not need to create a new object for it in the customer content namespace. How can you activate these objects? SAP provides the user parameter RSOISCONTENTSYSTEM that you can set to blank for a specific user in transaction SU01, as shown in Figure 8. For a user with this parameter set to blank, the system behaves like a regular BW system (i.e., it does not create D versions for new objects). You can activate and change external content objects for M and A versions.

Figure 8

Set the Parameter value for RSOISCONTENTSYSTEM to blank

When using Business Content objects, you should avoid transporting them to the target systems because this would overwrite the D versions of the Business Content in the target system. SAP has its own Business Content releases and Support Packages. Therefore, overwriting D versions of Business Content could lead to inconsistencies when the Business Content release differs between the central content and target systems. When transporting a developed application, only the customer content objects are transported to the target system, as shown in Figure 9.

Figure 9

Transport of a custom-content InfoCube containing an InfoObject of the SAP Business Content (0CUSTOMER)

Moreover, in some cases you cannot avoid changing external content. This is especially the case when using Business Content DataSources because the object names for the transfer rules and structure (D-TLOGO, SHMP, and SHTR) start with the DataSource name. This is in SAP’s namespace, so you cannot change it.

To use Business Content DataSources, switch the external content objects to changeable (see SAP Note 539278). Use transaction RSOCONTENT and click on Switch External Content To Changeable (Figure 10). If the DataSource delivers the correct data, you do not need to program a new DataSource, which can be complicated if a delta update is necessary. Use this option carefully. You can potentially activate and change the target system’s SAP business content in a way that is not compatible with the business content you use for the central content system.

Figure 10

Switch external content objects to changeable

All the previously mentioned objects use the mechanism with D and A versions. If you want to use roles together with the content, apply the technique explained in the next section.

Roles

In contrast to BW objects, roles are objects in SAP Basis, so no content (or D version) of roles exist. However, SAP delivers roles with Business Content that you can activate in the same manner as BW objects in the Administrator Workbench.

Roles with technical names that begin with SAP_BW_ are interpreted as Business Content. When you activate them, the system creates a copy that begins with SAP_BWC_. A similar behavior to BW objects is simulated. However, you cannot merge your enhancements and an enhanced content version of a role. When activating a new version of a content role, the system overwrites the active version and your enhancements are lost. You can use the same technique for the central content system. In transaction RSOCONTENT go to Namespace for Roles. Here you can specify two name prefixes (Figure 11).

Figure 11

Example of two namespace prefixes

With the setting in this example, you can deliver roles that start with prefix /EVX/ (e.g., /EVX/TESTROLE). The system recognizes these roles as content roles in the target system. When you activate them in Administrator Workbench, the system copies them to the appropriate namespace (e.g., /EVX/TESTROLE is copied to /EVX/C_TESTROLE). This technique allows an adaptation of the activated roles in the target system without the risk of losing this adaptation after importing a new content release.

Now I’ll describe how you can develop extractors in an SAP R/3 system as customer content.

Set Up Content Development in an OLTP System

Content is not only restricted to objects in BW. Extractors and DataSources in R/3 source systems can also be delivered as content to develop a complete application from extraction to reporting as custom content. A content extractor has the same advantages — local adaptation and delivery without influencing the active extractor. To indicate that you want the system to deliver an extractor or DataSource as content, use transaction RSA0 to change the setting in R/3.

You can also create and transport your own application component hierarchy to structure your self-developed R/3 content DataSources as shown in Figure 12.

Figure 12

Settings for customer content development in the R/3 system

In transaction RSA0, you must specify the name of the content application component hierarchy. You maintain the structure of the hierarchy in transaction RSA8. When you transfer the application component hierarchy in transaction SBIW, the system combines this hierarchy with the application component hierarchy delivered with the business content. As with content development in a BW system, I recommend that you use a unique namespace for content development in the OLTP system. You only need to set up the development namespace — a generation namespace is not necessary.

Tips to Solve Common Problems

Now that I’ve shown you the necessary configuration options, let’s look into some tips for solving common problems you may encounter.

Tip 1. Configure the system landscape. For content development, a single system in which you create the BW application and assemble the transports is usually sufficient. However, the problem with this configuration is that you cannot test content activation centrally.

You can solve this problem by introducing a second content system configured identically to the central content system. A user with settings as shown in Figure 8 (user parameter RSOISCONTENTSYSTEM set to blank) can then test the activation of the content application to make sure all objects are available and can be activated. If this is the case, you can create a new content transport on the test system to deploy the content application to the target systems, as illustrated in Figure 13.

Figure 13

Possible customer content system landscape

When you use a central content test system, you can significantly increase the quality of the content application and of the application transport.

Tip 2. Use SAP Basis objects. You may need to use Basis objects together with custom content (e.g., if you use your own customizing tables to control the logic in transfer or update rules). The problem here is that for these objects, no D version exists. They are active and available after importing in the target system. This foils one of the advantages of the content technology — the possibility to import a new release without influencing the active version. The following example illustrates a workaround when using SAP Basis objects.

Let’s assume that the system uses the function module /EVX/TRANSFORM in the content application’s update rules. When you deploy a new version of the content, you should rename the Basis objects if the system changed them (Table 1). This naming convention allows you to import the next release of the application without influencing the current productive release, which uses function module /EVX/TRANSFORM_10. The system doesn’t use the enhanced function module /EVX/TRANSFORM_12 until you activate the new release.

Tip 3. Manually append a generic function call to the user exit at the target systems. Another problem occurs when using user exits (e.g., for reporting variables). You cannot transport the exit itself (e.g., the include ZXRSRU01) to the target systems, because if you implement the exit in the target system, the system overwrites it.

A solution is to swap out the logic for the variables into function modules and manually append a generic function call to the user exit at the target systems. When appending a generic function call, use a naming convention for the function modules or a customizing table to relate function modules to variable names. After you append the generic function call, you can deploy a function module for each variable together with the content, which the system calls automatically if it uses the variable in a query.

Tip 4. Use transaction SE63 for language translations. In a regular BW system, it is common practice to develop in one language. When other languages are needed, developers often log on in the desired language and update the text again. This method does not work in a content system for query elements. Here you must use the translation environment. Configure the basic settings in transactions SLWA and SLWB, and perform the translation in transaction SE63.

Tip 5. Don’t use a separate namespace for Query Builder objects. In contrast to Administrator Workbench objects, you cannot use a separate namespace for Query Builder objects, such as queries or variables. If these objects are delivered together with a content application, you must ensure that the names of the elements are unique and don’t exist on the target system. Otherwise, you could activate the query from the content, but it would not appear in Business Explorer (BEx) or transaction RSRV. Therefore you cannot use them.

Robert Braun

Dr. Robert Braun has been working with BW since 1998, starting from one of the earliest releases, BW 1.2A, up to SAP NetWeaver 7.0. He has managed various SAP BW and SEM-BPS implementation projects as a consultant. The focus of his latest project was implementing the customer content technology.

You may contact the author at Robert.Braun@evivax.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.