1 2 3 5 Previous Next

SAP Business Explorer (SAP BEx)

67 Posts

Hi Folks,


This is my first blog post in SDN and I want to share a simple Bex trick with you. Some of you might already know it.


while creating a BEx query, we often want to use the variables that are already available and ready for use. It is always recommened to re-use the objects instead of creating new ones. These re-usable objects may or may not be created by you or your collegues and you may want to confirm there behavior before you use them in your query. Sometimes its tricky to find which variable suits your requirements best, as you wouldn't know the purpose of all variables available for a certain characteristic. Here, you must note that for all the standard variables, SAP has mentioned their properties in description itself. However, if that not how your custom variable's description is mainatined as per given naming convetion then one needs to look at the properties of the variable to determine its behaviour.


The general way to check the Re-usability of a variable is to check the property of the variable and mostly its done by getting the required characteristic in the filter area, right click -> Restrict -> Variables. when the list of all variables on that characteristic is displayed then we select it and click on option 'Edit Variable' to see the properties.





Here, theres a chance of altering the Variable values unknowningly, which will lead to change the behaviour of the variable across all queries.


so simpler way to check the variable properties without going in change mode is as follows.


in the infoprovider pane, expand on dimensions to the characteristic that you need.

Expand the characteristic further and you will see below 3 options, which can be further expanded.


1. Attributes

2. Characteristic Value variables

3. Characteristic values


Expand node 'Characteristic Value variables' and you will be able to see list of all the variables for that characteristic.


click on any variable and you will be able to see it's properties in the properties pane on the right had side of your Bex Query designer.


variable Properties.JPG


Here, you will be able to see all the properties of your desired Variable with ease and also they not in edit mode.


One more ease is in terms of checking out multiple variables.



Hope this helps you.



-Swati Gawade.

Hi All,


Here is my first blog post ..

As SAP suggested few safety belt s-notes to avoid server(JAVA stack) crashes and improve the fastness of server.


Many end users will run the BEx reports without filter or will run entire year data, in this cases, server will go slower or will create issues(slowness) for  other end users when they try to execute reports in portal. For avoid those issues - go below


Set Bex report execution limitation in Portal:

