The SAP BW Concatenate Characteristic technique increases the number of effective key fields that are being stored in the DataStore without actually changing the number of real DataStore key fields being used. It is often used to store Budget and Plan data in a DataStore when normally you would be forced to use a ‘BW Staging Cube’ in full load mode because the DataSource is not delta enabled and all characteristic, unit and currency InfoObjects form the records full unique key.
“the concatenation characteristic technique stores
multiple characteristic values in a single InfoObject”
Expressed another way; the full unique key is all record fields except the key figures. This identifies a record as being different from the other records.
This can easily result in more than 30 InfoObjects needing to be stored within the DataStores maximum of 16 key fields. Officially you could spend time and review the record to identify the real, true key fields from the businesses point of view and cross your fingers this ends up being within the DataStore 16 key fields limitation. For Example: A cost centre budget DataSet. Any cost centre attributes in the record will most likely be the real cost centre attribute that can be modelled from master data and effectively dropped from the transaction data record.
The concern with doing this is if you get the data analysis wrong or the master data relationship with the attribute changes over time then the budget will be re-allocated when it should not have been. There is also the risk that when activating data in the DataStore, records could be lost as the unique key you choose was not enough and records overwrote each other.
For plan, budget, forecast and target DataSets; a lot of BW developers, system administrator and data modelers will lean on the side of caution and use the full unique key of the record. If it’s not a key figure then it is considered to be part of the full unique key. We are now back to the dilemma of the DataStore being unable to store the full unique key using a straight 1 to 1 mapping of 1 key field is one InfoObject.
“the simplest concatenated characteristic has
no attributes, no texts, no hierarchies and no SIDs”
The concatenated characteristic utilises a fixed width storage format where up to 60 characters can be stored in a single InfoObject. They are generally used only in the staging and transformation layer of the DataModel as there is no real benefit of using them in the warehouse, reporting or consumption layers of the DataModel.
There is no need to have any attributes on this concatenation characteristic, as its primary use is the base characteristic value itself, which is already in the transaction data record. Since the concatenation characteristic is being used in DataStores that should have the SID generation turned off, will not be in end user reporting queries and hence will not need a drop down value selection list (F4) of the master data.
You can minimise the ETL impact by defining the characteristic and never load any master data into it.
Now consider adding the ETL to populate the concatenation characteristic with the individual attribute values related to the base characteristic value. What benefit does this really achieve? Not much. The recommended approach is to use the concatenation characteristic as a DataStore key field and still have the individual characteristics as DataStore data fields and never involve attributes. This allows for easier reconciliation and transformation mapping of the data.
Essentially you use the concatenation characteristic as a storage mechanism to force the records full unique key into the 16 available DataStore key fields while still using the individual characteristics that are the DataStore data fields for the business logic.
When writing the ABAP code to create the concatenated value you need to honour several aspects of each characteristics definition:
- The characteristic conversion exit for input is executed;
- The data is stored in the characteristics internal format;
- The data stored at the correct offset for the full width of the internal format;
- Force an upper case conversion if lower case is not allowed.
It might be tempting to put this logic into the routine in the characteristic definition itself. Don’t. This is not the place for it because the memory locations of the other fields in the record are not known by the concatenation characteristic routine. The related fields of the transaction data record that make up the concatenation characteristic value are only known when processing the transaction data record itself.
This in turn leads to a possible code maintenance problem where we might want to use the same code more than once. A good coding practice is to maintain it once and then use it everywhere. The solution is to create a program include that contains the code to fill in the concatenation characteristic value from a structure and then use that program include in all the BW routines where it is needed.
Is there a staging cube in your system? Yes. Re-factor the Data Model to use a DataStore instead.