Creating and Shipping Custom Content in the OLTP System

Prerequisites

Prerequisites in the development and test/delivery system for customer content:

You set up the corresponding system landscape and made the required system settings. You also requested and released the namespace for developing and generating objects and set it to changeable.

More information:

System Landscape

Making System Settings for Content Creation

Using Namespaces for Developing BW Objects

Prerequisites in the customer system into which content is imported:

You have ensured that the OLTP system in which the delivered content is to be delivered, is not defined as a content development system. You can check this in the Content Development Maintenance screen (transaction RSA0).
You have created the namespace as changeable in the OLTP system (role C).
You have ensured that a generation namespace has been released in the BW system in which the DataSources are to be replicated.
You have created and released the same generation namespace in the OLTP system.

More information: Using Namespaces for Developing BW Objects

Procedure

Create a generic DataSource as customer DataSource.

For more information, see Maintaining Generic DataSources.

If you generate a DataSource in a BI Content development system, the system generates an A and a D version in the defined namespace. The DataSource is identical in the A and D versions. There is only one version for the extract structure of the DataSource.

If you generate a DataSource and thus an extract structure, the system writes the following transport objects to a transport request:

Transport object	Description
R3TR OSOD /<Namespace>/<DataSource> /ABC/DATASOURCE1	D version of the DataSource
R3TR TABL /<Namespace>/ES<DataSource><four-digit counter> or R3TR TABL /ABC/<Your name for the extract structure> /ABC/ESDATASOURCE10001	Extract Structure

Transport object

Description

R3TR OSOD /<Namespace>/<DataSource>

/ABC/DATASOURCE1

D version of the DataSource

R3TR TABL /<Namespace>/ES<DataSource><four-digit counter>

R3TR TABL /ABC/<Your name for the extract structure>

/ABC/ESDATASOURCE10001

Extract Structure

The active version of the DataSource (object type: OSOA) is not linked with the transport system and is not delivered.

SAP supports the creation of customer DataSources that are extracted from database tables and views or from the function module.

Note the following when extracting from the view or table:

When extracting from the view or table, the system creates a proposal for the name of the extract structure if you enter the name of the DataSource: /<Namespace>/ES<DataSource><four-digit counter>, for example, /ABC/ESDATASOURCE10001.

Note

You can change the name of the extract structure.

You need this option if you make incompatible changes to the extract structure (for example, change the field type) and the productive scenario in the delivered system should not be changed. In this case, enter a new name for the extract structure in the screen for creating a DataSource. When you generate the changed DataSource, the extract structure is generated again under this name.

Note the following when extracting from the function module:

When extracting from the function module, the system does not generate a proposal for the extract structure. Enter the name of the extract structure that you previously created in your namespace in the ABAP Dictionary.

If you make incompatible changes to the extract structure (for example change a field type), you create an extract structure with a new name in the ABAP Dictionary (as a modified copy of the old structure). In this way you ensure that the productive scenario in the delivered system is not changed and the extract structure is not overwritten.

Create a customer application component hierarchy.

Note

If you want to deliver your own DataSources, you need not necessarily have your own application component hierarchy. Check if an existing application component is suitable for grouping and delivering your DataSources. If your DataSources are not assigned to any application component, they appear in the application component hierarchy under the node NODESNOTCONNECTED and can be used and processed in the normal manner.
1. Enter transaction code RSA8 in the command field.
  
  The Hierarchy Selection dialog box appears.
2. Enter the name of the hierarchy if it differs from the default name.
  
  Choose Create.
3. Edit and save the hierarchy. For more information about editing the application component hierarchy, see Editing DataSources and Application Component Hierarchies.
  
  When you save your hierarchy, the system writes the transport object R3TR DSAD /ABC/<application component hierarchy> to a transport request.
  
  The same is true for the application component hierarchy, which can only be transported completely, as for the DataSource, namely that the system creates a D version and an identical A version during the save.
  
  Note
  
  For example, if you want to keep the D version after a change of system, you should execute the report RSA1APDC before editing the hierarchy. This report creates an A version from the imported D version.
The D versions of the generated DataSources and application component hierarchies as well as the extract structures and possibly the function modules are on a transport request. They can be transported to the content test or content delivery system and delivered to customers or business areas from there.
Deliver the objects (DataSources and application component hierarchies in the D version, extract structures, extractors) from the content test system or delivery system using a delivery transport (for more information, see System Landscape). Note that for objects in A and D versions, the system only writes the D versions of the object to the transport request. You ensure this by selecting the Content Development field in the Content Development Maintenance screen (transaction RSA0) in the system.
After the import of the D versions, your customers (business area) can activate the DataSources and application component hierarchies and use them similarly to the BI Content delivered by SAP.

Note

Using application component hierarchies delivered as customer content:

All application component hierarchies in the D version are merged in a hierarchy upon activation in the OLTP system (transport object R3TR DSAA APCO_MERGED). This hierarchy also contains the customer content hierarchy. The merged hierarchy is replicated as a single object in the BW system. The customer application component hierarchy is therefore not displayed as a separate object in the BW system.

The following graphic illustrates the process flow for DataSources and application component hierarchies:

For objects which are seen as content objects in a system (with a changeable namespace and where the system is a content development system), the system automatically activates the DataSource in an after-import method for the D version. For more information about the activation of BI Content in OLTP systems in business areas, see Installing Application Component Hierarchies and Installing BI Content DataSources. In this system, object changes are saved in the active version. The D version remains unchanged.