If you do not integrate custom development in SAP NetWeaver BW with existing BI functionality (including standard BI content), you risk redundant data storage or loss of functionality. For example, say you are required to load external, non-SAP system data that contains field material. You create a custom object, ZMATERIAL, to store material instead of using the 0MATERIAL InfoObject. This defeats the purpose of SAP NetWeaver BW because of the following two reasons:

• If you create ZMATERIAL as a master data object with all material attributes, you must maintain two master data objects for the material. This can lead to expensive system maintenance down the line because of multiple versions and difficulty in reconciliation of material-related key performance indicators (KPIs) such as inventory.
• If you create ZMATERIAL as a simple object instead of a master data InfoObject, InfoProviders with ZMATERIAL lose visibility to material master data attributes resulting in an inefficient data model.

One of the core features of SAP NetWeaver BW is that it facilitates an environment in which you can integrate data elements across functional areas for analytical and operational reporting using the extended star schema concept. Integration enables you to share master data across InfoProviders. You can share master data across InfoProviders by using the following design techniques:

• Define one InfoObject as a reference object to another InfoObject
• Use the same InfoObject in more than one InfoProvider

In addition to providing an integrated reporting environment, sharing of master data has the following advantages:

• Eliminates redundant data storage, consequently minimizing system maintenance times and cost
• Provides a single version of the truth and eases the reconciliation with the source system

In a live BI environment, any new development requires careful analysis at the design stage to leverage existing standard or custom InfoObjects prior to deciding on defining new InfoObjects. BI developer teams often perform this time-consuming task manually. Once a DataSource is replicated to BI from the source system, the developer needs to answer the question “Are there any standard or custom objects already available in the system that could be used to define transfer rule mappings (3.x) or transformation mappings (7.0) for the DataSource?” This manual process usually involves the following steps: Step 1. For each source field, using the field description, search for an InfoObject with transaction RSD1. Step 2. Determine the technical characteristics of the InfoObject in step 1 to match the source field. Experience suggests that this procedure has the following issues:

• It is manual and very time consuming
• Using a field description does not always provide accurate results leading to redundant definition of data elements (multiple InfoObjects for the same source field)
• It is more likely that source fields are mapped to incorrect InfoObjects leading to loss of data due to truncation or a data type mismatch, thereby increasing the downstream maintenance activity. Incorrect master data InfoObject mapping would lead to either loss of master data sharing or redundant storage of master data.

I will explain how the existing field mappings are stored in system tables and show how to compare them to determine if existing InfoObjects for mapping use InfoObject technical characteristics instead of field descriptions. To further illustrate, here is a business scenario that requires definition of a custom DataSource from an SAP ERP table that has the following fields:

• Order number, SAP ERP field name – AUFNR
• Document number, SAP ERP field name – BELNR

When the SAP ERP DataSource is defined and replicated into SAP NetWeaver BW, you need to determine whether InfoObjects already exist. If they do, you must evaluate if you can use these InfoObjects to map AUFNR and BELNR in transfer rules (SAP BW 3.5) or transformation mappings (SAP NetWeaver BW 7.0).

Version 3.5 versus Version 7.0

In SAP BW 3.5, an InfoSource is a required object for mapping source fields to SAP NetWeaver BW InfoObjects using transfer rules. These transfer rules are stored in the system table RSOSFIELDMAP. As you know, field AUFNR is already used in DataSource 0FI_GL_4. Figure 1 shows the transfer rules for 0FI_GL_4. It has the following fields:

• OLTPSOURCE: DataSource
• LOGSYS: Source system
• FIELDNM: Source system field  (in this case, the SAP ERP field name)
• IOBJNM: SAP NetWeaver BW InfoObject

    In this example, field AUFNR is mapped to InfoObject 0COORDER for InfoSource 0FI_GL_4. In SAP NetWeaver BW 7.0, the InfoSource is an optional object. You can map the DataSource directly to data targets (InfoProviders) using transformations. In SAP NetWeaver BW 7.0, transformation rules are stored in system table RSTRANFIELD. Field to InfoObject mappings are stored in two different records, which you can link using fields TRANID, SEGID, RULEID, OBJVERS, STEPID, and PARAMTYPE from system table RSTRANFIELD. For my example scenario, SAP ERP field BELNR is mapped to InfoObject 0DOC_NUM in an existing transformation. This mapping is stored in system table RSTRANFIELD in two records (Figure 2). These two records have distinct values for field PARAMTYPE in table RSTRANFIELD.  The value for PARAMTYPE is 0 for an SAP ERP field and 1 for an SAP NetWeaver BW InfoObject.    

Logic to Determine InfoObjects

To determine all the InfoObject mappings for a given SAP ERP field, you need to analyze all the SAP BW 3.5 DataSource transfer rules or all the SAP NetWeaver BW 7.0 transformations.

SAP BW 3.5

Step 1. For the DataSource under consideration, read all the DataSource fields from table RSOLTPSOURCEFIE in which oltpsorce = DataSource and logsys = source system. Step 2. Read all the mappings that exist in the system using table RSOSFIELDMAP for the list of source fields in step 1. This results in the following scenarios:

• If the read finds a mapping InfoObject for the field, you can choose to use the mapping for your custom DataSource
• If the read finds more than one mapping InfoObject, you need to determine which InfoObject is appropriate for the DataSource
• If the read does not find an InfoObject, follow the steps in the next section to check if any transformations exist for these fields

The “Factors to Consider” section contains the criteria you should use for the items above.

SAP NetWeaver BW 7.0

Step 1. Read all the DataSource fields from table RSDSSEGFD for information about the DataSource and source system. Step 2. Read fields TRANID, OBJVERS, STEPID, RULEID, and SEGID from the existing transformation rules. Use table RSTRANFIELD for the list of fields in step 1 where PARAMTYPE = 0. Step 3. Read the InfoObjects from RSTRANFIELD for the list of TRANID, OBJVERS, STEPID, RULEID, and SEGID where PARAMTYPE = 1. Determine whether you can use these InfoObjects for your mapping by applying the information in the “Factors to Consider” section.

Factors to Consider

You should take the following into consideration when deciding whether you can use an existing mapping rule for custom development.

• Does the InfoObject have technical characteristics — such as field data type and length — that match the SAP ERP field?
• Does the InfoObject have master data, text, or hierarchies that you can use for custom development? If these are not available, can you enhance the InfoObject instead of creating a new custom object?