By default Bex report execution cell  limit is 10,00,000. This has to set lower(based on client requirement. Example 650000 cells

Check default settings in below table.


Se16>> table “ RSADMIN “ execute.  (If don’t have any setting’s for



Diff b/w DEF and MAX:   DEF – when the user ran the report,  limitation is DEF number. If the user wants to extend the cell limit, end users can increase MAX limit by clicking SETTINGS option.


Set values:  se38 >> programe SAP_RSADMIN_MAINTAIN >> execute (F8) then provide the parameters


BICS_DA_RESULT_SET_LIMIT_MAX  = 650000 cells then OK. We can modify also my clicking modify if wants to change the cell limit.


Portal execution limit msg.jpg


entend limit in web.jpg



For more details see s-note: 1127156


Set BEx report download to Excel/PDF limitation in Portal:

These limitations enhance the above settings.

The memory consumption may be larger for the export to Excel or to PDF than for the execution in the Web; therefore, a lower value can be specified as the safety belt for Excel and PDF.



Execution default limit is 500000 and Max limit is 650000 in portal but download to excel/pdf is 300000 cells only if we set XLS and PDF setting in RSADMIN table.


Message when Excel limit cross.



After Open Excel:


excel mesg.jpg



Message when PDF limit cross.


pdf msg.jpg

For more details see s-note: 1622134



Set report execution limitation in BEx Analyzer:

We know BEx reports can execute in Web and Analyzer.

We discussed web Safety belt setting in above. Below Analyzer settings.


ANALYZER_LIMIT_DEF: The default number of maximum cells if no further setting is specified. The default number can be overwritten locally in BEx Analyzer for each data provider.

ANALYZER_LIMIT_MAX: the absolute maximum number of cells (see below). The maximum number cannot be overwritten in BEx Analyzer.



Message when cross limit:

Analyzer msg.jpg

For more details see s-note: 0001411545

How to select Max limit in Analyzer

After executing the report in Analyzer click the workbook settings as shown below for increasing the MAX limit. Increasing MAX limit is report specific.


Analyzer prop.jpg

Data Provider >> Properties



cell limit inc.jpg


Nageswara Polaka

How to perform integration tests of BEx Analyzer Workbooks and the corresponding queries?


We have all encountered this problem - new support packages are installed, changes are made to your BW production system and you are tasked with manually testing all your BEx workbooks to make sure that nothing is broken. This is a task which can easily take many hours or days and you can never guarantee that you did not overlook some query or query condition.



The solution


To help you in automating these integration testing tasks, there is a new product on the market: BExTest.



In BExTest, you can define a set of BI queries and accompaning filter conditions.

These test sets can then be executed with two different test methods:


  • The queryies are executed and then compared to a stored set of query result files.
  • They are executed against two different environments, e.g. your production and your testing environment to see if there are any differences between the results (that works of course only if the underlying data are the same).


Differences in the tests are highlighted and you get a verdict of Fail or Pass of your test run.

The queries are either executed by using the SAP webservice QUERY_VIEW_DATA or by controlling your BEx analyzer directly.


Because for every query the query response time is displayed, the tool is also suitable for repeated performance tests.


A command line client for windows is also available to run these integration tests automatically and to integrate BExTest to an existing automated test tool.


And there is a free evaluation version available, no registration needed!



What is your impression? Comments, questions and feature requests are welcome!

Purpose: Making data available from BW system to another system is common and regular activity.


When extracting data from Report or any other sources we may have negative values like 100- , while updating same data to flat files , we may have requirement inverse negative values from 200- to -200.


Here is the solution.


  1. Drag the report
  2. Add ROUTINE transformation
  3. Connect report to ROUTINE transformation
  4. Double click on ROUTINE transformation add required fields from Field List to Source Flds
  5. In TargetFlds Tab add one extra column along with normal amount filed. Here SIGN_AMT type 0txtlg



  1. Write code as like below in ROUTINE tab of ROUTINE transformation.


ls_source TYPE y_source_fields,
TYPE y_target_fields,

   res_amt(60) type c.



LOOP AT it_source INTO ls_source.

if ls_source-amount lt 0.
clear: res_amt.

res_amt = ls_source-amount * -1.
concatenate '-' res_amt into

CONDENSE ls_target-sign_amt NO-GAPS.


ls_target-sign_amt = ls_source-amount.
CONDENSE ls_target-sign_amt NO-GAPS.


    APPEND ls_target TO et_target.




  1. You have to assign remaining fields source to target
  2. Create target like Direct DSO or flat file and connect ROUTINE transformation to data target
  3. Execute APD




Thank you,


In many BI projects it is necessary to create a custom hierarchy either by combining several logically linked characteristics, or by creating a subset hierarchy (diluted hierarchy according to business rules).


One of the ways to do it is to use an enhancement RSAP0001 with EXIT_SAPLRSAP_004 component in ZXRSAU04 include.


Here, after CASE/WHEN “8DATA_SOURCE_NAME”, we can place an ABAP coding which builds a hierarchy according to our logic (sure, important prerequisite is to generate export data source in RSA1 for the characteristic).


If our coding is OK and the hierarchy was created successfully - well done.


But if something was wrong (dump, errors, erroneous hierarchy structure) we would want to debug the coding.


Setting any breakpoint in ZXRSAU04 (hard-coded BREAK-POINT, using checkpoint, setting external breakpoint) doesn’t bring us to debugger session.


In this article I will explain one of the ways to debug ZXRSAU04 exit.


First, go to SE38 and show the report SAPLRSAP.



Then, go to include LRSAPF06 to the line 475.

In the line 475 we can see customer function ‘004’ is called – that is a call to EXIT_SAPLRSAP_004, so put an external breakpoint here.



It is possible that line number may vary depending on your system version, so, if there is no such call in the line 475, just try to search it around.


Then execute an info package which loads a custom hierarchy from "8DATA_SOURCE_NAME" (debugger still doesn’t called).


After the info package load was finished go to SM37, find your job (should have prefix BIREQU_*), check the line, write in transaction line JDBG and press enter.


Debugger will appear.



Press F8 and you will get to your breakpoint.



Finally, press F5 will get you into your ABAP coding.


Nice debugging

Customer Exit OLAP Variables require ABAP coding which often can be found in a single INCLUDE program ZXRSRU01 as part of legacy Enhancement RSR00001 (a.k.a. Customer Exit EXIT_SAPLRRS0_001). Usually the INCLUDE program becomes bigger and bigger. Moreover, various people and/or project teams are working in the same place. You can imagine that it is dangerous because one programming or transport sequence mistake can destabilize the entire system. The solution is encapsulation of the coding of individual variables and you will need a framework to realize it.

In this blog I would like to discuss the latest enhancement technology to be used. Moreover, I will present an alternative approach for implementing a framework and the advantages it can offer you.

Please refer to my document Implementing Framework for Customer Exit OLAP Variables for a detailed step-by-step instruction for implementing the framework.

New Enhancement Spot

In SAP BW release 7.3 a new Enhancement Spot RSROA_VARIABLES_EXIT for Customer Exit OLAP Variables was introduced. It contains BAdI RSROA_VARIABLES_EXIT_BADI which can be impemented multiple times using an appropriate filter. It also contains a default implementation SMOD_EXIT_CALL to call program ZXRSRU01 as part of legacy Enhancement RSR00001.

I can recommend reading blog New BAdI RSROA_VARIABLES_EXIT_BADI (7.3) for more detailed information. Although it is a big improvement, I would like to suggest a more sophisticated approach to take the encapsulation to the next level.


My alternative approach indirectly uses standard SAP’s new BAdI RSROA_VARIABLES_EXIT_BADI. Instead of implementing this BAdI for every new variable, I introduce an intermediate layer: a new custom Enhancement Spot YBW_OLAP_VAR with 4 BAdIs (corresponding to the processing steps). The following 4 BAdI Definitions are available:


  • YBW_OLAP_VAR_BEFORE_POPUP - OLAP Customer Exit Variables - Before Popup (i_step = 1);
  • YBW_OLAP_VAR_AFTER_POPUP - OLAP Customer Exit Variables - After Popup (i_step = 2);
  • YBW_OLAP_VAR_VALIDATION - OLAP Customer Exit Variables - Validation (i_step = 3);
  • YBW_OLAP_VAR_AUTHORIZATION - OLAP Customer Exit Variables - Authorization (i_step = 0).


Only once BAdI RSROA_VARIABLES_EXIT_BADI will be implemented in a generic way. Here the respective BAdI implementation will be called dynamically according to the processing step and filter on variable name (except processing step 3 where I propose to filter on query name).


The main reason for implementing such a framework is achieving a safer system that is much better/easier to manage and support. The main advantages are in my opinion:


  • Every BAdI implementation is independent of all others, the encapsulated pieces of coding (residing in their own implementing class) can be maintained and transported independently and therefore eliminating risks which can destabilize the system;
  • The BAdI implementation is filtered on variable name (except processing step 3 where I propose to filter on query name), only one BAdI implementation will be processed every time;
  • The BAdI implementations are grouped by processing step (i.e. before pop-up, after pop-up, etc.) which increases transparency;
  • There is no need anymore to program a filter on variable name (CASE I_VNAM. etc.) and the processing step (e.g. IF I_STEP = 1.) in a nested way, the framework is taking care of that and contains appropriate error handling;
  • The Enhancement Spot technology is the latest and way forward technology for enhancing the system, it's using ABAP-OO programming technology and can optionally (not mandatory) be combined with the Switch Framework, you can find more information in the blog Simplify & structure your Enhancements by using Switchable Kernel BAdIs.


Most likely you are not working in an empty greenfield SAP BW system and you might find a considerable implemention effort in INCLUDE program ZXRSRU01 and/or any preceding framework (e.g. using Function Modules). If you decide to switch over to a new way-of-working, you will not be able to migrate all existing content in one go. Usually you will migrate gradually using a “phase in, phase out” approach. In other words, the legacy implementation and the new implementation have to live together in the same system for the time being.

This is possible but one “hidden” aspect will pop up as soon as you will create your first new implementation. The standard SAP BAdI implementation SMOD_EXIT_CALL will not be called anymore. This implementation is used to call INCLUDE program ZXRSRU01 as part of Enhancement RSR00001. Since this implementation is flagged as a “default implementation”, it will not be called as soon as any normal implementation is found.

The solution is creating another RSROA_VARIABLES_EXIT_BADI implementation which replaces the SMOD_EXIT_CALL implementation. It must be an exact copy of the standard SAP implementation so that it will call the legacy implementation in the same way.

You can find more information in blog Coexistence of BAdI RSROA_VARIABLES_EXIT_BADI and Customer-Exit EXIT_SAPLRRS0_001.


In this blog we discussed a new way of implementing Customer Exit OLAP Variables. The framework consists of an intermediate layer: a custom Enhancement Spot and 4 BAdIs which correspond to the processing step. The respective BAdI will be called dynamically using a single generic implementation of standard SAP BAdI RSROA_VARIABLES_EXIT_BADI. After an overview of the advantages of such an approach, we discussed the topic migration that is applicable in almost all cases.

If you are interested to know all about it, please refer to my document Implementing Framework for Customer Exit OLAP Variables. Here I will share with you detailed technical instructions how to implement such a framework.



I have ZGL_ACCNT with two compounding object 1 Chart of accounts 2 Logical Source System.


Created variable and using in BEx Report.


As per my requirement I need restrict F4 values for G/L Account variable specific to Chart of accounts.




P Table


GGL Account     Chart of Accounts          Source System

123                    A                                   ABC

123                    B                                   ABC



As per my requirement I need to show F4 values for chart of accounts 'A'.



So, implemented BADI using RSR_VARIABLE_F4_RESTRICT_BADI enhancement and written SELECT statement pull only where Char of accounts equal to 'A' and filling C_T_RANGE.


In C_T_RANGE I am able see only 123 and A record.(In Debug)


If I execute report and press F4 I am able see 123 A and 123 B also, I am wondering how 123 B is coming since i filled C_T_RANGE table with 123 A.


Finally I am not able to meet customer requirement ,


Here is the solution , you may found number of documents how to create(http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/4009b0a8-7adc-2e10-48b3-a111c8f407af?QuickLink=index&…) RSR_VARIABLE_F4_RESTRICT_BADI along with that we need add below piece of code to work as expected like 123 A as per above example, while working with compounding objects.

LOOP AT t_zgl_accnt INTO w_zgl_accnt.


           l_s_range-iobjnm = i_iobjnm. "ZGL_ACCNT

           l_s_range-sign = 'I'.

           l_s_range-option = 'EQ'.

           l_s_range-low = w_zgl_accnt-zgl_accnt.

           APPEND l_s_range TO c_t_range.


           l_s_range-iobjnm = 'ZCHRT_ACC' ." Char of accounts.

           l_s_range-sign = 'I'.

           l_s_range-option = 'EQ'.

           l_s_range-low = w_zgl_accnt-zchrt_acc.

           APPEND l_s_range TO c_t_range.


           l_s_range-iobjnm = 'ZSOSYS' ." Logical source system

           l_s_range-sign = 'I'.

           l_s_range-option = 'EQ'.

           l_s_range-low = w_zgl_accnt-ZSOSYS.

           APPEND l_s_range TO c_t_range.




Note: Need to add all compounding objects for C_T_RANGE, here chart of accounts and logical source system, adding to C_T_RANGE even though not required for user then only data will restrict and display when you press F4 as expected.


Thank you,






The original blog can be found here: ekessler.de


In this blog I would like to try some clarity in the processing of exit variables (EXIT_SAPLRRS0_001) to bring. The emerged with BW 7.30 BAdI RSROA_VARIABLES_EXIT_BADI has to deal with Exit variable not exactly simplified. In addition, the BAdI is unfortunately not documented in the SAP Help. Furthermore, it has now also changed 60 with the 7.4 domain RSCHAVL of CHAR to SSTRING.

All exit variables described here are used to the range of values of a report limit or expand the scope of permissions. In addition, the properties described here by Exit variables for Exit variables are to be used as part of the staging in DTP's or InfoPackages.

First, however, let us first of all deal with the different types of exit variables and their processing order.

1.1      Variablentypen

If I talk about exit variables I distinguish the following types of use:

  • Ready for input
  • Not ready for input
  • Use for authorization or staging

Ready for input variables come then to use if the user should be given the opportunity to influence the outcome report individually. The basic concept of an input-ready variables provides the user determines the value for the variable, and the value could not be changed by internal processing processes (customer exit). In section 1.3, "Overriding input values", I describe how this concept can be bypassed and the user-entered value of an input-ready variables in the customer exit can be overwritten.

Reday for input variables would be processed in I_STEP = 1 and I_STEP = 3, see Section 1.2 "processing steps (I_STEP)".

Not ready for input variables come then to use if the value is to be determined by rules. Here rules are often defined (implemented) in which the variable values for input-ready variables not depending on ready for input variables are determined.


Not ready for input variables would be processed in I_STEP = 1 and I_STEP = 2, see Section 1.2 "processing steps (I_STEP)".

Exit variables can also be used as part of authorization or to staging. At exit variables that must be considered are used here, that there is no interaction with a user is usually held. This means here is the processing order another.

Therefore, it must be ensured here that combinations as ready for input, mandatory and no default value (Default value) that cause a variable dialog is needed. Process of staging (DTP, InfoPackage) are usually scheduled processes in place that are executed by background-users.

Variables of usage authorization and staging are processed only in I_STEP = 0, see Section 1.2 "processing steps (I_STEP)".

1.2 Processing steps (I_STEP)

Exit variables depending on the usage and purpose in one or more steps, the I_STEP's processed. In the section "Dependencies for Variables of Type Customer Exit" the SAP Help the I_STEP's are briefly explained. The description in the online help is unfortunately incomplete and omitted entirely on examples. Therefore, I will briefly explain each step again using examples.

1.2.1 Authorization and Staging (I_STEP = 0)

In I_STEP = 0 exit variables are processed in the authorization and are used in staging. Figure 1.1 shows the use of an exit variables within the authorization. For the processing of exit variables within the entitlement only the I_STEP = 0 is traversed.



Figure 1.1: Exit variables within the authorization

Figure 1.2 shows the use of an exit variables in staging the example of selection within an InfoPackage.


Figure 1.2: Exit variables within the Staging


1.2.2 Initialization (I_STEP = 1)

The I_STEP = 1 is used for initialization of variables and exit is run separately for each exit variable. In the first stage the input-ready variables and then not ready for input variables are processed, see Figure 1.7. (The order could be differ, depends on the release (here BW 7.31 SP06)!)

Figure 1.3 shows a typical example of initializing an input-ready variables. The variable is initialized with the current month of last year.



Figure 1.3: Initialization


1.2.3 Derivation of variable values (I_STEP = 2)


The I_STEP = 2 is used to derive the values for the non-input-ready variables Exit. Again, the variables are processed separately analogous to I_STEP = 1. To derive the values for non-input-ready variables Exit all previously detected variable values in the parameter I_T_VAR_RANGE available. In section 1.3, "Overriding values entered" I describe as well as input-ready variables can be processed here.


Figure 1.4 shows how the current variable (examination of the variable name is not shown here), the value is derived based on the value of the variable ZTKE_MONTH.



Figure 1.4: Derivation of variables


1.2.4 validation (I_STEP = 3)


The I_STEP = 3 is used to validate all recorded variables. In I_STEP = 3 all previously recorded values in the parameter I_T_VAR_RANGE are testing and validation.


The I_T_VAR_RANGE parameter contains only the variables that contain a value. That is here are the only variables included:

  • value set by default value or
  • value set by an implementation (I_STEP = 1 or I_STEP = 3) or
  • user entered a value in the variable dialog


In I_STEP = 3 can not be changed, the values of the individual variables. It is possible to generate messages which would be display with the report-result or the variable dialog. In the event that the validation of the variables means that it makes no sense to run the report by throwing an exception (RAISE EXCEPTION) to prevent the report is run. The exception means that the user re-enters the values in the variables dialog.


Figure 1.5 shows the values for the two variables ZYEARFROM and ZYEARTO determined and then compared as in I_STEP = 3. If the FROM value greater than TO value of a message is issued and using the RAISE statement wrong_value prevents the report is run. The user has the opportunity to correct the value in the variable dialog.



Figure 1.5: Validation - Customer Exit


Figure 1.6 shows similar to the example in Figure 1.5, as in the object-oriented context to run the report can be prevented. The exception must be thrown here in the object-oriented context.



Figure 1.6: Validation - BAdI


1.3 Execution Order of I_STEP


Figure 1.7 shows the sequence in which the individual's I_STEP under a BEx reports. I distinguish the two phases:

  • Präparation (preparation phase) and
  • Validierung (Validation Phase)


The I_STEP's the preparation phase are run before the variable dialogue and I_STEP's validation phase will only go through if the values of the input-ready variables change in the variables dialog.



Figure 1.7: Processing of exit variables (I_STEP's)


That is the calling SAP standard processing procedure initially assumes that the user accepts the default values of the variables dialog without changing. In this case, the validation phase is not run again!


The process steps of the validation phase will only go through if the values in the dialog variables were changed by the user.


1.4 Processing of process variables Exit


With BW 7.3 the BAdI RSROA_VARIABLES_EXIT_BADI was introduced and presented to the customer exit EXIT_SAPLRRS0_001. The blog Coexistence of BAdI RSROA_VARIABLES_EXIT_BADI and Customer-Exit EXIT_SAPLRRS0_001 shows how the BAdI and the customer exit behave in a BW 7.3 system.


Figure 1.8 shows the individual processing blocks which are executed as part of the variable processing of exit variables.



Figure 1.8: Variables processing


The standard processing process first checks whether an active BAdI implementation by Type RSROA_VARIABLES_EXIT_BADI is available. As a filter value here, the technical name of the InfoObject is used on the exit variable based currently being processed. From a technical perspective, this test is performed within the function block RRS_VAR_EXIT via GET BADI.


The blog New BAdI RSROA_VARIABLES_EXIT_BADI describes the manufacturing process of the BAdI's in the details.


1.5 Overriding input values


The basic principle for input-ready variables was initially that user entered values can not be overwritten. An input-ready variable is not processed by default after the variable dialog as a single variable.


In I_STEP = 3, the variable can indeed be validated but not be changed. If it is determined during validation that the user entered value is not meaningful, in the I_STEP = 3 is a message that the user generated informed. In addition, an exception will be thrown. The exception ensures that the variables dialog appears again.


With the introduction of the parameter E_CHECK_AGAIN (see Note 1272242 - Renewed Variablenverprobung in I_STEP = 2), the concept was canceled. The parameter allows the developer to the user-entered value of an input-ready variables after the variable dialog in I_STEP = 2 to overwrite as needed.


As described in Section 1.2 "processing steps (I_STEP)" input-ready variables only in I_TEP = 1 and I_STEP = 3 processed, the value only in I_STEP = 1 changes (initialiesiert) can be. To ensure that an input-ready variables in I_STEP = 2 is again processed must be in I_STEP = 1 for this variable is the export parameters E_CHECK_AGAIN (E_CHECK_AGAIN = 'X') are set. If the parameter is set E_CHECK_AGAIN so this is ready for input variable is processed into a not ready for input variables in I_STEP = 2 analogous to the variables dialog.



This blog has been translated with Google Translate. the original blog can be found here: ekessler.de



In the block Use the reporting name in Exit-variables for authorization I have shown as the name of a report in the processing of exit variables in the context of the authorization may be used. In this block, I show what restrictions are taken into account.



The customer exit is traversed twice in the context of authorization. In the first pass the COMPID field is not yet available in the memory, and the call



returns for l_compid nothing. With the following code to ensure that all users of the report 'ZTKE_EXIT_VAR_AUTH' only the information on the country Germany (DE) is obtained.



   DATA: TYPE l_compid rszcompid,

         ls_range TYPE rrrangesid.


   IMPORT FROM MEMORY ID l_compid compid = 'COMPID'.


   CASE l_compid.


          ls_range-sign = 'I'.

          ls_range-opt = 'EQ'.

          ls_range-low = 'EN'.

          APPEND TO ls_range c_t_range.





The first call in I_STEP = 0 still determined not COMPID and thus no value for the processed here exit variable comes back as part of the authorization. In the second call, the COMPID can be determined and the permission is restricted to DE.


The first call has the consequence that we in the execution of the report, the warning

You do nothaveanalysisauthorizationforanychar. values​​of char. 0COUNTRY


get, see Figure 2.1. the authorization


By default, the variables are determined buffered values ​​in the context of the authorization check. To ensure that the values ​​can be evaluated in the second pass, the buffering in the RSECADMIN (see Figure 2.1) can be switched off. This is only possible system-wide!



Figure 2.1: Variablen Pufferung deaktivieren


After the buffer was switched off, we get no warnings regarding. The lack of analysis authorization more.

Unfortunately, there is no alternative to turning off the buffer. The analysis authorization concept clearly states that an analysis of authorization should be made ​​to the data and not the reporting object.

I am sure most of you have come across multiple issues during BEX workbook upgrade from 3.x to 7.x. Most of the customers use BEX workbooks pretty heavily. Some of the workbooks might have huge number of tabs. I have seen workbooks with 50+ tabs. Do you believe it? I am not kidding…


The BEX 7.x is based on .NET framework. A process can allocate a maximum of approximately 1.2 gigabytes (GB) in the .NET framework, regardless of the memory capacity in the front-end. This corresponds to approximately 750,000 data cells.


Following are some of the potential solutions, if you get the error “Client out of memory” in the upgraded workbook.


  1. Avoid refreshing the whole workbook. Refresh the queries that you require by enabling the following features. The following features are available only from a certain support package level.
    1. Allow refresh of single queries as a global setting in BEX
    2. Single data provider refresh functionality
  2. Split the workbook into multiple. It’s time to re-engineer and remove unwanted tabs.
  3. Covert BEX workbook into to a new tool called SAP BO Analysis for Office. It's a bigger decision. If you have plans to move to this tool in future , this a good time to move forward. One of the main prerequisites is that you have to be on SAP BW 7.01 SP11 or higher.


(1)  Net..Net…Plan to upgrade the back-end and front-end patches to leverage the above-mentioned features so that you can avoid memory related errors in the upgraded workbook.


In the next part, I am going to talk about the missing features in BEX 7.x workbook compared to BEX 3.x workbook and provide alternate options to overcome the same.

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!

This blog explains the use of BI commands to pass variable parameters to a BEx query.




It is quite usual scenario that we will have to open a BEx query from another Web Application Designer report or from any other portal. This will generally be implemented by having a button / URL pointing to the target query.


At times, it is also required that we have to pass the selections made in the landing page to the query so that the output will be filtered according to the values passed.




In order to achieve this, we can make use of the standard BI commands. One such command is SET_VARIABLES_STATE. This command is used to set the value of a variable which is used in BEx query.

Consider the following example, where in a query has a single value variable ZVAR_DATE created on InfoObject ZDATE. From the landing page, when the user clicks on the URL of the target query, it should pass the date value selected in the landing page to the above said query.

Below is the BI command which we need to append it to the actual query URL with required <variable name> and <variable value>.


In our case, we should replace <variable_name> with ZVAR_DATE and <variable_value> with 01.01.2014(or any other required date).

Similarly, it is possible to pass values for multiple variables by appending the query URL with the above command with ‘N’ number of times, where N= number of variable values that needs to be passed.

Thanks for reading this blog

Appreciate any suggestions/feedbacks!

I found very interesting report. It has no ABAP code at all. But it has a lot of text in there instead. Name of the report mentioned in here is RSR_BEXANALYZER_TEXT. The texts which it carries are related to BW’s BEx Analyzer. So basically all the texts used within this Windows based tool are stored with the report.


The texts are downloaded to user’s folder (%temp%\BW\COMMON\texts\ into the file e.g. BExTexts_EN.xml as per language used for login) when first logon to BEx Analyzer is performed. There are many SAP Notes which deal with the report. Mostly they deliver new or changed texts. So once you are not able to see new/changed text delivered by Note you may want to delete this folder or file to get refreshed texts to your workstation. See SAP Note “1732598 - Text Elements do not appear correctly in BEx Analyzer” for details.

I was curious to know how many texts the report has. So I prepared short ABAP report to count that. Here it is:

DATA: lt_tpool TYPE TABLE OF textpool,

LANGUAGE      = 'E'
TABLES         TPOOL             = lt_tpool
EXCEPTIONS  others          = 0.

DESCRIBE TABLE lt_tpool LINES lv_lin.
WRITE: / lv_lin

BTW: in my system based on SAP_BW 731 SP 0002 it has 827 texts.

So basically this is how I was playing tonight

The blog is cross posted on my personal blog.

This blog has been translated with Google Translate. the original blog can be found here: ekessler.de


As part of the authorization check for Reporting's permission relevant values​​, among other things with the help of exit variables can be determined. It happens that the requirements of the business require that to be included in the determination of the values ​​within the exit implementation of the report in which the data should be displayed. That if user A, he should look at the data on the X report be eligible for other values ​​than when he looks at the data on Z report.


The SAP BW authorization concept is the consideration of the report for the determination of the authorization-relevant data are available. For this reason, the name of the report is not handed over to the Cuxtomer exit interface. That is, the parameter is the report name usually provides the customer exit for exit variables in the processing of exit variables in the context of initial authorization.


In the following I want to show the behavior of an example. Furthermore, I would like to show an alternative way how to determine the name of the current report. The feature 0COUNTRY is filtered through an exit variable within the authorization check.


Figure 1.1 shows the definition of authorization ZTKE_AUTH01. To determine the appropriate values ​​the exit variable ZTKE_COUNTRY is used.



Figure 1.1: Definition of authorization


Figure 1.2 shows the use of the authorization in the role.



Figure 1.2: Definition of the role


In my example, I put the implementation not in the customer exit EXIT_SAPLRRS0_001 (Extension - RSR00001 BI: Enhancements for Global Variables in Reporting) to, but here I use the SAP BW 7.30 newly introduced BAdI RSROA_VARIABLES_EXIT_BADI.


For the new implementation of the BAdI RSROA_VARIABLES_EXIT_BADI I define as a filter IODBJNM = 0COUNTRY. The filter combination IOBJNM = '' we do not need here because of us I_STEP 3 = not interested. Only in I_STEP = 3, the parameter IOBJNM is not maintained. Exit variables that will come as part of the authorization to use = 0 processed in I_STEP and the parameter IOBJNM is maintained. Figure 1.3 shows the upper part of the filter combination used.



Figure 1.3: BAdI implementation


The lower panel in Figure 1.3 shows how the name of the report can be found. When processing in I_STEP 1, 2 and 3, the name of the report is on the COMPID field of the structure I_S_RKB1D. But in I_STEP = 0 the field is empty. With the help of the instruction:

IMPORT compid = l_compid FROM MEMORY ID 'COMPID'.

may the name of the report but are determined at runtime.

This blog has been translated with Google Translate. the original blog can be found here: ekessler.de

In the blog BAdI RSROA_VARIABLES_EXIT_BADI I have shown how exit variables using the BAdI RSROA_VARIABLES_EXIT_BADI can be processed.


Now In this blog I want to deal with the coexistence of BAdI and customer exit. First, you should always consider I need the new technical way the SAP me here provides or can I also use the (customer exit) life?

The customer exit for BEx variables has always been a good candidate for unstructured, extensive and historically (often hysterical) grown Coding. This is due to the fact that the exit (Include ZXRSRU01) usually from many different developers (often short-term purchased external consultants) will be processed with different programming views (functional or Objektorientier). Not infrequently, bring this their procedures and approaches to structuring the customer exit (call dynamic function blocks / methods, nesting Includes, ...) from other projects with a.

Another reason that makes a structuring of the customer exits so complicated is the interleaving of two case distinctions. Firstly, it must be distinguished according to the current process step, the I_STEP, and secondly, by the variable to be processed. This nested branching nearly impossible to exit structuring. For this reason, a lot of different methods have been developed for customers all over how to tackle the problem. The following methods can be found in practice (partly slightly modified):


  • Nested Includes
    The implementations of the individual departments are hereby outsourced to include and the include ZXRSRU01 only contains the individual department-specific includes.
  • Dynamic call of function modules
    For each variable, a function block is created. By means of a fixed naming convention can be derived from the name of the variable and thus dynamically invoked the name of the function block.
  • Dynamic invocation of methods of ABAP OO classes
    A method is created for each variable. By means of a fixed naming convention can be derived from the name of the variable and thus dynamically invoked the name of the method. Following the procedure for the function module. In this method the professional belonging together variables / methods are often summarized in a class. This makes the link between the variables with the appropriate method somewhat expensive but has the advantage that helper methods in the class can be reused easily.


Often customers have invested a lot of work into the development of such a concept and a migration towards the BAdI RSROA_VARIABLES_EXIT_BADI is made difficult by this method. It is therefore important that is initially clarified whether the use of the new BAdI also brings much added value that the migration effort worthwhile. To understand where the added value of using the BAdI's against the customer exit is I want to describe the use and the internal processing of exit variables and the interaction of the BAdI RSROA_VARIABLES_EXIT_BADI and the customer exit briefly here.


1.1 Internal processing of exit variables

To understand the internal processing process, it is first necessary to understand how the BAdI RSROA_VARIABLES_EXIT_BADI works. In the BAdI RSROA_VARIABLES_EXIT_BADI is a "new" BAdI. New BAdI are organized in enhancement spot. As known in the rule of the BAdI name, not the enhancement spots I always climb in through the BAdI Builder (transaction SE18) to edit the BAdI implementations. Furthermore, the BAdI RSROA_VARIABLES_EXIT_BADI is a filter-based BADI. As filter the BAdI uses the info object that forms the basis for the BEx variable. Figure 1.1 shows on the left the SAP code to handle variables. If it is in the current variables to be processed by an exit variable by means

      GET BADI variable_exit
          iobjnm = i_iobjnm.

tested whether an active BAdI implementation exists in the filter settings to the info object names match. That is the calling process within the SAP standard variable processing, checks whether the BAdI Framework is an active BAdI implementation for a filter value.
If an active BAdI implementation found PROCESS method of the class of the BAdI implementation is called:

      CALL BADI variable_exit->process
          i_vnam        = i_vnam
          i_vartyp      = i_vartyp
          i_iobjnm      = i_iobjnm
          i_s_cob_pro  = i_s_cob_pro
          i_s_rkb1d    = i_s_rkb1d
          i_periv      = i_periv
          i_t_var_range = i_t_var_range
          i_step        = i_step
          c_t_range    = e_t_range
          c_no_screen  = e_no_screen
          c_check_again = e_check_again
          c_s_customer  = c_s_customer.


The definition of the BAdIs RSROA_VARIABLES_EXIT_BADI allows more than one active implementation (Multible use) to form a filter value. Find the BAdI framework for a filter value several active implementations are all performed sequentially. Here, the order is indeterminate.



Figure 1.1: Processing of exit variables


1.2 Default implementation

In addition to the BAdI definition RSROA_VARIABLES_EXIT_BADI were running SAP in the standard of an active BAdI implementation (SMOD_EXIT_CALL). (= IOBJNM <>'' or IOBJNM'') of the filter value of this implementation is defined so that this implementation will always be used as BAdI active implementation.

The BAdI implementation SMOD_EXIT_CALL is characterized in Release 7:30 as the default implementation. As a result, this implementation is called only if no other active implementation is found. It must be noted that the filter value is taken into account when determining the active implementations.
I will illustrate this with a small example. As part of a migration project, we want to change the processing of the exit variables of the processing in the customer exit to the BAdI based variant. The migration project can not be implemented in a Big Bang but due to the scope. So that some variables in the customer exit and some in the BAdI be processed.
Variables and basic information items:




BAdI implementations for variables and the filter

  • SMOD_EXIT_CALL [default implementation]
    • Filter:  IOBJNM <>'' OR'' = IOBJNM
    • Filter: IOBJNM = '0 CALDAY 'OR IOBJNM =''
    • Processing takes place in the customer exit!


Query and variable




Query processing ZTKE_Q_DAY

First, we consider the processing in I_STEP = 1
When you call the query ZTKE_Q_DAY the standard SAP processing determines all active Implementation to the filter 0CALDAY that are not marked as a default implementation.

GET BADI variable_exit
    iobjnm = i_iobjnm.

Here the BAdI Framework will only find the BAdI implementation ZTKE_IMPL_CALDAY (filter  IOBJNM = '0 CALDAY ').
In I_STEP = 3 BAdI BAdI Implementation Framework only ZTKE_IMPL_CALDAY place again (filter  IOBJNM =''). In I_STEP = 3 all variables for validation (i_t_var_range) are available. I_vnam The parameters and i_iobjnm are I_STEP = 3 initial.


Query processing ZTKE_Q_YESTERDAY

Again, we first consider the processing in I_STEP = 1
When you call the query ZTKE_Q_YESTERDAY the standard SAP processing determines all active implementation to the filter 0CALDAY that are not marked as a default implementation.

GET BADI variable_exit
    iobjnm = i_iobjnm.

Here the BAdI Framework will only find the BAdI implementation ZTKE_IMPL_CALDAY (filter  IOBJNM = '0 CALDAY ')! But we want to take advantage of the processing in the customer exit. This can be the case if, as have, the processing for this variable is not yet migrated in our example. Below I show how this can be implemented.
In I_STEP = 3 BAdI BAdI Implementation Framework only ZTKE_IMPL_CALDAY place again (filter  IOBJNM =''). Here the same applies as I_STEP = 1


Query processing ZTKE_Q_WEEK


Again, we first consider the processing in I_STEP = 1 When you call the query ZTKE_Q_WEEK the standard SAP processing determines all active implementation to the filter 0CALWEEK that are not marked as a default implementation.

GET BADI variable_exit
    iobjnm = i_iobjnm.

Here you will find the BAdI Framework no active implementation that is not marked as a default implementation!
The default implementation SMOD_EXIT_CALL is used as the active implementation.
In I_STEP = 3 BAdI BAdI Implementation Framework finds the ZTKE_IMPL_CALDAY (filter  IOBJNM ='').


1.3 Results


The following points should be noted:


  • In the various implementations of the I_STEP must be checked and the current variable (Relocated CASE)
    In the example above, the implementation ZTKE_IMPL_CALDAY used as the active implementation for all variables based on the info object 0CALDAY. That within the implementation must be distinguished according to the currently processed variable analogous to the customer exit a case distinction. The case distinction is here implemented instruction usually with the help of CASE.


  • I_STEP 0,1,2 and the special case I_STEP = 3
    Similar to the variable name must be distinguished within the implementations of the I_STEP. The I_STEP = 3 provides as a special case here. In I_STEP = 3 all variables are testing and validation, and the parameters I_VNAM and I_IOBJNM are initial. That a case distinction according to the variable name is not possible here. When processing the I_STEP = 3 all BAdI implementations are called as active implementations in the filter IOBJNM = contain''. That it must be here a distinction according to the current query to be processed. The current query can be determined from the component COMPID the structure I_S_RKB1D.


  • With Release 7:30 it is not possible without further a BAdI implementation and parallel to use the customer exit.


  • From Release 7:40 SPS09 and BAdI customer exit can be used in parallel without further notice. For 7.40er systems from SPS09 the Note 2036773 needs to be implemented


2 Coexistence with Release 7:30

In a SAP BW / .3 system of BAdI RSROA_VARIABLES_EXIT_BADI and the customer exit EXIT_SAPLRRS0_001 can not be operated in parallel without further ado, see example above. To ensure that the customer exit is always run, it is necessary to set up your own BAdI implementation to this. For the BAdI implementation, the filter values are defined analogously to the SAP standard implementation.

Figure 2.1 shows a BAdI implementation to call the customer exits.


Figure 2.1: BAdI definition for Customer Exit


Figure 2.2 shows the filter values of the BAdI implementation.

Figure 2.2: Filter values of the BAdI implementation

Listing 2.1 shows the implementation of the PROCESS method of BAdI implementation. Within the implementation of the call to the customer exit is passed. It should be noted that it must be ensured not be deleted that may have already been determined value. The parameter E_T_RANGE of the function block is a pure export parameters, ie if the parameter C_T_RANGE was already filled in another BAdI implementation, this value must be saved before calling the exit.

METHOD if_rsroa_variables_exit_badi~process.

  DATA: lt_range_tmp TYPE rsr_t_rangesid.

  IF c_t_range IS NOT INITIAL.
    APPEND LINES OF c_t_range TO lt_range_tmp.

      i_vnam        = i_vnam
      i_vartyp      = i_vartyp
      i_iobjnm      = i_iobjnm
      i_s_cob_pro  = i_s_cob_pro
      i_s_rkb1d    = i_s_rkb1d
      i_periv      = i_periv
      i_t_var_range = i_t_var_range
      i_step        = i_step
      e_t_range    = c_t_range
*    E_MEEHT      =
*    E_MEFAC      =
*    E_WAERS      =
*    E_WHFAC      =
      e_no_screen  = c_no_screen
      e_check_again = c_check_again
      c_s_customer  = c_s_customer.

  IF lt_range_tmp IS NOT INITIAL.
    APPEND LINES OF lt_range_tmp TO c_t_range.


Listing 2.1: Implementation of the PROCESS method


Filter Blog

By author:
By date:
By tag: