Skip to Content
Author's profile photo Shravan Marathe

Run time population of fields in BEx Query

In this blog I am going to demonstrate on how the fields can be populated during run time in BEx query.


A firm has confidential data such as the price of a material which is yet to be released to market, which the firm does not want to store it in a data store object or an InfoCube straightaway. Instead they will store it in an encrypted format in a database table. But certain users such as Product Managers or Board Members should be able to view the decrypted prices in the final BEx query. In this case, it is required to populate the decrypted values during run time of a BEx query.


We can make use of classic BADI implementation on RSR_OLAP_BADI. This BADI basically gets executed for the specified characteristics / KeyFigures and populate the values during run time based on the code written for the implementation.

To do this, we need to have virtual charactristics/KeyFigures present in the underlying InfoProvider i.e. say we already have the decrypted value stored in the InfoObject ZDEC_VALUE of an InfoProvider, then we need to create a dummy Key Figure say ZENC_VALUE on the same InfoProvider.

Once the above step is complete, then create a custom implementation on RSR_OLAP_BADI which will have three pre-defined methods i.e. INITIALIZE, DEFINE and COMPUTE. It is mandatory to define and initialize the fields in INITIALIZE and DEFINE methods in order to use them in COMPUTE method. In the COMPUTE method we can have the logic to decrypt the values and assign it to the dummy virtual characteristic/KeyFigure created.

By doing this, everytime when the queries having the InfObjects specified in the BADI will undergo the business logic and the fields are populated accordingly.

It is possible to create new custom methods other than the pre-defined methods.


It is also possible to restrict the BADI to run it only for the queries built over a particular InfoProvider or a particular query alone. This can be handled by using a TVARVC variable by having list of queries stored in it and having a lookup to this before going to the actual logic in COMPUTE method. The InfoProvider restriction can be added straightaway in FILTERS area of BADI implementation.

Where as sample piece of code for INITIALIZE method can be copied from the example class CL_EXM_IM_RSR_OLAP_BAPI and this can be changed based on the requirement.

Thanks for reading this blog.

Appreciate any comments/feedbacks!

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Harish Allachervu
      Harish Allachervu

      handy snippet about bex query design.... 🙂

      you could have added screenshots of the steps in this whole scenario, so that reader will grasp very easily and remember for long time 😉

      it's my personnel opinion!!

      Thanks & Regards,