Child pages
  • BW Characteristics with Conversion Routines
Skip to end of metadata
Go to start of metadata

Overview

Conversion routines are used in the BW system so that the characteristic values (key) of an InfoObject can be displayed in a different format(e.g. in a certain frontend for a BW query) to how they are stored in the database. There are standard conversion routines which are delivered by SAP like ALPHA, MATNR or WBSEL(see online documentation below). When such routines are used it is important to know that there are no automatic checks regarding the correct internal values. The only exception is the routine ALPHA which is checked when data is loaded into a BW Provider, see note 1935630.

Simple Examples:

CHAR1 has length 4 and uses ALPHA

  • correct internal value 0007 (external value = 7)
  • incorrect internal value 7 (external value = 7)

In case a data record contains the internal value 7 the loading process will terminate with a corresponding error message(see example below).

CHAR2(like 0material) has length 18 and uses MATN1

  • correct internal value 000000000000000007 (external value = 7)
  • incorrect internal value 7 (external value = 7)

In case a data record contains the internal value 7, the loading process will finish successfully and write the internal value 7 into the SID table. Hence, it might e.g. happen that the SID table then contains both, the internal value 000000000000000007 and 7 which both have the same external value '7'! 

Such inconsistent values can cause various issues when running BW queries and they cannot be repaired automatically. You need to delete the transaction data which contains the wrong internal values before you can delete the affected SIDs(and master data). Please proceed as follows(details can be found in the example below):

  • Find out which SIDs refer to incorrect internal values. You can use transaction RSRV and/or directly check the SID table if you already know suspicious values.
  • If you want to check how exactly a certain conversion routine works you can use the functions CONVERSION_EXIT_<routine name>_OUTPUT and CONVERSION_EXIT_<routine name>_INPUT.
  • Check in which InfoProvider this SID(corresponding value) is used and delete the transaction data. You can run report RSDMDD_DELETE_BATCH in simulation mode and check then the where-used-list in the log. Single SIDs can also be checked by using method CL_RSMD_UC_UTILITIES=>UC_ONLY_EXECUTE_CHECK.
  • You can use the feature Selective Deletion or delete the corresponding request  if still possible(when not activated/compressed).
  • Afterwards it is possible to delete the incorrect internal values from the master data and SID tables by running report RSDMDD_DELETE_BATCH(notes 1705824 and 1661251).
  • Then the deleted transaction data can be loaded again. However, you need to assure now that correct internal values are used!

Comments

  • In the past the function RSDDCVER_USAGE_MDATA_BY_SID was executed to get a where-used-list, however, it isn't supported any longer(it does not exist at all on a BW/4Hana system). Instead the method CL_RSMD_UC_UTILITIES=>UC_ONLY_EXECUTE_CHECK can be used.
  • There are conversion routines like PROJ(and WBSEL) where the external description is stored in an attribute of the characteristic(e.g. characteristic 0PROJECT_EX exists as an attributes of InfoObject 0PROJECT). Hence, the conversion routines 'CONVERSION_EXIT_PROJ_INPUT/OUTPUT' access the master data tables in order to get the corresponding internal/external values.
SAP Online Documentation
SAP Notes
  • 1705824  Old master data deletion is obsolete
  • 1661251  SP31:New Master data deletion - Enhancements
  • 1935630  Permitted characteristic values and conversion exit

Example(BW75 System based on Hana)

Characteristic With Conversion Routine MATN1

We load data from an InfoCube to an ADSO(technical name STPE_ADS3) where the transformation has a end routine containing some code lines which generate an incorrect internal value:

The corresponding DTP can be executed without error messages:

Afterwards the SID table contains a incorrect internal value without leading zeros:

When we switch on the usage of the conversion routine in SE16 we can see that there are two internal values with the same external value!

As already mentioned above, such inconsistent values can cause various issues when running BW queries. Before we take a look at a test query we use Transaction RSRV to check the characteristic values.

If you need to better understand how exactly a certain conversion exit works, you can use the functions CONVERSION_EXIT_<routine name>_OUTPUT and CONVERSION_EXIT_<routine name>_INPUT. In our case the functions have the names CONVERSION_EXIT_MATN1_OUTPUT and CONVERSION_EXIT_MATN1_INPUT:

Transaction RSRV

Transaction RSRV detects such incorrect values and displays the error message RSRV200 along with the affected SID number:

Checking a Query in RSRT

Our sample query is very simple and has a input-ready variable based on the characteristic STPEMATNR. When we run the query in RSRT and leave the variable empty, the following result is displayed:

We can see the value 4 two times(since technically these are two different values) which is already very confusing for users. When we know call the variable screen and enter the value 4, only one row is dipsplayed in the result set:

This is the value 4 with the correct internal value(see above). However, when you use the function 'select filter values' in the navigation pane, you can distinguish between these two different '4's and e.g. set a filter only for the 4 with the incorrect internal format:

So, it is now clear that such values cause inconsistent and very confusing query results 

How to Repair this Inconsistency

First we need to check in which InfoProvider the wrong SID number is used/posted. Since we already now the SID and it is only one , we use the method CL_RSMD_UC_UTILITIES=>UC_ONLY_EXECUTE_CHECK to find out the affected InfoProviders(in the past the function RSDDCVER_USAGE_MDATA_BY_SID was used in this context but it isn't supported any longer - it does not exist at all on a BW/4Hana system):

I_T_CHVL:

So, the  SID 6 is only used in the ADSO STPE_ADS3. Hence we take a look at the Inbound table(since the request isn't yet active) of this ADSO where we can also see the affected request which has to be deleted:

It is also possible to use the report RSDMDD_DELETE_BATCH in simulation mode and check then the where-used-list in the log(transaction SLG1).

Log(SLG1):

Now we can delete the affected request from the ADSO and afterwards the SID 6 with report RSDMDD_DELETE_BATCH.




  • No labels