Virtual Characteristics without the use of BADI
Virtual Characteristics without the use of BADI:
I found a lot of “step by step” documentation on Virtual Characteristics and Key figures in SDN, however all of them pointed towards the use of BADI. I wanted to make use of this functionality but without the use of BADI, in a traditional way of coding in enhancements.
Scenario:
This documentation is for the purpose of basic understanding and I do not have a real time requirement at hand, so I’m creating a simple scenario of my own and realizing it with the use of a Virtual Characteristics. I plan to display the text for the characteristic plant in the report. The easier and best way would have been to make use of the display property for the characteristic 0PLANT in the BEx query. However as my pursuit was to understand Virtual Characteristics I will be realizing this through enhancements.
Step1: Create an info object which you would want to get populated virtually only during the query execution.
Step 2: Insert this characteristic into the infocube and multiprovider. Two things to note here would be as below:
i. Virtual Characteristic will not hold any data at any point of time, so these could be added into any of the dimension tables (except the Package, Time and Unit) and their contribution to the dimension table size is nil.
ii. Map the virtual characteristic to the infocube in characteristic identification of the multiprovider, else the activation of multiprovider will fail.
Infocube:
Multiprovider:
Step 3: Add the virtual characteristic in the intended query.
Running the query without the population logic will fill the Virtual Characteristicswith NOT ASSIGNED values:
Step 4: Coding
The coding part, unlike the other exits used in SAP BW enhancements, is written under different includes for Virtual Characteristics and key figures.
Enhancement: RSR00002
Components:
Top / Global declaration:
Function: ZXRSRTOP
Under global declarations variables related to the characteristics being used for the calculation and the virtual characteristics have to be declared. It is mandatory to ensure that the variable names being declared have the format G_POS_<INFOPROVIDER NAME>_<CHARACTERISTICS>.
EXIT: EXIT_SAPMRSRU_001
Include: ZXRSRU02
In the actual include the characteristics and their modes are passed. In the present example the characteristic 0PLANT is read from the info provider WOSC_MP and characteristic ZVCHAR_1 is populated into the report. Hence the mode should be “read” for 0PLANT and “no selection” for ZVCHAR_1. If more than one characteristics are read then all of them should have the value MODE populated with “Read”.
Initialization: EXIT_SAPMRSRU_999
Initialization exit is not to be changed or altered. It has to be left as it is.
Include: ZXRSRZZZ
Population Logic: The population logic will have to be written in the include ZXRSRZZZ.
Execution of the report:
We can find that all the plants have the text values being populated under the characteristic “Virtual Char”.
Navigating to all the exits:
In CMOD choose your project which holds the enhancement RSR00002 and select the components:
Choose any of the exits under the enhancement RSR00002 and double click.
In the exit click on the attributes tab:
Double click on the program name SAPLXRSR, this can also be accessed from transaction SE38 directly.
Hope this document is helpful if you choose to write a virtual characteristic or key figure without using BADI. Writing the individual codes inside an include function will insure your system against collapse of all the reports due to syntax errors in logic of a virtual char related to any info provider.
Really useful document. Thanks for sharing manohar.
Good presentation with screen shots.
Thank you, I'm encouraged. 🙂
Useful Information. Thanks for it. 🙂
Thank you, Hope it helps. 🙂
Thanks for sharing this blog... keep it up....
Thank you for the encouragement. 🙂
Very nicely explained docuemnt.
Although few questions :
1. Is this virtual char is not query specific ?
2. if not, will this code run every time when the query on top of this infoprovider ran
One of the pain point of using the traditional user exit code for virtual char is assignment of dynamic values generated during query execution, if your way of virtual char works...then this will be solution for that problem too.
Thanks for sharing the doc.
Thank-You.
Regards,
VB
Hi Vinod,
Thank you for the encouragement and the question. Your question just provides me an opportunity to add things which I had missed in the original post. Please find my answers for your questions below and hope this clarifies things.
1. Is this virtual char is not query specific ?
Even though the case statement checks for the infoprovider name before executing the virtual char logic, unless there is a virtual characteristic added in the query, this particular case statement is never even checked. To understand this further I created a copy query without the virtual characteristic on top of the same infoprovider, set up a break point in the virtual characteristic population logic and executed the query in debug mode, the query never ran into the virtual characteristic code.
Observed during debugging that the query with Virtual Characteristic will have the column USER EXIT in the internal table I_TH_SFC filled with a value 1, this further leads to the execution of the FORM USER_<INFOPROVIDER> which has the Virtual Characteristic logic. If this USER_EXIT is not filled with a value 1 or 2 then the FORM USER_<INFOPROVIDER> is not accessed at all:
2. if not, will this code run every time when the query on top of this infoprovider ran ?
No, the code will only get executed if the virtual characteristic is present in the query definition, else the query will never encounter this piece of logic.
This was the traditional method of Virtual Characteristic coding, which was then replaced with BADI.
Thanks,
Manohar. D