Inversion Routines – Making use of Set Objects
In this blog, we will discuss how to make use built-in transformation capabilities of the multidimensional set objects to transform selections from the outbound universe to the inbound universe (i.e. from query to the source).
If we consider a VirtualProvider, there is always a transformation involved in the data flow between source and the target. In order to make the selection conditions of the query to be passed to the source, we need to make use of inverse transformation (especially if the transformation consists of expert /start/end routines, we need to write a corresponding Inverse routine to make sure that the selections are forwarded to the source).
Note: Even if the selection conditions are not forwarded to the source completely, there will not be any inconsistency, i.e. you will not miss even a single record which satisfies the selection criteria. At most, this case will bring all the records from the source (this may lead to memory overflow causing a dump). The inverse routine should be implemented for direct access or in the case of Report-Report Interface for better performance.
Coming back to our topic, the selections passed from the query are converted into a multidimensional set object. These objects can be represented as instances of ABAP class CL_RSMDS_SET. This can gain a considerable performance advantage over the range table representation (of course this will substantially reduce the coding efforts).
For more information about the import and export parameter details of the Inverse routines, please check the link.
Coming to the implementation part of the Set Objects, the coding logic is as follows.(please check the image below).
If all values are requested from outbound structure, request all values from inbound structure as a multidimensional set object. Mark the result as an exact inversion.
Create a mapping table for fields (dimensions) of type RSMDS_S_DIMMAPPING. We maintain fields of outbound and inbound structure in this table.
In the try block, we use built-in transformation capabilities of set objects.
If some exceptions happen for e.g. if a dimension is unknown, to be on the safe side, we request all the values from the source system (logic in catch block).
The query is not at all affected with any data inconsistency due to the simplification or enhancement of selection conditions. In all cases in which the selection conditions of the query are simplified in the transformation, the system never reads fewer data records from the source than are necessary to fulfill the selection condition on the VirtualProvider. Excess data records are filtered out in the analytic engine after the transformation.
Click here for more details on implementation of inversion routine.
In the next blog we will discuss, “how to trace the missing selections.”