Introduction

Characteristic relationships allow to model the admissible combinations of characteristic values in basic real-time Infoprovider by means of master data attributes, hierarchies, DataStores, … etc. The settings in characteristic relationships are more flexible than e.g. compounded characteristics but will usually not changed very often.  

Characteristic relationships provide the following basic functionality:

• Check combination, i.e. a modeled consistency check combinations of characteristic values.
• Derivation, i.e. a modeled derivation of characteristics values from a given set of source characteristics.
• Combination proposal: For a given set of characteristics and a selection this service generates all valid combinations of characteristic values. This function is compatible with check combination, i.e. generated combinations are valid and there exist no valid combinations that will not be generated.

See SAP Online Document.

Generic Characteristic Relationship

Generic characteristic relationships are of more technical nature. These relations cannot be customized, they are always active during runtime. These relations come from the BW metadata (compounding, navigation attributes, MultiProvider, key figures and unit characteristics), are pure technical (SIDs in connection with compounding or navigation attributes) or are specific for BI time characteristics. These relations are needed most often in the OLAP Processor but are also used in Planning Functions. In the following sections we describe these ‘generic’ characteristic relationships.

• Compounded Characteristics and SIDs

  For compounded characteristics a SID encodes at least two characteristic values in one integer value. See this Example. , the Cost Area(0CO_AREA), Cost Center(0COSTCENTER) combination 2000/2000 is represented by a certain SID value 201 that can be seen in SID table /BI0/SCOSTCENTER. The OLAP processor uses SIDs for all characteristics. Thus also Cost Area values are represented by SIDs and this means that a combination of Cost Area and Cost Center values represented by SIDs may not exist:

1. 2000/2000 is represented by SID 201.
2. See table /BI0/SCO_AREA, 1000 is, for example, represented by SID 7, and 2000 is represented by SID 11,
3. SID combination 7, 201 for Cost Area, Cost Center is inconsistent. Then the error RSPLS_CR 009 is triggered.

• Navigation Attributes and SIDs

  Navigation attributes are master data attributes that can be used as normal InfoProvider characteristics in queries. Thus similar to the above examples the basic characteristic and the navigation attribute may be contained in the row, column of a query view, respectively. Thus the system has to make sure the values of the basic characteristic and the navigation attribute are consistent. See the Example.

• Time Characteristics Relations

  BW supports 13 time characteristics. One part of the planning model is to choose the ‘right’ time characteristics for the real-time InfoProvider. Depending of the planning application, the characteristic ‘0fiscper’ is convenient (12.2005 + 1 = 1.2006), but to be able to build nice query views (e.g. periods in rows and year in data columns) other time characteristics are need. To support these kind of scenarios BW Integrated planning will check time characteristics to be consistent, redundant time characteristics should be avoided in Aggregation Levels since these characteristics can (and will) be derived if redundant characteristics are contained in the real-time InfoProvider. See the Example.
  Technically the system generates characteristic relationships for time characteristics on the fly depending on the requested time characteristics in Plan Queries or Planning Functions. These ‘time relations’ are all of type derivation. All of the time relationships can be seen at online document.

Customized Characteristic Relationship

In addition to the generic characteristic relationships, one can model relationships explicitly in the Planning Modeler on the real-time InfoProviders. These relationships are automatically visible in all InfoProviders relevant for BI Planning, i.e. they are known in manual planning via Plan Queries and in Planning Functions.
The atoms (i.e. smallest units) of characteristic relationships are called steps or simply relations. These relations are defined for at least two characteristics. The following types of Characteristic Relationships are available:

• Attributes

  The admissible characteristics for a relation of type attribute are the characteristics of the real-time InfoCube with attributes. The basis characteristic is then the source characteristic, if this characteristic is compounded the compounding parents are also sources. As target characteristics one can choose one or more attributes of the base characteristic (not necessarily navigation attributes, but of course no key figures). The valid combinations are then defined by the corresponding records in the master data table. See the example.
  
  

• Hierarchy

  The admissible characteristics for a relation of type hierarchy are the characteristics that support hierarchies defined in transaction RSD1/RSH1. Thus, in a relation of type hierarchy one has to choose one hierarchy. In the relations one can now use all ‘external characteristics’ defined in RSD1 including the hierarchy characteristic as source or target characteristics. The relation of type hierarchy only supports only one source and one target characteristic. Since hierarchy structures are usually used for derivation the hierarchy has to be ‘unique’, i.e. a node can only occur once. Also link nodes are not supported. One can use a hierarchy in more than one relation. It is also possible to parameterize the hierarchy with variables; these variables a not allowed to send a user dialog for value replacement. See the example.
  
  

• DSO (DataStore Object)

  The records in the DSO defines the valid combinations or will be used for derivation. The characteristics contained in the DSO structure can be used in the relation as follows:

  • Only check combination: One can choose a subset of InfoObjects (except key figures) from the DSO structure for check combination.

  • With Derivation : The source characteristics are the characteristics from the technical key of the DSO. As target characteristics one can choose characteristics from the data part of the DSO structure.

  In both cases restrictions for the characteristics in the key of the DSO can be used. But this key with restrictions can then not be used in a relation. Then only the subset of records defined by the restriction will be used for check combination and derivation (and combination proposal). These restrictions may also contain variables. these variables are not allowed to send a user dialog for replacement.  
  
  

• Exit

  If none of the above type of relations is flexible enough, you should use a relation of type exit. To maintain this relation, one has to define the set of characteristics of the real-time InfoProvider, you are interested in the exit implementation. In addition, for the derivation case, the role of the characteristic has to be specified (source or target). For this scenario, we should use interface 'IF_RSPLS_CR_EXIT'. It is recommended to derive the exit class from the template class 'CL_RSPLS_CR_EXIT_BASE'. This class implements methods needed by the run time of the characteristic relationships, so you can focus on the implementation of the methods 'CHECK', 'DERIVE' and 'CREATE'. The template class contains also infrastructure to buffer previous calls and their results(see Note 1067433). You should study the comments in the three methods. Copy and de-comment (and adjust, if necessary) this code in your implementation.