Implementing Characteristic Relationships and Data Slices on the SAP HANA Database
If the generic types of characteristic relationships (attribute, hierarchy, DataStore) and data slices (selection) do not meet specific customer requirements, you can implement characteristic relationships and data slices of type Exit.
- Example 1: Let us assume that two previously separate sales organizations are being merged. Some of the products offered by one organization are also offered by the other, and these products originally had different product numbers in the two organizations. To allow standardized reporting over the entire product range, the two independent product catalogs are mapped to a cross-organizational product catalog using a mapping table. The mapping table has the following structure:
Table 1: Mapping Table Z_MAP_PRODUCT Region Regional_Prod_ID Product_ID R_01 RP_123 UP_123 R_02 RP_123 UP_321 ... ... In the different regional sales organizations, different products can have the same identification number. To ensure that there is a unique designation for a cross-regional comparison, these RP numbers must be converted into unique UP numbers. In our example, product RP_123 from region R_02 is given product ID UP_321.
Example 2: Let us assume that a company wants to implement a company-wide planning process for quarterly sales key figures at the product group level. Note that some regional sales organizations fix their plan data (for certain planning versions at least) on a certain date, while others modify their plan data if dictated by certain subsequent events.
This could mean for example that the plan data of Region A for the first quarter of the following year is fixed starting on 15th December of the current year, while Region B is allowed to modify its plan right through to the end of January on the basis of an unforeseen opportunity to increase its sales. To make this comprehensible, plan version V2 can be introduced, filled with the original plan data from plan version V1 and then opened for modifications from Region B only.
To implement the requirement in example1, you can define a characteristic relationship of type Exit, containing two relations (steps) with derivation: The first relation has the unique ID as its source characteristic and the original ID (in connection with the original sales organization) as its target characteristic, while the second relation is the same but the other way round. The original ID is therefore derived if the unique ID is planned. The unique ID is derived if the fields are reversed. The consistency of the two IDs is guaranteed if both characteristics are open for planning.
The requirement from example 2 is a typical case for a data slice of type Exit, defined on the characteristics Region, Plan Version and Quarter, with access to data that is edited outside of the BWsystem in a tool for the planning process, which stores its data in a database. To make this requirement more individual still, there should a number of administrators who are authorized to modify plan data at any time, in order to correct incorrect entries.
The typical ABAP exit implementation of these examples is direct, with the external data being read from the database using SQL commands from the ABAP runtime and - taking into account further information such as user name (sy-uname) - checking, deriving or creating records in the corresponding structure.
In BW, you can perform planning using internal database routines. In SAP HANA database, you can perform SAP HANA-optimized planning If you are using the Planning Applications Kit, we recommend also implementing the customer-specific exist functionality for characteristic relationships directly in the SAP HANA database using SQLScript. If you do not do this, you cannot take full advantage of the performance optimization possibilities: Plan data would then have to be submitted to the ABAP runtime and processed in individual records. While this would not be problematic for displaying data from analytical queries, as the data is available in the ABAP runtime anways, there can be a negative impact on performance if disaggregation (top-down distribution) or planning functions are executed on mass data. The entire data processing then takes place in the SAP HANA database. An ABAP implementation of the exit functionality would then prevent performance from being optimized.
Note the following however: Even if you implement SQLScript procedures for all methods that are used in characteristic relationships and data slices, the corresponding ABAP implementations must also be present, as the system triggers the ABAP equivalent in certain situations in order to avoid data transfer of individual records between the BW system in the SAP NetWeaver stack and the SAP HANA database.
If a SQLScript implementation is performed, the names of the implementing SQLScript procedures are determined in the ABAP runtime, and other parameters that are only available in the SAP NetWeaver stack (such as the user name in the sy-uname system field) are determined for subsequent use in the SQLScript implementation.
- IF_RSPLS_CR_EXIT : ABAP implementation of the characteristic relationships
- IF_RSPLS_DS_EXIT : ABAP implementation of the data slices
- IF_RSPLS_CR_EXIT_HDB : SQLScript implementation of the characteristic relationships
- IF_RSPLS_DS_EXIT_HDB : SQLScrip implementation of the data slices
The SAP HANA-specific interfaces have the following tasks:
- They serve as marking interfaces which show that the data will be processed in the SAP HANA database, regardless of the existence of characteristic relationships and data slices of type Exit.
- By providing information about the corresponding SQLScript implementations, these implementation should be called up if the data is processed in the SAP HANAdatabase, and a data transfer to the ABAP runtime environment can be avoided.