SAP Community - BW Business Explorer (SAP BEx)

BEx 3.x/7.x to AfO 2.x Automated Mass Conversion Tool v2.2

2020-11-18T08:41:41+01:00

Introduction

Hello everyone, I am back again with a very interesting topic, the Automated Mass Conversion Tool v2.2, it will be my pleasure to walk you through the newest features that I added to the previous version that was firstly introduced by my colleague bhargavmalsani.dayanand in this blog.

What is the Mass Conversion Tool?

The Mass Conversion Tool was internally developed by SAP to accelerate and facilitate the conversion process rom BEx (Analyzer) Workbooks to Analysis for Microsoft Office Workbooks.

The Automated Mass Conversion Tool is 6x to 8x faster than the manual conversion method, conversion of 100 Workbooks take around 5-6 Minutes, compared to at least 30 seconds per one workbook in case of manual conversion.

This is a screenshot for a real run on 100 Workbooks that were converted in 5:44 minutes, after successfully setting up the tool on the customer's environment:

When is the conversion process mandatory?

If you are migrating to BW/4HANA, as BEx Analyzer will not be able to access the BW/4HANA system.

If you are upgrading your Microsoft Office landscape to 64bit Edition, as BEx Analyzer only runs on Excel 32bit Edition

More information about the maintenance strategy for BW BEx Explorer can be found in note number 1322923.

New Features:

Rename workbooks after conversion

Standardize the naming convention of the converted workbooks, by simply providing a CSV file containing the Workbook ID, Destination Role ID, and New Workbook ID.

WID	Role	WBName
3FAFDUZNSGVNIHLO63YTUX9HA	ZE_ROLE1	AFOWB_1
3VYKQU1PO9DKICADNOPQN0G70	ZE_ROLE2	AFOWB_2
1JW9S8WCDXYZ277J3NDNAVHH8	ZE_ROLE3	AFOWB_3

Workbook IDs after Conversion

Converted workbooks can now be opened using 64bit Excel:

This was a limitation even in the manual conversion method, when a workbook is converted the leftover code from BEx Analyzer remains, in order to surpass it, the 3 default VBA modules must be manually deleted, or "Declare PtrSafe" must be written before each Sub.

In the new version of the tool, you do not have to worry about that, you are just one checkbox away from solving it.

Saving to multiple different roles:

This feature allows the converted workbooks to be saved to multiple different workbooks, they can be their original roles or entirely new ones.

For example WB1 to Role1, WB2 to Role2, and WB3 to WB3, a csv can be provided to identify the workbook technical ID and destination role, as shown below:

WID	Role
3FAFDUZNSGVNIHLO63YTUX9HA	ZE_ROLE1
3VYKQU1PO9DKICADNOPQN0G70	ZE_ROLE2
1JW9S8WCDXYZ277J3NDNAVHH8	ZE_ROLE3

Workbook branding options:

Gain advantage of the conversion service by rebranding or standardizing the layout of your old workbooks, the following options are now available to be applied to the converted workbooks:

A screenshot for a workbook before conversion:

The workbook had 2 images, the filter and information buttons were clicked, there was no descriptive title, there were the Author and Status of Data info fields in the range below the title.
This is the same workbook after conversion using the options in Advanced Conversion Settings in the first screenshot:

The images were removed and replaced by SAP logo and the orange line.

The 3 buttons from Analyzer were removed, whether they were opened or closed.

A descriptive title was captured from the workbook description, centralized and added in merged cells.

The whole workbook was colored white.

The old info field was removed and replaced by Query Created By, Data Source Name, Last Date Update and Key Date were added, using a different font for the title and the value.

Rows between 1:4 were deleted.

Rows between 1:5 were inserted to be populated by the info fields.

Note:

The table styling cannot be applied in this version, it will always reset to the AfO default blue theme.

Workbook styling will be applied to the main sheet, not all of them, this is a current limitation that I will be working on.

Conclusion:

The new version is not only about conversion, it offers an opportunity to:

Make all of the converted workbooks 64bit Compatible.

Redistribution of the workbooks among different roles.

Standardize workbooks format or entirely change the design.

Standardize the naming convention for the converted workbooks.

This service is available for both Max Attention(Premium Enagaments) and Professional Services customers, if you would like to request it or find out more about it please contact your Engagement Architect, Technical Quality Manager, Account Manager or you can reach out to the contacts below.

This blog post will be updated whenever a new feature is rolled out.

Lastly I would like to give well deserved credit to my colleague mike.luang-khot1 who played a major role in the development of the first version of the tool, and also played a crucial part in this version by thoroughly explaining the tool's primary code to me, without his help these features would not have been possible.

SAP Stakeholders can reach out to the following contacts based on their region:

CoE EMEA Team:

CoE EMEA Analytics Planning and Consolidation

CoE North America Team:

CoE NA Analytics

CoE Ireland Team:

CoE Ireland Analytics and AI

Thank you for reading this, I hope it was interesting and comprehensive enough, please do not hesitate to ask any questions, provide feedback, or suggest any further enhancements.

SAP Data Warehouse Cloud: Consume SAP BW based Queries

2020-11-20T09:39:43+01:00

Introduction

SAP Data Warehouse Cloud (DWC) is designed to extend the existing Enterprise Data Warehouse into the Cloud under the lead of the LoB users. Due to its easy to use design, look and feel, Data Harmonization tasks can be achieved directly within your LoB Departments with very little IT involvment.

When we talk about SAP BW Data Model and exposing logic out of SAP BW we talk about BEx/BW Queries. These Queries will be used to expose a Data set to the Front- End such as SAP Analytics Cloud for Data visualization.

We can re- use these Queries in order to expose this logic to DWC aswell. In that case you can secure your TCO that you invested in the past into your SAP BW Data Model.

Versioning

Document Version	0.1
Document Date	19.11.2020
DWC Version	2020.23.56

Prerequisites

In order to follow this Blog you need the following prerequisites fulfilled:

You have meet the DWC System requirements

Your DWC Tenant is connected to your SAP BW

You are using the SAP ABAP connection Tile

You have a BEx/BW Query

None of the limitations apply
- SAP BW on HANA Limitations
- SAP BW/4HANA Limitations

Consume SAP BW based Queries

In order to consume your Queries within DWC, we have to mark your Query as an InfoProvider. Without doing this, the Query wont show up within DWC. So the general Overview looks like the following:

Identify your Query

Mark the Query as InfoProvider within SAP BW

Use it in your Graphical View

Identify your Query

In our case i created a simple Query for demoing. My Query is called CP02Q01_SALOVE and the definition looks like the following:

Not a beauty, but does the trick.

Mark the Query as InfoProvider

This part is mission critical. If we do not mark the Query as InfoProvider, the view out of DWC looks as follows:

Mark your Query as InfoProvider

Log- On to your SAP BW

Launch Transaction RSRT

Select your Query

Hit the Properties button

Select Query is used as InfoProviderPlease remark: If you get a notification telling you that your Query cannot be used as an InfoProvider, please check the limitations that apply when using a Query as an InfoProvider.

As of now, we can see our Query within DWC:

Use it in your Grapical View

At the end we are now finally able to use the Query within a Graphical View. In the first hand we import it:

Whereas afterwards it is ready to use within our Graphical View:

Further Information

If you seek for further DWC Information material, hit the DWC Product Page.

You need more help during your Implementation? Check the Product documentation for helpful implementation Guides.

Want to know whats coming up in the DWC Universe? Check the DWC Roadmap.

Regards
-Seb.

Enabling cold store data access using view for external access (The ‘8’ View) for aDSOs in BW reports with mixed modelling scenario

2021-04-15T14:10:59+02:00

Greetings !

As promised in my earlier blog post, in this article I will be explaining the possibilities of using the view for external access or the external SAP HANA SQL view for aDSOs or the generated '8' view of aDSOs. The main idea is to gain optimum performance avoiding unnecessary access to cold storage when only Hot data is requested. For details about the '8' view please have a look into the above mentioned blog post link.

For this illustration, I will use the same aDSO used for the earlier blog post : SALESADSO, which has some sample sales data for calendar year 2019 & 2020. Executing suitable DTO rule, I have moved all the data residing in partitions covering calendar year 2019 to external cold storage (IQ). So, the view for external access for the aDSO : /BIC/ASALESADSO8, has the COLD_STORE_FLAG column populated as : 'X' for all data belonging to year 2019 & ' ' for all data belonging to year 2020.

Now let's think about consuming this view into a BW data model using mixed modelling architecture in such a way that unless a request has been made to cold store data, it should not access the cold store causing unnecessary performance penalty.

Meaning, we will build a calculation view based on the '8' view & then consume the calculation view into a composite provider & finally a report on top of the composite provider. The purpose is to explore how can we determine the access to cold store data exposing the flag as a consumer of single value input variable in the application layer of reporting.

Now the challenge is that if we simply expose the field COLD_STORE_FLAG as a variable in the report through the HCPR, user can select either ' ' (blank or empty string, no whitespace) or 'X' if we build a single value input variable in frontend, which is the goal here, we could potentially have a multi input variable which can request both the data. But I will try to explain how to build a solution using single value input variable around this flag. The challenge with this approach is if a user, for example, requests data from December 2019 to February 2020 in report, & selects based on the flag values available with just the field exposed as it is, user can see either 2019 year's data (if user selects COLD_STORE_FLAG = 'X') or 2020 year's data (if selected ' '). But with selection of 'X' we need to secure that the user is able to access both 2019 & 2020 years' data. This situation can be handled in multiple ways :

By using multiple input variable where user needs to select both the values for COLD_STORE_FLAG in such situations.

By handling it using an input parameter & necessary filter criteria in calculation view.

By using a step 2 exit variable where for user input 'X' against flag value, the step 2 variable can pass '*' (all) as a filter to COLD_STORE_FLAG column.

I will explain the second approach in this blog post, which is handling of the flag completely in calculation view level. I would explaiin two ways of doing it :

Approach#1 : using single input parameter :

First step is to consume the view in a calculation view in below way:

I have made 2 nodes out of the view called HDB & HDB_IQ. In HDB I have placed a filter on COLD_STORE_FLAG = ''. So, it contains only data from the hot data store (Active Data Table of aDSO), while the other node has no filter, containing all the data combining hot & cold storage.

In the node Union_1, I have created a new target column : CS_FLAG, with custom constant mapping of the node values as ' ' (HDB) and 'X' (HDB_IQ). This way the pruning is secured.

I have created an input parameter called IP_CS_FLAG (Access Cold Store) as optional single input of type VARCHAR & length 1. This is to pushdown the filter with flag value passed from application layer on access of the data tiering storage by using a filter expression.

If no value is passed through it, the takes the unassigned value, thus only requesting the hot store data avoiding the extra traffic to access the external cold storage.

Coming to the fact that the COLD_STORE_FLAG can have 2 possible values with enabling Cold Storage & movement of some data into it ie. 'X' for cold store data & ' ' for hot store data.

Now in our reports, we want to have a universal variable which enables users to select if

They want to access data from cold storage('X') - this may lead to some performance penalty

Or they just want to access the recent data residing in Hot storage of HANA nodes(' ').For securing no data loss while selecting the variable as 'X', we need to access both HANA & IQ (Cold store) data when user selects the variable value as 'X', to handle cases like accessing data from a period which overlaps between hot & cold storage.

The above scenario is handled using the filter in node 'Aggregation_2' using a filter on the created target column : CS_FLAG & restricting it on the input parameter value.

The filter expression basically reads the input parameter value passed, if it comes with a value 'X' (user requests data from both Hot & Cold store), we set the CS_FLAG to go through the HDB_IQ node as per the definition of the field pruning & both 2019 & 2020 years' data are requested, if the input parameter is not fed or filled with blank value ie. ' ', then according to the constant mapping it should only look through the HDB node with ' ' values for the flag, ensuring only Hot store data is selected & no cold store table is accessed causing unnecessary performance penalty.

Now, let's just make a select query on the calculation view without passing any input parameter value :

We can see it only picks the data relevant for year 2020 where the COLD_STORE_FLAG is blank. A planviz shows that the executed plan hits only the Active data table residing in hot store.

Now, let's execute a select query on the same again but this time with the input parameter value filled in as 'X'.

And this time it shows all the data irrespective of the flag value both from hot & cold store for year 2019 & 2020. The planviz shows it hits both cold store table & active data table this time.

Approach#2 : Using double input parameters

Create a calculation view with two input parameters. One input parameter for taking the user input as to determine if access the cold store is needed or not & the other one is to derive the actual filter value to pass for COLD_STORE_FLAG column.
In this case, we have IP_USER_INPUT input parameter to intake the user input, with default value blank & the other one is IP_CS_FLAG, which is derived using a stored procedure. The stored procedure has the input parameter which is fed by the first input parameter & then if user selects 'X', it passes '*'(both Hot & Cold Store should be accessed), else blank(only Hot data store is accessed).

Now let's create a procedure which can take the IP_USER_INPUT as input parameter & populate & return the value of COLD_STORE_FLAG as a feeder to IP_CS_FLAG.

The logic of which is as below :

CREATE PROCEDURE "ZCSFLAG" ( 

IN IP_USER_INPUT NVARCHAR(1), 

OUT IP_CS_FLAG NVARCHAR(1) )

LANGUAGE SQLSCRIPT 

READS SQL DATA AS

BEGIN



IF :IP_USER_INPUT = '' THEN

IP_CS_FLAG := '';

ELSE

IP_CS_FLAG := '*';

END IF;



END;

Now use this procedure as the derivation factor for IP_CS_FLAG.

Now we need to connect the input parameter IP_USER_INPUT to the same of this procedure. This can be done in semantics of the calculation view under tab : Parameters/Variables from Input Parameter Manage Mapping option as shown below :

And then in the lowest Aggregation node we filter the COLD_STORE_FLAG column by using a match function with the IP_CS_FLAG.

This way securing, that if user selects blank as IP_USER_INPUT, we only select hot store data by passing '' value as match filter, else if user selects 'X' in the same, both Hot & Cold store data are selected by passing '*' as match filter. We can again check if the pruning is working as intended by doing a select on the calculation view without manually entering any input. This should take the default blank value & should only access Hot data store (Active Data Table). The below plan viz supports the expectation.

And it picks only those 9 records pertaining to year 2020 from hot data store.

Approach#3 : which does not support proper pruning of maneuvering query to right data tiering storage

However, I tried another exercise with one input parameter & the IF-ELSE handling in the MATCH funtion using filter instead of doing the same in a stored procedure. The results were same, but the difference was in prunning.

Let's assume, I have just one input parameter (VARCHAR(1)) in the calculation view & the default value is blank.

Now in lowest Aggregation_1 node, the filter on COLD_STORE_FLAG is like below :

if('$$IP_CS_FLAG$$' = 'X',match("COLD_STORE_FLAG",'*'),match("COLD_STORE_FLAG",'$$IP_CS_FLAG$$'))

The filter expression basically reads the input parameter value passed, if it comes with a value 'X' (user requests data from both Hot & Cold store), we set the COLD_STORE_FLAG to show all values using a match function with '*' , other values than 'X', which is ' ' should only match with ' ' values for the flag, ensuring only Hot store data is filtered & selected for output.

But the observation from planviz is that it accesses both Hot & Cold store tables even when a blank value is passed.

In terms of performance it is not good if the query hits the external cold store table even if only Hot data is requested & fetched as output. So, the last option is not something we should aim for.

Our job now is to consume this calculation view along in a composite provider & then build a report with the variable based on the input parameter. Let's create an masterdata info object for holding the input parameter possible values for browse help. I created one called CS_FLAG with type CHAR length 1, the master data table of which looks like below :

So, on browse help in report, it will only show the values as unassigned & 'X' to choose from.

As next step, the HCPR : CP_SALES is created & this info object is assigned to the input parameter in HCPR output tab (IP_CS_FLAG in Approach#1 & IP_USER_INPUT in approach#2)

The next step is to create an input ready single value variable on this info object CS_FLAG to restrict the input parameter in the report using the same.

Now simply create a report with meaningful rows & columns dragged into. I have created a sample report : ZQ_SALES_TEST as below just to show the behaviour of the report data controlled by the flag with a single variable in selection prompt screen which was built on CS_FLAG.

Let's now have a look at the selection prompt screen of the report :

So, as mentioned earlier, I have just included the data tiering controller flag variable to showcase the output variance. As expected from the masterdata entries, the value help shows only two possible values to choose from.

Now let's first execute the report without having any value passed to this variable, since it is optional.

We can see only 2020 data is shown back, which is in the hot storage.

Now let's do it again with the variable value passed as 'X'.

And this time we get data from both hot & cold storage ie. both 2019 & 2020 year's data.

PS : Since the '8' view has a union of the cold store & hot store tables in it's sql defintion (explained in my blog post), at this point, it always will create a connection to the cold store no matter what data is requested. Meaning when this view is used in the data model & data from aDSO's hot storage is requested, it will still open a connection to the cold store if DTO is active for the aDSO & there is data in cold store. It will not access the cold store table if we use the above mentioned pruning methods of accessing data, but it will still open the connection since it has to structure the definition of the '8' view, ie. union of aDSO's active table in HANA & the virtual 'OU' table pointing to the cold store. So, make sure you have enough connections available if you are opting for this kind of solution. Else You can make a workaround with a union of active table of aDSO & the 8 view of aDSO & make a constant selection mapping based pruning in the union node with a target field directing the query to 8 view if cold data is requested, else direct the query only to hit the active table of the aDSO in case only hot data is requested using a filter expression restricted on the input parameter.

Hope this blog will help gaining some insights about the generated '8' view for aDSOs being consumed in mixed modelling scenario from BW/4 reporting perspective & securing correct control of data across different data temperature tiering systems with optimum performance in mind.

You are welcome to share any comment/feedback/experience regarding this topic for enriching our mutual knowledge bank 😉

Cheers!
Abhi

Implementing AMDP procedure in the BW customer exit variable

2021-07-09T22:03:26+02:00

Introduction

Implementing AMDP procedure for the custom logic used in the BW customer exit variables.

Applies to

BW/4HANA, BW Powered by HANA.

Summary

What you learn from this blog is to push the custom logics based on table lookups into the HANA via AMDP method to Database instead of relying on the application server.

Many a times in our customer exit variables we might have to read from the cube, ADSO tables, info object tables, HANA Tables, SAP Standard, Custom tables etc.

if we are in a bw4hana then we can use the AMDP procedure to do the “select operations” from the tables. The reason is simple we are trying to bring the database operation to the database itself.(Code to Database)

Author : Lakshminarasimhan Narasimhamurthy

Created on : 13/JUN/2021

Body

Requirement

I have a customer exit variable and the logic is that it must include only the cost centers that are present in the employee master data InfoObject and also include costcenters present for the user in the Z info object(Custom info object).

we can implement the badi RSROA_VARIABLES_EXIT and Now in the custom logic part I'm going to make use of AMDP procedures to read the costcenters.

AMDP stands for abap managed database procedures, basically we're going to make use of native SQL statements within the method.

The interface IF_AMDP_MARKER_HDB must be added to the public section of the class and then add the method to the class with importing and exporting parameters.

The AMDP methods must not be blank and must have SQL statements only.

In the AMDP method implementation we must add the following,

Method <method name>

By database procedure

For HDB

Language sql-script

Options Read-only

Using <table name/view names>

I have created the method “get_cost_centers” inside the class ycl_amdp_var_exit_1(Screen shot 1), the method takes the input of the username and outputs the relevant costcenters from the masterdata.

(Note : The master data infoobjects/ADSO's must be exposed to hana in prior via the check box “External SAP HANA view for master data” if at all you need to read from the generated view(s) in HANA for the BW objects)

The table type YCOST_CENTERS has been created with the line type as cost center(Screen shots 2 and 3)

Screen shot 1 -

Code snippet

class ycl_amdp_var_exit_1 definition

public

final

create public.

public section.

interfaces IF_AMDP_MARKER_HDB.



METHODS:

get_cost_centers

importing

value(lp_un) type XUBNAME

exporting

value(result) type YCOST_CENTERS raising cx_amdp_error.



protected section.

private section.

endclass.

class ycl_amdp_var_exit_1 implementation.

method get_cost_centers

by database procedure for hdb language sqlscript options read-only

using /BIC/Q<table name> /bic/p<table name>.



result = select MAST_CCTR

from

"/BIC/Q<table name>"

where

dateto = '99991231' and

"/BIC/<field name>" = :lp_un

union

select "/BIC/<field name>" AS MAST_CCTR

from

"/BIC/P<table name>"

where

"/BIC/<field name>" = :lp_un;



endmethod.

Screen shot 2 -

Screen shot 3 -

Now create a query (Screen shot 5)and customer exit variable for cost center(Screen shot 4). The processing type is customer exit and it is a mandatory variable.

Screen shot 4 -

Screen shot 5-

I have implemented the badi RSROA_VARIABLES_EXIT and the debugger comes to the variable Y_COSTCENTERS in i_step 2. (Even in i_step 1 same logic can be applied).

The code is given below in Screen shot 6.

Screen shot 6 –

    data : lv_username         type                   xubname,

           ls_range            type                   rrrangesid,

           yob_amdp_var_exit_1 type ref to            ycl_amdp_var_exit_1,

           yt_cost_centers     type                   ycost_centers,

           ya_cost_centers     type line of           ycost_centers.



    case i_vnam.



      when 'Y_COSTCENTERS_01'. " Customer exit variable

To get the username of the user executing the report(SYST-UNAME can also be used instead of the below FM).

          clear lv_username.



          call function 'RSEC_GET_USERNAME'

           importing

             e_username       = lv_username.

Call the AMDP method

             clear la_pernr.



             create object yob_amdp_var_exit_1.



*             try.

             call method yob_amdp_var_exit_1->get_cost_centers

               exporting

                 lp_un  = lv_username

               importing

                 result = yt_cost_centers

                 .

*              catch cx_amdp_error .

*             endtry.

In debug mode

After F6 the data is populated in the yt_cost_centers

As expected 5 cost centers were retrieved from master data.

The report now yields the output

The user(1736) has the following cost centers in Z* infoobject and master cost center in 0employee master data and all of them are visible in the report.

Note – We can debug the AMDP procedure step by step using “Debugger perspective” in SAP HANA STUDIO. Step by step debug of AMDP is possible using F5, F6 etc similar to ABAP Debugger. This will give a greater clarity on the execution of SQL Scripts.

Welcoming the readers to provide feedback and engage with me in the comment section.

References

Introduction to ABAP Managed Database Procedure (AMDP) (saplearners.com)

Query Performance Optimization in BW - Few Tips

2022-02-02T07:13:27+01:00

In this blog, I am going to discuss about the approach I have taken to optimize queries in SAP BW .

Two-way Bex query performance tuning can be done:

Changing the development and design of query.

Tuning and changing the Setting and properties.

Let’s discuss on the two options in details:

A. Tuning with proper setting:::

1. Use Program RSR_CACHE_RSRV_CHECK_ENTRIES to remove the unused Cache entries.

2. Using the Selection of Structure Elements activated.

This option you need to enable when you are selecting specific selection (restricted Key figure) out other key figure you activated the setting when filter passes to the DB and cell which have value only pass to the query in BW. Not All fields and cells are transferred. As a result, query execution time less.

This function you can also not be activated if the query has read mode 'A’ as in this mode all the key figure value are transferred at the start of the query execution so selective process can be done.

For example -

A. Selected on Structure Element AMMOUNT (MN) Without activating Selection of Structure Elements -

Selected on Structure Element AMMOUNT (MN) With activating Selection of Structure Elements -

3. There will be a significant improvement in performance using it if:

Your queries contain a large number of selections or restricted key figures and that need to be displayed latter on the drilldown, not in the initial screen.

When a lot of operations used filters using selections or restricted key figures then this configuration useful.

4. Steps: Go to RSRT -à Go to Query Properties.

My recommended setting in general scenario -

5.Deactivate parallel processing for an individual query.

Deactivate the parallel processing for an individual query which do not have sub query or formula variable with replacement path which execute another subquery. We will gate fast response time.

By below process we can deactivate it –

Go to RSRT-> select Execute + Debug mode -> Data Manager -> select no parallel processing –

6. Operation in BWA/HANA mode: Which is suitable for what scenario:

0 -No Optimized Operations in SAP HANA/No BWA: This is not efficient as this setting not allowing to do any kind of operation inside the HANADB. If there is any virtual key figure used in query, then this setting we apply.

2 - Individual Access per Info Provider: If we used multi-Provider and want to optimize each multi-Provider separately then we use this option,

3- Optimized Access: In this setting we the optimization done as a whole i.e., jointly for all the info providers. This is one of the best settings to get optimize query performance.

6- Exception Aggregation default: Using this setting we can get most optimize performance as it used to perform sub calculation and build sub views on it. But this setting has lots of limitation and everywhere we can not use it. If it is not suitable for your scenario then use 3- Optimize access.

A. Tuning on Development and Design time:::

The below rules are not only true for BEX query but also for other query and views also –

1.Take only those info object/fields in query which you only want to use in the report. No single additional info object/fields.

2.Use Multi provider/Composite provider, if possible, to build a query.

3.Use filter whenever is possible to reduce the dataset into query.

In filter use Not in i.e., Exclude some data point from a data set instead of IN. It improves performance –

4. Minimum use of Free Characteristics: If you know how the Report structure looks like then please use structure to develop the query. I recommended to minimum use of free characteristics. It reduces the memory load and improve the performance.

If we use structures selections inside that and enable the setting “Selection of Structure Elements” the performance improves Significantly.

5. Push the calculation to the transformation layer:

Do not do any kind of calculation i.e., Calculated key figure and Restricted key figure Query Level if it is not required to meet the criteria that cannot be fulfil without creating in query level.

Push all the calculations to the Transformation layer . Develop DSO, info cubes and other objects in different layers and use transformations Layer for Calculated characteristics and calculated info Objects. Pass those info Object/fields to the Reporting Layer.

Use that field into query.

6. Avoid Aggregate unnecessary fields, be specific to the key figures required.

7. in additional in Push the joins (lookups) before aggregation in to narrow down the dataset in info provider level. In native HANA we can use ENUM JOIN_THRU_AGGR same way by alternate we will use via lookup before aggregate whenever it is possible.

8. If required Use logical partitioning - semantic partitioning, multi provhint

9. If required use physical partitioning

10. Use OLAP cache

11. compress cubes

12. Always “Suppress Result Row” to get optimize performance for each field in the Bex query –

13 .Try to reduce characteristics drilldown at Query Level.

14. Choosing the proper decimal precisions for key figure calculation:

Use higher precisions while creating info object using in Info Object maintenance transaction (RSD1) for key figure, and in the query monitor for all key figures of a query.

By default, “short decfloat” with Dec floating point with 16 places selected.

Use “Long decfloat” with floating number with 32 places. This will reduce memory load.

BW4 Query Linked Components – an intelligent feature

2022-03-29T09:24:09+02:00

Introduction to Linked Components

With BW/4HANA, SAP introduced a new intelligent feature at query level called Linked Components. This allows you to link Query components so that changes in the source query components are reflected in the target query components. The system maintains mapping information that allows the queries to be synchronised automatically. We can create Linked components based on Calculated/Restricted Key figures and Queries.

Mapping is supported for InfoObjects, Hierarchies, Restricted Key Figures, Calculated Key Figures, and Variables. Some features are not currently available/supported, such as Filters and Currency/unit conversions.

For example, the business requirement is to write a large number of BW/4 Queries, the majority of which use comparable Restricted / Calculated Key Figures but are based on different InfoProviders. As they are dependent on common business requirements, most of the Restricted / Calculated Key Figures follow the same logic. If the business logic changes, all Restricted / Calculated Key Figures need to be changed.

Instead of manually altering all of these Restricted/ Calculated Key figures, why not just change one of them and the others would automatically be updated?

The question now is, “How can I accomplish such automatic functionality?” This is where the Linked Components feature comes in.

Solution Overview

Using Linked Components feature, the central management of Query objects is achievable. It is now possible to describe the logic of components centrally (for example Calculated/Restricted Key Figures) and reuse the logic across queries created on top of other Info Providers. When the source Restricted / Calculated Key Figure is modified, all linked (target) components are updated.

Deep Dive

We shall examine four topics in this blog post concerning Linked Components:
1. Creating Linked Components
2. Modifying the Source Component
3. Modifying/Deleting the Target Component
4. Decoupling the Target Component

Let us look at the following scenario and see how to work with linked components.

Scenario: IP1 and IP2 are two Info Providers with a similar structure. You have created the query Q1 for IP1. You need to create query Q2 for IP2. This query (Q2) should be similar to query Q1 and should alter automatically whenever query Q1 is changed.

Creating Link Components

To create a Linked Component based on a query, follow the steps below:

1. Open source query Q1 and click on ‘Show Linked Components View’:

This opens a new tab called Linked Components:

2. Open the context menu for the source component and choose New Component:

3. Enter the name of the target component & target Info Provider and a description.

4. Click on Create Proposal.

When you click “Create Proposal,” the system will automatically map the objects based on the reference info object. You have the option to alter the mapping by clicking on ellipsis button on the target object, this opens up a dialog box to choose from.

If the data types for Info Objects match and the system is able to map source and target objects, the status will be green. If the system cannot find any similar fields, the status will be red, with the message “Could not locate a suitable object for **.” In this case, you map it manually.

5. Validate & Create. Now you can see the newly created query (IP2_Q2) is linked to the source query (IP1_Q1):

Modifying the Source Component

If we make any changes to the source component these will be added in the target component as well. Let us look at it in more detail:

1. Open source query (IP1_Q1) and make any changes to it. Let us add Product in rows.

2. Save the changes in Source query.

After saving the source query, the target component icon on the Linked Components tab has been changed and an * is added, indicating that the target component is currently not synchronous with the source component and that any changes made in the source will not be reflected in the target:

3. To start synchronization, choose Synchronize from the context menu for the source component:

If the synchronization is successful, you will get status as green.

Modifying/deleting the Target Component

As the target component is linked to the source component, you are allowed to make limited changes to it. You can only change description or mapping.

Let us look at how to make these changes in the target component.

1. Choose Open from the context menu of the link target component on the Linked Components tab:

2. Under General, press the Edit mapping and synchronize with source component button.

3. Edit mapping and synchronize with source component dialog box appears, make relevant changes (Description / Mapping):

4. Validate & Synchronize.

Note: If you try to make any more modifications to the target component, such as adding filters, removing characteristics/key figures, or even deleting the target query, you will get an error that the Component is still linked and cannot be changed:

Decoupling the Target Component

In order to make further changes/delete the target component, we need to Decouple (breaking the link between source & target component) the target component.

Follow these steps to decouple target component:

1. From the Linked Components tab, open the context menu of target component and press Decouple:

Or

2. Open the target component, in the general tab press Decouple button:

Note: It is not possible to re-link a broken query component; if you wish to re-synchronize, you must restart the entire process.

Conclusion

Overall, Linked Components is a helpful and straightforward feature for mapping source and destination components and automatically synchronising them. It also assures uniformity and saves time.

Supporting Documentation & Information

You can find more information on Linked Components on https://help.sap.com/viewer/dd104a87ab9249968e6279e61378ff66/11.0.8/en-US/ec2998cc10d44c7c8d26817fe8eb63b3.html?q=BWMT%20linked%20components

I hope this blog post has helped you understand Linked Components better. Thank you very much for reading it; please provide your valuable feedback, and if you have any questions, please message me, or you can find more Q&A and post questions in the community by using the links below.
https://answers.sap.com/tags/73554900100800000681 (BW/4HANA) https://answers.sap.com/tags/834511320631052684142696158061592 (SAP Business Explorer)

Please note that this blog post was first published at https://nttdata-solutions.com/uk/local-blog/bw4-query-linked-components-an-intelligent-feature/

How to consume an analytical query / BEx Query in ABAP

2023-01-17T19:59:03+01:00

How can I consume an analytical query in ABAP ?

Normally analytical queries are used with reporting tools like SAC, Analysis Office, WebDynpro Grid, or RSRT in backend.

This post show how to directly access and use the query within your own ABAP application by the use of Lightweight BICS API ( LBA ) .

It's really easy and needs only 2 ABAP calls . Development was driven by the need for testing the query with unit test. But for sure this approach also fits to others usecase where you want to use the query in your ABAP application.

This example show the most simple case. Calling a query without variables.

DATA(lr_std_query) = NEW cl_lba_std_query( i_query_name = 'MyQueryName' ).



lr_std_query->get_resultset(  

               "EXPORTING i_t_requested_columns = lt_requested_columns       "dimensions&keyfigures for resultset  

               "          i_t_variable_values   = lt_variable                "mandatory and optional variables

               "          i_t_filter_values     = lt_filter                  "additional filters   

                IMPORTING e_r_resultset         = DATA(lr_resultset)         "resultset table

                          e_t_column_catalog    = DATA(lt_column_catalog) ). "resultset description

LBA comes also with a 2nd flavours to call the CDS based query.

DATA(lr_std_query) = NEW cl_lba_cds_query( i_view_name = 'MyCDSview' ). 



lr_cds_query->get_resultset(  ...

Query in this context means BW modelled queries:

CDS based analytical queries ,

Query modelled using BW modelling tools ( BWMT )

Query modelled using BEx Query Designer

Note 3269710 contain further details like available releases and has 2 attachments
with several sample cases for CDS based queries and classical analytical queries.

Amount in certain currency is multiplied by 100 at Report Level

2023-02-09T18:08:51+01:00

About Author:

Hari Boda is working as a SAP Lead BW-HANA consultant at TekLink Software Pvt Ltd and has worked on multiple assignments in BW-HANA analytics domain.

Brief about issue:

Amount in certain currency is multiplied by 100 in bex report in other terms the decimal places in a query is returning wrong values, sometimes the amount might be too high or too low by a factor of 100.

Explanation and solution:

This generally happens due to the decimal places maintained in table TCURX.

The Table TCURX defines how currency amounts are converted between DB storage and display on the front-end.

Not only at front end,the TCURX settings are considered also when loading data. Therefore, in order to get consistency, always there should be inverse calculation done at loading time at Application level.

By default, all amounts are stored with 2 decimal places on the database and are later converted for display based on the currency entry in the table TCURX.

If a currency is entered with e.g. value 0, then the currency is displayed with 0 decimal places in BW Queries (which means that the amount is displayed with factor 100 higher than it is stored on DB Level).

Example:

TCURX = NO ENTRY: Database entry = 123.45

The above number is displayed as 123.45

TCURX = 3: Database entry = 123.45

The above number is displayed as 12.345(3 decimal places, as 3 is maintained in the TCURX table).

TCURX = 0 Database entry = 123.45

The above number is displayed as 12345(0 decimal places and shows 12345 as no decimal places maintained in the TCURX table)

In order to correct this in BW:

we have to correct the data for the currencies having issue while loading in BW within the transformation.

In the routine, get the data from TCURX to fetch number of decimal places for the respective currency.

for 0 decimal currencies that are having issue's at reporting layer, assign 100 value to a variable and store it in internal table.

using above internal table, for the respective KPI's and Currency Unit we need to divide by 100.

By doing this division by 100, at the reporting layer the KPI will show correctly i.e. without multiplication of 100.

Thank you for reading my blog. Comments and feedback are welcome!

SAP Premium Engagement: A service roadmap for SAC, S/4 Embedded Analytics, Business Objects and Planning

2023-10-11T23:58:54+02:00

Who we are

We are SAP’s Center of Expertise (COE) for Analytics, Planning, and Consolidation in the globally operating Adoption Service Center. Our goal is to drive adoption and consumption of SAP Business Technology Platform technologies and lay the foundation for the Intelligent Enterprise. We are a trusted partner for customers with MaxAttention or Premium Engagement (PE). Also, we engage in the area of Professional Services, Preferred Success and other partnerships.

Introduction

With thousands of established and new customers moving and expanding their Analytics & Planning solutions in S/4 and BTP, we want to explain how our Premium Engagement services offer every type of help needed for your success.

OnPrem, in the cloud or hybrid

Our services and experts provide solutions and guidance in S/4, BTP, BW/4 and Business Objects. We support with integration, implementation and prototyping. We guide you in your Big Data and AI innovation journey to a quick and positive ROI with modern analytics, planning and forecasting.

Priorities for the Customer from Analytics and Data Management Perspective

From discovery to run

Our service portfolio (Service and Support Catalog link) and engagement model range from:

Expert workshops for discovering innovation.

Architecture and strategy services where new solutioning options are defined reflecting your requirements.

Design, configuration, migration, enablement and prototyping services for your specific analytics, data mangement and planning scenarios.

Holistic functional and technical assessments, verifications, performance tuning and stress testing.

E2E monitoring and issue analysis during go-live and cutover.

Service Portfolio for SAP Analytics and Planning

Key services and highlights

Analytics Strategy: Workshop with experts to define your own path and strategy to a modernized SAP landscape in the area of enterprise analytics and planning, S/4HANA embedded analytics, enterprise data warehousing, and integration scenarios.

Analytics Design: Learn how to refine the implementation aspects of the analytics architecture, e.g., source system connections to SAC, SSO, creating models, UX and reporting & planning applications.

Jump-start for Analytics and Data Management: Demo realization and prototyping of a use case. Identify and realize business processes and KPIs for your enterprise analytics, data management and planning. For example, re-platforming Lumira to SAC.

Enablement Workshop for Data and Analytics: Show-and-tell session and teaching for your technical and functional teams on analytics features, concepts and methods.

Technical Integration Check: Technical assessment of the solution, business processes, interfaces, and system landscape. Transparency and action plans for expert guidance and follow up.

Business Process Performance Optimization: Analyzing and improving the performance of business processes.

Volume Test Optimization: Simulation of peak usage in Analytics to validate if the underlying solution architecture can handle the load.

Analytics & Data Management Health Check: Remote check of the analytics solution for a potential misconfiguration of parameter settings or logs and operational aspects (e.g., housekeeping).

Going Live Support: System monitoring during go-live and hyper-care. Root cause analysis of critical issues during cut-over period.

Service Assignment Options

These services are available for a variety of SAP support frameworks, including Value Assurance, SAP MaxAttention, SAP Active Embedded, and SAP Active Attention. Don’t hesitate to reach out to your Technical Quality Manager (TQM), your SAP Account, your Customer Success Partner (CSP), or our central entry channel, the Virtual Project Room (VPR) to unleash the full potential of SAC, the unrivaled symphony of data insights that elevate your business intelligence to new heights.

In the blogs below we share more tools and insights from our engagements.

SAP Analytics Cloud – Planning in Unified Story using Input Controls

BEx to AfO Automated Mass Conversion Tool

SAP Analytics Cloud – Replicating BW Analysis Authorizations into Dimension Read/Write Property

why UX and Accessibility are important

Strategy for troubleshooting network performance issues in SAC

How to Collect a HTTP Archive (HAR file) from the SAC Mobile App: A Step-by-Step Guide

Bex Query/AFO Reports Development tips/tricks & Performance Improvement Techniques.

2023-10-25T16:10:28+02:00

Hello All,

Welcome back to yet another blogpost on Bex Query/AFO Reports Development, Tips/Tricks & Performance Improvement Techniques. This blogpost will explain best practices to follow during the development of these objects, tips and tricks to follow, and how to optimize the performance of these queries so that we can develop better business reports for our customers.

Before deep diving, first let us understand the flow of data while creating a Business Explorer Report Aka Bex Query in a typical SAP BW or SAP BWONHANA or SAP BW4HANA and BW4HANA mixed and hybrid modelling scenario looks. PFB picture :

There are a lot of blog posts and learning videos available on the web to understand how to create BW objects for modeling before reaching the Bex query. Here I am not going to discuss BW development. Here we will discuss Bex query best practices to follow and optimization techniques.

Best Practices to follow during Bex Query Development

1. When reports from Web Intelligence (also known as WebI or Webi) are connected via a BICS connection, all the data is extracted depending on the characteristics listed under the columns, rows, or free characteristics.In order for the SAP BW BEx Query to provide aggregated results, only necessary characteristics should be present in the columns, rows, and free characteristics.

2. Employ filters to reduce the query's expected result set as much as you can (to a maximum of 1000 lines). Large result sets produced by SAP BW BEx queries are resource-intensive and have an immediate effect on reporting performance.

3. Instead of using formulas in SAP BW BEx Queries, build calculated key figures and restricted key figures at the InfoCube level.This is due to the fact that whereas calculated key figures and restricted key figures are global in nature, formulae are local to a query.As a result, they may be applied to queries created using InfoProviders, resulting in values that are consistent across queries. Additionally, it reduces maintenance work because all queries that use a calculated key figure or limited key figure receive the effects of any modifications made to them.

4. Any computations (such as currency or unit conversions) that must be performed before aggregation should be done either before or during the transformation and loading into the InfoProviders operations. You can skip a significant, time-consuming query-processing step by processing currency or unit conversion during the data-load process and storing the result as part of the InfoProvider. As a result, queries run more quickly.

5. InfoCubes and MultiProviders, which are optimized for data aggregation, should be used to develop SAP BW BEx Queries for SAP BW systems running on non-SAP HANA databases. AVOID writing queries on InfoSets or DataStore Objects (DSOs). DSOs, which are flat-table structures, and InfoSets are largely join conditions and their analytical engines lack efficient data-processing components. Queries on DSOs are preferred for BW systems built on the SAP HANA platform. As a columnar database, SAP HANA is highly optimized for reading and aggregating data at the database level, producing high query performance.

6. The exclude operator should not be used in restricted key figures, filters, or selects since it is not designed to work with indexes. It is preferable to incorporate characteristic values in selections rather than to exclude them.

7. Because BusinessObjects client tools do not use the Result Rows parameter for each characteristic in a BEx Query, it should be set to Always Suppress.

8. If non-cumulative key figures are used in a BEx Query, InfoCube queries must be compressed. The two cumulative key figures that are used to define a non-cumulative key figure are processed more efficiently thanks to InfoCube compression, which also lowers the amount of records in InfoCube tables.

9. Whenever possible, let the global filtering of temporal characteristics be used. By reading data solely from the required database partitions that are constructed based on time characteristics, the Structure Query Language (SQL) engine is able to create an execution plan that is as efficient as possible.

10. Ensure that there is a filter order within the structures and that it is filtered at the highest level. The analytical engine constructs the where clause in the SQL statement using the appropriate filter order.

11. Decrease the amount of data by adding numerous necessary variables. Mandatory variables ensure greater performance by forcing the query user to supply filters at runtime and reducing the amount of data that needs to be read from the database.Make sure all exit variables used in a SAP BW BEx Query have optimized ABAP code. Performance can be greatly hampered by programs with poor ABAP coding.

12. Only incorporate navigational and time-dependent attributes into queries when necessary. The InfoCube tables do not store time-dependent qualities or navigational attribute data. In order to provide the output with time-dependent features and navigational attributes, additional table joins and data processing must be done at query execution time, which causes a performance lag.

13. Reduce the number of nodes in the query results if hierarchies are utilized in the query. The performance of a SAP BW BEx Query is significantly impacted when hierarchy nodes are used. This is because temporary hierarchy tables are created and then read during execution. Utilizing user-entry variables is one method of lowering the number of hierarchies.

14. Suppress the Not Assigned node at the hierarchy definition to remove it from the hierarchy. Performance is enhanced and unnecessary data is prevented from being fetched into the query-result set. To choose the hierarchy, enter the SAP BW transaction code RSH1 and choose Main Menu > Goto > Hierarchy attributes from the menu. Set the Suppress 'Unassigned' Node parameter check box in the pop-up window that appears (Figure below ), and then click the green checkmark symbol to save your settings.

15. Make sure that the Use Selection of Structure Elements parameter in the query
attributes is enabled for queries that contain a number of restricted and computed key figures.
By structuring the SQL statement, it is possible to only retrieve the structural elements or key
figures that are truly needed.

16. for a heavy Bex report where JAN-DEC MTD Data, JAN-DEC YTD Data, Q1-Q4 Data & H1-H2 data need to be shown better to create a period structure and try to load MTD, YTD,QTD,HTD data into the ADSO rather than calculating at the Bex Query. If flat data is loaded to ADSO and still if we create a bex query on top these ADSOs then also performance can be managed to some extent with above points. But if MTD,YTD,QTD,HTD calculations need to be done at a HANA CV level and you are trying to show these calculations in a Bex Query where raw data sits in HANA CV then definitely we will have performance issues as calculation is happening on the analytic engine then hits to DB eng before rendering the number on your screen.

So follow the strategy of calculate -> Store --> Report. (Do not do complex calculations at HANA CV level. If we have huge data volume then for sure report performance will go down)

For Example.

Create a period structure in the Bex Query with individual selections for optimum performance.

17. Avoid Cell restrictions in the Bex query or try to minimize as much as possible.

18. Once the trace is generated we can use of standard hints for the info provider.

How to do this directly without SM30 and as it is a cross client transparent table:-

Go to SAP T Code S37, & enter the function Module SE16N_INTERFACE

Once we execute the same as below :-

For best performance NO_JOIN_THRU_AGGR would be most promising.

why? answer is : Hints are typically used to optimize SAP HANA performance or memory consumption and have no effect on the result set of the request.

How to Analyze the Bex Query performance

If we have taken care With the above steps, the bex query should be in a proper shape and manageable performance.

But still bottlenecks, then how can we analyze the performance of BexQuery?

Kindly follow the steps:

These steps are by my own learning experience by working with various SAP PE experts during actual project work.

Step 1 :- First go to ST 12 and do HANA trace collection from the bankend.

How the ST 12 screen looks like. I found it difficult when I do by my own but took Basis help to collect the trace.

Now with the ST 12 screen open go to RSRT and run the Bex Query in my case it is ZTEST_NAREN_COPA_REORT. Once the report runs fine then again go back to ST 12 then clink end trace collection and click on Fullscreen below or click the SQL Summary:-

How the SQL summary looks :-

Next Click on the call statement

So total DB time arround 321.226 seconds, HANA performance analysis performed.

Step 2: Now say a workbook is created on top this bex query then kindly follow below steps :-

Open Analysis for Office the click on File --> Home-->Analysis -->TroubleShoot --> Advanced Mode -- >Analysis --> Then check mark Enable BW server tracing and Enable workbook Profiling (BW statistics). PFB the picture

Now run the workbook and check TRACE in transaction RSTT

Rerun and Debug is possible here too.

Step 3 : Enable BW query Statistics

Go to SAP T Code : RSDDSTAT to enable the statistics for BW Queries

Change the default setting for all BW Bex Queries as in below picture

Change setting for Individual query or Info providers

Step 4 : Check BW query Statistics

Go to SAP T Code ST13, tool - BIIBTOOLS.

Run BW Statistics Analysis

Select Statistics by User ID and Time .PFB below .

Check the query statistics analysis.

OLAP time reflects the complexity of the BW query design and the time spent on the ABAP time in the application.

Data Manager time reflects the data collection time in the database. PFB snapshot.

Kindly refer to below SAP notes as well

SAP Note 1681396 - Query Performance.

SAP Note 2620998 for Analysis for Office.

AO workbook design : Best Practices to follow

When we refresh a workbook it refreshed every query and the sheet in the workbooks sequentially.

Recommendation:

Refreshing individual Data sources is faster than refreshing all sources.

Use only one query in the sheet, and allow all users to change the columns in the WORKBOOK and refresh the query to change the granularity.

Consider refreshing a single sheet instead of refreshing all at once.

For pure reporting purpose, consider using BI tools instead of Excel. For example SAP BO WEBI and SAC can execute BW bex queries in parallel.

do not check refresh workbook on opening and if we do this refresh before input variables in prompt window and after input new variables, the AO workbook will refresh again.

This will cause duplicate workbook refresh on open.

There are few blogpost and PDF document available on the internet kindly follow this document to check in Bex query optimization in detail and we can understand from scratch.

https://blogs.sap.com/2022/02/02/query-performance-optimization-in-bw-few-tips/

(By Pallab Haldar)

The PDF credit goes to Pravin Gupta (As in the document ) and I do not own the rights for it. The link is just used for self-analysis and reference purposes, as I personally found it useful where each information is given from scratch to end of Bex Query optimization.

https://teklink.com/wp-content/uploads/2015/12/RA2015_Gupta_Optimizingbexqueryperformance.pdf

These pieces of information are neither copied from anyone nor performed in a client system. These queries are performed in a local SAP server. Where ever references were used I gave the credit to the blogpost author.

Thank you,

Narasingha

How to replace RRW3_GET_QUERY_VIEW_DATA

2024-02-07T23:59:11.396000+01:00

This blog is about how to replace the outdated function module in latest system using the Lightwight BICS API (LBA)

function to be replaced

DATA lt_parameter TYPE  rrxw3tquery.
lt_parameter = VALUE #( ( name = 'VAR_LAND'  value = 'DE' ) ).

CALL FUNCTION 'RRW3_GET_QUERY_VIEW_DATA'
  EXPORTING
    i_query       = l_query
*   i_view_id     =
    i_t_parameter = lt_parameter
  IMPORTING
    e_axis_info   = lt_axis_info
    e_cell_data   = lt_cell_data
    e_axis_data   = lt_axis_data.
*   E_TXT_SYMBOLS

this call is showing an example for an analytical query with 1 query variable. Provide a query name and retrieve query resultset with table lt_cell_data. Depending on the use case additional information about axis and text symbols can fetched and need to interpreted by the caller.

replacing with LBA

using LBA the same query is called like this

DATA(lr_lba_query) = NEW cl_lba_std_query( i_query_name = l_query ).
Data(lt_varialbe_value) = VALUE cl_lba_std_query=>tn_t_values( ( name = 'VAR_LAND'  sign = 'I' opt = 'EQ' value_low = 'DE' ) ).
lr_lba_query->get_resultset( EXPORTING "i_t_requested_columns = 
                                       "i_t_filter_values     =
                                       i_t_variable_values   = lt_varialbe_value
                             IMPORTING e_t_column_catalog    = DATA(lt_column_catalog)
                                       e_r_resultset         = DATA(lt_resultset) ).

resultset comparision function module output and LBA output

changing query desingtime setting at runtime

RRW3_GET_QUERY_VIEW_DATA has parameter i_view_id to overrule the query desingtime setting. A view_id contains other query resultset setting than the designtime with regards to dimension-& keyfigures selection and filter settings. The view_id need to be created before using it.

Overruling designtime setting with LBA works different , view_id's are not needed anylonger.

Instead dimension and keyfigure selection can be changed and set with each call dynamicly with i_t_requested_columns.
not providing or empty i_t_requested_columns means to select all available dimensions and keyfigures including dimension from free axis for resultset
Filters can be supplied with i_t_filter_values.

Further details are available with ABAPDoc in the code.

Also see this blog introducing LBA https://blogs.sap.com/2023/01/17/how-to-consume-an-analytical-query-bex-query-in-abap/

Release Info:

Valid for all SAP_BW & BW/4 codelines equal or later than SAP_BW 755 ( embedded BW 7.55 in S/4HANA 2009 ) and DW4CORE300 ( BW/4Hana 2021 )

From BEx to AfO to SAP Analytics Cloud

2024-10-17T12:40:37.516000+02:00

Several years ago, I published a post concerning The BEx Broadcasting Need and SAP Analytics Cloud. It is time to update the use cases from that post.

BEx broadcasting has been an important tool for organizations using BW. It has effectively served important communication workflows over the past twenty-plus years, allowing organizations to distribute reports to a wide variety of users, partners and customers. However, with the need to push content out to stakeholders continuing to be a critical requirement for many of these organizations, and with this capability only available in older versions of SAP BW, such organizations need to deploy an alternative to BEx broadcasting as part of their move to newer technologies like BW/4HANA, S/4HANA, and Datasphere.

While there are still a considerable number of customers continuing to use BEx Analyzer and Broadcaster, a majority of customers have moved on to Analysis for Office. As organizations undertake digital transformations and adopt SAP’s cloud-based offerings, including SAP Analytics Cloud, the need to move beyond BEx becomes more and more pressing.

In her recent update on Analysis for Office, SAP’s Jeanne Bigonnet emphasized SAP’s continuing investment in the cloud-based SAP Analytics Cloud Add-In for Microsoft Excel, but she also noted that the desktop edition of Analysis for Office has a user base of around 1 million, and SAP will continue to support this user base.

From BEx Analyzer to Analysis for Office

In my original post, I contemplated the possibility of implementing SAP Analytics Cloud stories to fulfill the business process workflows that were previously using BEx Analyzer. While that continues to be an effective approach which many will fully or partially employ, it does require the creation of a set of stories and the development of new skillsets by BEx report developers. The preferred path for the majority of organizations currently using BEx is to migrate their BEx reports to Analysis for Office.

But getting the reports moved to Analysis for Office is only half of the journey to replacing the BEx Broadcaster workflows. The next step is to address report scheduling, broadcasting and distribution requirements, which present new challenges.

SAP BusinessObjects provides scheduling and broadcasting capabilities to Analysis for Office users, but the digital transformations of SAP customers are taking these organizations beyond SAP BusinessObjects and into the cloud-based analytics of SAP Analytics Cloud. The move to SAP Analytics Cloud is not cosmetic: it is a shift to advanced analytics, visualization, planning, and integration with SAP’s cloud-based enterprise offerings, creating a unified data fabric. These organizations will face growing pressure to move their BI workflows to take advantage of new capabilities.

From SAP BusinessObjects to SAP Analytics Cloud

As SAP Analytics Cloud adoption continues, organizations are looking for ways to move their Analysis for Office reports to the newer cloud-based analytics so they can remove another use case from SAP BusinessObjects as they prepare to retire the venerable BI platform. But moving Analysis for Office reports to the SAP Analytics Cloud Repository creates a new problem: SAP Analytics Cloud does not support Analysis for Office scheduling and broadcasting.

To move beyond SAP BusinessObjects, organizations using Analysis for Office need to establish scheduling and broadcasting in SAP Analytics Cloud.

With the need to push content out to stakeholders continuing to be a critical requirement for many of these organizations, and with the sunsetting of BEx reports, such organizations need to deploy an alternative to BEx broadcasting as part of their digital transformation and move to S/4HANA, BW/4HANA, Datasphere, and other updated technologies. Analysis for Office meets these needs, but SAP Analytics Cloud lacks support for AfO scheduling and broadcasting. This lack is both a barrier to SAP Analytics Cloud adoption and a barrier to SAP BusinessObjects retirement.

Centralizing Analysis for Office reports in the SAP Analytics Cloud Repository is a first step toward making Analysis for Office an integral part of your data fabric, with all the benefits such integration entails, including improvements to data governance and security.

Scheduling & Broadcasting Analysis for Office Reports in SAP Analytics Cloud

Organizations can overcome the lack of Analysis for Office report scheduling and broadcasting in SAP Analytics for Cloud by deploying APOS Publisher for Cloud.

APOS Publisher for Cloud (available on the SAP Store) smooths the adoption of both Analysis for Office and SAP Analytics Cloud by complementing Analysis for Office workflows with scheduling & broadcasting capabilities. It creates a centralized and unified scheduling and broadcasting environment for SAP Analytics Cloud reports, and SAP Analysis for Office reports.

The solution also includes a web user interface that provides a simplified means of meeting all of the scheduling needs of most Analysis for Office users.

APOS Publisher for Cloud Web User Interface

In summary, the APOS Publisher for Cloud solution helps organizations to:

Move SAP Analysis for Office to SAP Analytics Cloud with scheduling and publishing capabilities
Support SAP Analytics Cloud adoption
Centralize scheduling and broadcasting for better data governance and security
Simplify scheduling with a web user interface
Replace BEx Broadcaster workflows

Connectivity-BW4HANA & SAC:: Configuration of Import Connection

2024-12-04T11:49:26.529000+01:00

Integration between SAC and BW offers a dynamic and comprehensive solution for accessing, analyzing, and visualizing data stored in BW.

Types Of Connections:

1.) Import: When there is a need to bring data from BW into SAP SAC for further analysis, modeling, and visualization, an import connection between SAP SAC and BW is necessary. Below we will explore the step-by-step process of configuring an import connection and setting it up in SAP SAC.

2.) Live: A live connection between SAP SAC and BW is preferred when real-time access to BW data is critical for decision-making. Below we will explore the step-by-step process of configuring a live connection and setting it up in SAP SAC.

Configuration: Import Connection between BW4HANA & SAC:

To configure the data source in SAP SAC, follow these simple steps.

1.First, navigate to the “system” tab in the administration section. Next, click on the “data source configuration” tab, where you will encounter a variety of data sources to choose from. Scroll down until you find the SAP BTP core account option. Take note of the region host and sub-account user details displayed there, as they will be essential for the next step.

2.To establish a secure connection between your on-premise application and the cloud, a cloud connector is essential. This crucial tool acts as a handshaking application, facilitating a seamless link between the two environments. Before proceeding with the installation of the cloud connector, ensure that you have a SAP JVM ready. Locate or download the SAP JVM and make note of its file path, as you will need to specify this during the installation process.

3.Once you have the SAP JVM, extract it onto the server where you plan to install the Cloud Connector. As an example, you can unzip the file into the directory C:\SAP JVM\sapjvm_8. You can download it from this link: https://tools.hana.ondemand.com/#cloud

4.After obtaining the SAP JVM from the provided link, download the cloud connector from the same source. During installation, specify the folder location of the SAP JVM.

5.Once the installation process is complete, open your web browser and enter the following URL: https://localhost:8443. This will take you to the logon screen. Here, use the default credentials: “Administrator” for the username and “manage” for the password. It is recommended to change the password after your initial logon. At this point, you will be prompted to choose between a master and shadow installation. Opt for the “Master” option if you are installing a single Cloud Connector instance or the primary instance from a pair of Cloud Connector instances.

6.Next, enter the subaccount details that you noted earlier. Specify proxy host and port if using a proxy, otherwise leave blank. Optional to enter Location ID for multiple Cloud Connectors. Remember to save the configuration.

7.Once you have completed the necessary configuration, click on the “Connect” button. After doing so, verify that the connector state is displayed as “Connected.” This confirmation ensures that the Cloud Connector has successfully established.

8.When establishing connections with SAP BPC MS, SAP BW, SAP UNX, or SAP ERP systems, it is necessary to install the SAP Analytics Cloud agent in addition to configuring the Cloud Connector. However, for connections with SAP BPC NW, SAP BPC for BW/4HANA, OData, or SAP S/4HANA, configuring the Cloud Connector alone is sufficient.

9.To proceed with the installation of the SAP Analytics Cloud Agent, there is a preliminary step to follow. It involves downloading Apache Tomcat, a widely-used web server and servlet container, from the official website at https://tomcat.apache.org/download-80.cgi. Once the download is complete, simply double click on the Tomcat executable file to initiate the installation procedure. During this step, you will be prompted to accept the license agreement, an important formality. Moving forward, when presented with the Choose Components screen, it is recommended to stick with the default options, which are already configured optimally. And click next.

10.you need to specify the ports to be used by Apache Tomcat. It is essential to ensure that there are no conflicts with existing applications already running on your system.

11.Next, specify the path to your and install.

12.Once you have successfully installed Apache Tomcat, the next vital step in optimizing the performance of SAP Analytics Cloud Agent is to configure the JAVA Heap space allocation. Launching the Tomcat configuration allows you to modify these settings and allocate more memory accordingly. To initiate the configuration process, navigate to the Tomcat installation directory and locate the Tomcat8w.exe file. Simply double click on it to open the configuration window. By default, the initial and maximum heap space values (-Xms and -Xmx) are usually set to 128MB and 256MB respectively, which often prove insufficient for efficient data acquisition in SAC, leading to timeout errors. It is crucial to increase these values to prevent such issues. For enhanced performance, it is recommended to set the values to 1024MB and 2048MB respectively.

13.To install the SAP SAC (Analytics Cloud) agent, begin by downloading it from the SAP Support Portal: https://support.sap.com/swdc. Access the SAP Software Downloads page and navigate to “By Category.” Choose “SAP Cloud Solutions” and then select “SAP ANALYTICS CLOUD CONN SAP ANALYTICS CLOUD CONN 1.0 SAP ANALYTICS CLOUD AGENT 1.0.” Proceed to download the latest version available.

14.Once downloaded, unzip the file and rename the WAR file to C4A_AGENT.war. Extract the package and copy the C4A_AGENT.war file to the webapps directory in your Tomcat installation. When you restart Tomcat, the agent will automatically deploy.

15.To establish the authentication credentials needed for configuring the SAC Agent, follow these steps. First, locate the Tomcat conf directory and open the tomcat-users.xml file. Inside this file, you can add a new user with the Services role. This user will have the necessary permissions to ensure smooth communication between SAP Analytics Cloud and the SAC Agent. Simply provide a unique username and password for the new user, and make sure to save the changes.

16.For establishing a connection with SAP BW, an additional component called the SAP JCO connector is required. To obtain it, you can download the connector from the official SAP website at http://support.sap.com/swdc. Once the download is complete, extract the contents of the downloaded zip file. Within the extracted files, locate the sapjco3.dll and sapjco3.jar files. Copy these two files and paste them into the tomcat/lib directory. After completing the file transfer, it is essential to restart the Tomcat application for the changes to take effect.

17.Now go to your cloud connector at http://localhost:8443. Enter your login credentials to access the Cloud Connector administration console. Once logged in, select the “Cloud To On-Premise” option. Next, locate the “+” icon and click on it to add a new Access Control entry. This step is crucial for defining the access permissions for on-premises systems.

18.The next step is to specify the Back-end Type. Select “Other SAP System” as the Back-end Type from the available options.

19.Then select HTTP protocol. Choose HTTPS if SSL configured on the Tomcat instance where the BOC Agent is deployed.

20.enter the hostname (Internal Host) and port number (Internal Port) of the Tomcat server where the SAC Agent is running. The default HTTP port for Tomcat is 8080, while the default HTTPS port is 8443. Therefore, when specifying the Internal Host, provide the hostname or IP address of the Tomcat server. For the Internal Port, enter the corresponding port number based on whether you are using HTTP or HTTPS (8080 for HTTP or 8443 for HTTPS).

21.Now give virtual host and port that will be used on SAC side.

22.Select “None” as the Principal Type. This selection indicates that there is no specific principal or user identity associated with the access control settings. By choosing “None,” you are specifying that the access control applies to all users or principals attempting to access the specified resources. This can be useful in scenarios where you want to grant general access to the SAP SAC Agent without requiring specific user authentication or identity verification. However, please note that depending on your specific security requirements, you may need to consider alternative options or additional authentication mechanisms to ensure secure access to the SAC Agent.

23.Select the option “Check availability of internal host” to ensure the HANA Cloud. Connector can access the C4A Agent and click finish

24.The next step is to add a resource in the Cloud Connector configuration. Set the URL PATH to “/C4A_AGENT/” and choose the option “Path and all sub-paths” to allow access to this specific path and its sub-paths. This URL PATH represents the endpoint or route where the SAC Agent is accessible within the Tomcat server. By adding this resource and specifying the URL PATH, you are granting the necessary permissions for SAP SAC (Analytics Cloud) to communicate with the SAC Agent and retrieve the required data. Once the URL PATH and access settings are configured, click on the “Save” button to save the resource configuration.

Creating an import connection in SAC:

Follow these simple steps within your SAC tenant. Firstly, navigate to the administration section and access the data configuration tab. Here, you can establish a connection to your on-premise data sources by adding a new location. Enter the required information to create the connection. Specify the Host as the virtual hostname that you previously defined during the HANA Cloud Connector configuration. Next, input the virtual port that you set during the HANA Cloud Connector configuration in the Port field. In the Username and Password fields, enter the credentials that were specified in the tomcat-users.xml file. These credentials ensure secure authentication for the connection between SAC and your on-premise data sources. Once you have entered all the necessary information, simply click on the Create button. This will establish the connection, allowing you to access and analyze your on-premises data.

Happy Learning!!

Creating OData Service with SAP BW Query for C4C Integration via Cloud Platform Integration (CPI)

2025-03-20T18:32:15.806000+01:00

Introduction:

For the requirements such as sending the BW Data (Query) / OData to any SAP cloud systems or third party systems using the Integration Platform process, I created OData Service using SAP BW Query outbound of BW system and send the data to SAP C4C system using SAP CPI (Cloud Platform Integration) by following steps.

Step 1 Create a BW Report:

Go to the required BW Query in BW Modeling Tools and enable the option By OData from BW Query Settings as shown below:

Refer : Steps to Create an ODATA service for a BW Query | SAP Help Portal

Tip: Sometimes, variables requiring mandatory user input may prevent the OData Service from enabling. Ideally, use optional or no variables and avoid authorization-relevant ones. However, this issue may not be relevant in the latest SP levels.

Step 2 Enable OData Service:

2.1 Go to T-Code in BW system: /n/IWFND/MAINT_SERVICE → Select “Add Service”

Select the Service with Query Name
For Ex: - Report Name: ZSALES_ODATA_BW_QUERY
Service generated: ZSALES_ODATA_BW_QUERY_SRV

Service is automatically created & Make sure to Enter your package to collect in a transport request.

2.2 Go back one step to the Service Catalog (Activate and Maintenance) screen:
Select the Service ZSALES_ODATA_BW_QUERY_SRV -> Call Browser to check the data.

2.3 Go to SICF t-code to activate the service

2.4 Check the URL and make sure the Query runs fine without any issues:

By default, the service is called with parameter '?$format=xml', the full URI is: /sap/opu/odata/sap/<query name>_SRV/?$format=xml

Here we can see, with parameter 'ZSALES_ODATA_BW_QUERYResults' we can access the data in the query result.

2.5 Below OData Service links can be useful to display Query Information:

Display Metadata:

https://<BI Portal URL>/sap/opu/odata/sap/ZSALES_ODATA_BW_QUERY_SRV/$metadata

Display Format:
https://<BI Portal URL>/sap/opu/odata/sap/ZSALES_ODATA_BW_QUERY_SRV/?$format=xml

Display Query Result:

https://<BI Portal URL>/sap/opu/odata/sap/ZSALES_ODATA_BW_QUERY_SRV/ZSALES_ODATA_BW_QUERYResults

Display Query Result with Filters:
https://<BI Portal URL>/sap/opu/odata/sap/ZSALES_ODATA_BW_QUERY_SRV/ZSALES_ODATA_BW_QUERYResults?$filter= 0CALMONTH eq '04.2025'

Step3 Login to the SAP CPI (Cloud Platform Integration) system:

3.1 Field mapping between the BW Query and C4C in CPI system.

Map the BW Query Result (Fields from left side of below mapping) with the C4C OData API (Cloud Data Source) from C4C system as shown below:

Note: C4C OData API (Cloud Data Source) is created in C4C system and the BW Query fields are mapped in CPI system.

3.2 A daily job can be scheduled to load the data from SAP BW Query OData service to SAP C4C Cloud data source using CPI system. A defined period and time can also be set similar to process chains and update the data regularly.

Please Refer: SAP Cloud for Customer - Integration to Central An... - SAP Community

Also Please refer to below Links for more SAP insights on OData Service Enabling:

Steps to Create an ODATA service for a BW Query - SAP NetWeaver Business Warehouse - Community Wiki

How to do Odata Services from BEx Query | SAP Blogs

Transform SAP BW Queries into OData Service: Part 1 – Generation and Activation | SAP Blogs

ODP-Based Data Extraction via OData - SAP Help Portal

How to publish BEx through odata service for third party access

2025-04-01T11:07:50.047000+02:00

Saikat Pal is a Manager in Data & Analytics practice of PwC India with 15+ years of experience in SAP Datasphere, SAP BTP HANA Cloud, SAP BTP CAPM, SAP BW4HANA, S4 HANA Embedded Analytics with CDS technology. Saikat has exposure in techno-functional consulting in Material Management, Purchasing, Sales & Distribution, Customer Relationship Management ( CRM ), Supply Chain Management ( SCM ) from Steel Making Industry, Pharma, Petrochemical, Cement, Solar,Battery etc.

**********************

Client Challenge

**********************

Access BW data to any third-party cloud-based system.

***********************

Pre-requisite

***********************

1. Sholud have authorization to RSRT,SE38,/n/IWFND/MAINT_SERVICE tcodes.

**********************

Proposed Solution

**********************

We can expose both data of BEX query via o-data service.

****************************************
1. Steps to Expose BEx query data
****************************************

a. Create any BEx query & click on By O-Data from General Tab

b. Bex query output from RSRT tcode

c. Go to SE38 tcode & run this program

d. Select & Generate Service

e. Go to tcode /n/IWFND/MAINT_SERVICE & select Add Service

f. Give system alias as LOCAL & give the technical name of BEx followed by*. Then press enter. You will get the service below. Please note that this service (*SRV) is generated from the program EQ_RS_AUTOSETUP

g. add selected service

h. Select local Package(if you do not want to transport). Continue with the above screen & then come back at the previous screen.

i.Click on this highlighted service. Activate ICF Node if not active

j. Click on SAP Gateway client

k. Click on execute

l. Status of this service is ok

m. Click on EntitySets & click on _C02_Q0002_ODATAResults

n. Click on Call Browser from SAP Gateway Client

o. Both http & https url is generated

p. Click on Call Browser(http) & you can see the data in XML format which is tallying with RSRT output of BEx

Sunset of BEx Tools in SAP BW - What You Need to Know Before October 2025

2025-05-20T14:45:44.756000+02:00

Introduction: Sunset of BEx Tools - A Critical Milestone by October 2025

IMPORTANT UPDATE (10/15/2025):

BEx Analyzer and BEx Precalculation will no longer be supported in mainstream maintenance and will enter customer-specific maintenance with limited support effective October 15, 2025. Under customer-specific maintenance, the processing of problems is customer-specific. This means that for known problems, the solution is still covered by the maintenance. However, the customer may have to pay for the expense of solving new problems not yet known to SAP. In addition, SAP may, at its own discretion, choose to provide fixes under special circumstances e.g. for selected security issues, or for any critical bug that may impact the migration to alternative tools. See SAP Note 3665993 for more details.

Although BEx Analyzer and BEx Precalculation will be in customer-specific maintenance from October 15, 2025, other BW BEx tools such as BEx QueryDesigner and BEx WebApplicationDesigner have no direct dependency to Microsoft Office and will continue to be supported as usual until 2030, including, with the availability of bug fixes for any new errors reported for BW 7.5, and with a .NET compatible version not higher than 4.8. Consequently, support for other BEx tools such as BEx QueryDesigner and BEx WebApplicationDesigner is provided with BW 7.50 until the end of maintenance of BW 7.5.

With the clock ticking toward October 14, 2025, the end of support for Microsoft Office 2016 and 2019 also signals the end of mainstream support for Excel-based SAP BEx tools like BEx Analyzer, BEx Workbooks, and BEx Broadcaster (Pre-calculation) by SAP. While some BEx components (BEx Query Designer, BEx WAD) will continue in maintenance mode until 2027 or 2030, the Excel-dependent tools face a end of mainstream maintenance and move into customer specific maintenance with limited support from October 15, 2025.

While many organizations are already moving forward with SAP Datasphere adoption or planning their SAP BW/4HANA conversion, those still operating on SAP BW 7.x must urgently assess their current BEx tool usage to avoid disruptions and ensure long-term supportability.

In this article, we break down:

What BEx tools are affected and when
How to check if your system still relies on BEx Tools approaching end of support
Available replacements like SAP Analysis for Office and SAP Analytics Cloud
SAP's mass conversion tools and services to ease your transition

For answers to the most frequently asked questions (FAQ) about the BEx tools sunset, check out the dedicated FAQ:

👉Sunset of BEx Tools – Frequently Asked Questions and Answers (FAQ)

Whether you have already started migrating or are still evaluating your next steps, this article will help you understand the risks, available options with existing BEx tools usage.

BEx Solutions Overview

SAP offers a range of BEx-related tools and components, each serving different roles in the reporting and analysis workflow. These solutions fall into two broad categories; those dependent on Microsoft Excel and those that are web-based or standalone.

BEx tools can be classified in two broader categories:

Excel-Dependent (Impacted by both BEx sunset and Office lifecycle)

BEx Analyzer
BEx Workbooks
BEx Broadcaster

Standalone/Web-Based (Independent of Office support)

BEx Query Designer
BEx Queries
BEx Web Application Designer

BEx tools that rely on Excel only work with specific versions of Microsoft Office. The last versions supported by BEx tools are Office 2016 and Office 2019. Since Microsoft's decision to stop supporting Office 2016 & 2019 versions by October 14, 2025, this poses a hard limit on the mainstream maintenance support timelines for the excel based BEx reporting tools as well, and after that BEx tools (BEx Analyzer, BEx Workbooks and BEx Precalculation) dependent on Excel will enter into customers-specific maintenace support by SAP from October 15, 2025.

BEx tools that don’t rely on Microsoft Office (i.e. BEx Query Designer, BEx Queries, BEx WAD) can still be used and supported until 2027 (standard support) or 2030 (extended support), in line with BW 7.50 maintenance timelines. These tools are now in maintenance-only mode, meaning SAP will only provide basic support for fixing issues in BW 7.5 with no new development, innovation or new features planned for these BEx tools.

BEx Tools – Supportability Overview

Following table provides the End of Support for the BEx related products based on SAP NetWeaver or BEx End of Life timelines:

Key References and Support Notes for BEx Transition

The End of mainstream support for BEx (excel based tools) is reinforced by external dependencies, such as Microsoft’s end of support for Office 2016 and 2019, which directly impacts the usability and security of BEx Analyzer and Workbooks and BEx Broadcaster. Excel depedent tools such as BEx Analyzer, BEx workbooks and BEx Pre-calculation server will enter into customers-specific maintenace support by SAP from October 15, 2025.

SAP has formally communicated the BEx sunset through multiple channels, including official SAP Notes and blogs dating back as early as 2016. The references below serve as key evidence points supporting the urgency and inevitability of moving to modern alternatives like SAP Analysis for Office (AO) or SAP Analytics Cloud (SAC):

Microsoft Support link - Microsoft will no longer provide technical support, bug fixes, or security fixes for Office 2016 and Office 2019 vulnerabilities which may be subsequently reported or discovered. This includes security updates which can help protect your PC from harmful viruses, spyware, and other malicious software
Announcements for BEx sunset was announced through the blog - Announced in 2016
SAP Note 2609031 - Sunset of BW Business Explorer (BEx) – Announced in 2018

Additional References:

SAP Note 3665993 - End of Mainstream maintenance and start of customer-specific maintenance for BEx Analyzer and BEx Precalculation w.e.f. Oct 15, 2025
SAP Note 1973324 - BEx support for Microsoft Office 365 - Client Excel 2013 and 2016
SAP Note 3474912 – BEx Query Designer support for BW 7.50
SAP Note 3590297 - SAP BW NetWeaver Cloud: Information about maintenance availability in private cloud editions
SAP Note 1995532 - BI 7.x tools - HW\SW requirements and Compatibility of Microsoft Operating Systems and Office Products

BEx Sunset Adoption Gaps

As part of SAP’s long-term strategy to modernize its business intelligence tooling landscape, the sunset of BEx (Business Explorer) tools has been formally announced, encouraging customers to transition to more advanced and supported alternatives such as SAP Analysis for Office (AO) and SAP Analytics Cloud (SAC).

However, many SAP BW 7.x customers are at varying stages of adoption readiness, and significant gaps remain in fully realizing this transition. We observed these customers in following categories:

Transition Planned but BEx Still in Use: BW 7.x customers who have already planned the transition from BEx tools to modern alternatives such as SAP Analysis for Office (AO) or SAP Analytics Cloud (SAC)
- Users have been informed about the BEx sunset through communication efforts like end-user trainings, replacement solutions and awareness sessions
- Despite these efforts, end users continue to use BEx tools (e.g., BEx Analyzer, BEx Workbooks) for their reporting activities
Unaware of BEx Sunset: BW 7.x customers who are not aware of the sunset of BEx tools.
- BEx continues to be the primary reporting tool for all business use cases, as users are not informed of alternative solutions or the transition roadmap

What SAP Products are impacted:

SAP BW 7.5 or lower: BEx Analyzer/Workbooks can be the primary reporting front-end for classic BW systems
Embedded BW (in SAP ECC or ERP): Even though Embedded BW is typically used for operational reporting, BEx Analyzer/Workbooks can still used in some implementations
SAP SCM (Supply Chain Management): SCM systems with APO or SNP modules often have their own BW instance or rely on Embedded BW

While BEx is closely associated with SAP BW, its footprint extends into nearly every corner of the SAP ecosystem i.e. from legacy CRM and SRM systems to industry-specific solutions like IS-U and IS-Retail. Any system with a BW component or an integration to BW for analytics could potentially be generating BEx usage worth monitoring.

How to identify the impact in SAP BW system:

There are few potential options to check it in the system or EWA if BEx Analyzer or BEx Broadcaster is still used in the SAP BW system:

Option 1:

The SAP EarlyWatch Alert (EWA) report is a proactive monitoring tool provided by SAP that delivers a comprehensive technical health check of your SAP system. It is part of SAP’s support offering and is typically generated weekly to help detect and prevent potential issues before they impact system performance or availability.

Check section “Frontend Distribution” in BW EarlyWatch Alert reports. This section provides an overview of BW query executions, segmented by frontend tools, for the period covered in the EarlyWatch Alert (EWA) report. The data is sourced from the RSDDSTAT_OLAP view in the BW system.

The availability and data for the section depends on the configuration of the EarlyWatch Alert report for BW system: e.g.

ACTION REQUIRED: If there are any entries in BEx Analyzer 7.x and/or BEx Broadcaster, it is critical to initiate remediation steps to mitigate the impact of BEx End of support

Note: The statistics in EarlyWatch Alert report are extracted from the RSDDSTAT_OLAP view. Accuracy of the data relies on the proper enablement and execution of detailed statistics collection through transaction RSDDSTAT in SAP BW system, which must be activated for Workbooks, Queries, and InfoProviders to capture the statistics.

Option 2:

If EarlyWatch alert is not activated, you can login to the BW Production system, and manually check BEx tool usage accessing transaction SE16, and table RSDDSTAT_OLAP:

For BEx Analyzer / Workbook usage:
- Use selection “BEX” as STEPTP field and “3200” as EVENTID.
- Number of entries > 0 show the usage of BEx Analyzer / Workbooks in the system.
For BEx Broadcaster usage:
- Use “14601”, “14611” and “14671” as EVENTID.
- Number of entries > 0 show the usage of BEx Broadcaster (Pre-calc server) in the system.

The USERID field in the results will identify which users are actively using BEx tools

ACTION REQUIRED: If there are any entries in either of the above cases, it is critical to initiate remediation steps to mitigate the impact of BEx end of support.

Additional Consideration: This analysis is not limited to standalone BW systems. You can also perform this check in SAP systems with the SAP_BW component, such as ECC, SCM, or CRM etc. While most customers leverage standalone BW for central reporting, embedded BW capabilities in source systems allow the creation and use of BEx queries locally; another area that must be assessed during BEx deprecation planning.

How can SAP Services help?

BEx Workbooks

To ensure continuity and supportability, all BEx Workbooks should be migrated to SAP Analysis for Microsoft Office (AO). For customers with only a few BEx Workbooks, a manual migration may be more practical.

For customers with a large number of BEx Workbooks, SAP offers a tool for Automated Mass Conversion Tool to accelerate and facilitate the conversion process from BEx (Analyzer) Workbooks to Analysis for Office Workbooks. The Automated Mass Conversion Tool is 6x to 8x faster than the manual conversion method, conversion of 100 Workbooks take around 5-6 Minutes, compared to at least 30 seconds per one workbook in case of manual conversion.

This service is available for both MaxAttention (Premium Engagement) and Professional Services customers, if you would like to request it or find out more about it please contact your Engagement Architect, Technical Quality Manager, Account Manager or you can reach out to us via the email:

SAP PremiumHubCoE_BExtoAO_Migration

BEx Broadcaster (Pre-calculation)

Unlike BEx Workbooks, which benefit from SAP’s Mass Conversion Tool for migration to Analysis for Office, BEx Broadcaster (Pre-calculation) presents a different challenge. There are following replacement options available:

SAP Analysis for Microsoft Office (AO) with Scheduling via BI Platform
SAP Analytics Cloud (SAC) Publication

There is no automated conversion tool available for migrating broadcasting scenarios to replacement alternatives. Customers must manually rebuild scheduling and distribution logic from scratch using supported replacement options.

Conclusion

While many customers have already transitioned to modern alternatives, there are customers who still rely on BEx tools particularly BEx Analyzer, BEx Workbooks and BEx Pre-calculatio server for critical reporting and scheduling needs. BEx Analyzer, BEx Workbooks and BEx Precalculation will no longer be supported in mainstream maintenance and will enter customer-specific maintenance effective October 15, 2025.

Organizations with a significant footprint of BEx Workbooks should be aware that migrating to SAP Analysis for Office can require substantial time and manual effort. SAP offers a Mass Conversion Tool and expert services through SAP MaxAttention and the CoE teams to accelerate this process and reduce the operational burden. Please connect at SAP PremiumHubCoE_BExtoAO_Migration.

For those using BEx Broadcaster (Pre-Calculation Server), it is equally important to plan a transition to supported scheduling solutions using manual rebuild such as SAP BusinessObjects BI Scheduling or SAP Analytics Cloud Publications.

Taking proactive steps today will ensure business continuity, reduce security and compliance risks, and set your organization on a clear path toward a modern, supported, and future-ready analytics strategy beyond BEx.

Sunset of BEx Tools - Frequently Asked Questions and Answers (FAQ)

2025-05-27T05:16:16.873000+02:00

Sunset of BEx Tools - Frequently Asked Questions and Answers (FAQs):

IMPORTANT UPDATE (10/15/2025):

BEx Analyzer and BEx Precalculation will no longer be supported in mainstream maintenance and will enter customer-specific maintenance effective October 15, 2025. Under customer-specific maintenance, the processing of problems is customer-specific. This means that for known problems, the solution is still covered by the maintenance. However, the customer may have to pay for the expense of solving new problems not yet known to SAP. In addition, SAP may, at its own discretion, choose to provide fixes under special circumstances e.g. for selected security issues, or for any critical bug that may impact the migration to alternative tools. See SAP Note 3665993 for more details.

Although BEx Analyzer and BEx Precalculation will be in customer-specific maintenance from October 15, 2025, other BW BEx tools such as BEx QueryDesigner and BEx WebApplicationDesigner have no direct dependency to Microsoft Office and will continue to be supported as usual, including, with the availability of bug fixes for any new errors reported for BW 7.5, and with a .NET compatible version not higher than 4.8. Consequently, support for other BEx tools such as BEx QueryDesigner and BEx WebApplicationDesigner is provided with BW 7.50 until the end of maintenance of BW 7.5.

With support for BEx Analyzer, Workbooks, and Broadcaster ending in October 2025, organizations using SAP BW need to act now. This article answers the most frequently asked questions around the BEx tool sunset, outlines key dates, risks, and support limitations, and explores recommended replacement tools like SAP Analysis for Office and SAP Analytics Cloud

We have grouped the questions by components to make the information clear, simple, and component-specific.

General Questions about End of Support
Migration and Replacement Tools
Technical and Operational Concerns
Conversion Questions
License
Planning and Next Steps

For an Overview of the BEx tools sunset including the rationale, timelines, and key actions customers should consider ahead of October 2025, refer to previous detailed blog post:
👉Sunset of BEx Tools in SAP BW – What You Need to Know Before October 2025 This foundational article complements the FAQs by offering strategic guidance for planning your transition effectively.

General Questions about End of Support:

What specific BEx tools are affected by the end of support in October 2025?

BEx tools dependent on excel, such as BEx Analyzer, BEx Workbooks, and BEx Broadcaster (Pre-calculation server) are impacted

What are the key dates we need to be aware of for the end of support?

October 14, 2025: End of Microsoft support for Office 2016 and 2019, impacting end of mainstream maintenance support for BEx Analyzer / Workbook and BEx Broadcaster (Pre-calculation server) but supported in Customer specific maintenance from October 15, 2025.
December 31, 2027: End of mainstream maintenance for SAP BW 7.5.
December 31, 2030: End of extended maintenance for SAP BW 7.5 and BI Java based Broadcasting and BEx Query Designer
Note: Users on older SAP BW versions (e.g., 7.4 or earlier) have already past their mainstream maintenance end dates in 2020.

What happens if we continue to use BEx Excel dependent tools after the end of support dates?

BEx Analyzer and BEx Precalculation will no longer be supported in mainstream maintenance and will enter customer-specific maintenance effective October 15, 2025. Under customer-specific maintenance, the processing of problems is customer-specific. This means that for known problems, the solution is still covered by the maintenance. However, the customer may have to pay for the expense of solving new problems not yet known to SAP. In addition, SAP may, at its own discretion, choose to provide fixes under special circumstances e.g. for selected security issues, or for any critical bug that may impact the migration to alternative tools. See SAP Note 3665993 for more details.
After the start of customer-specific maintenance, the processing of customer cases for BEx Analyzer and BEx Precalculation will proceed as follows. This also applies to broadcasting of BEx workbooks (since it uses BEx Precalculation):
- Customers can continue to report issues via customer cases as usual. Technical Support and downstream support teams will continue to accept and process customer cases during the regular message processing.
- The reported error is analyzed.
  - If the error is already known and has been fixed, the known solution will be made available to the customer.
  - If the error is not known yet, it is regarded as a new, as yet unknown error. In this case, SAP will use its discretion to either decline the correction, or may choose to offer a fix depending also on the complexity of the issue and the feasibility of providing the fix. However, this will be regarded as a consulting service and may be subject to additional charge
  - You may speak with your Account Executive or Customer Engagement Executive about Professional Services options in order to avail SAP's consulting services that may be subject to additional charge

What about embedded BW systems (e.g., ECC, SCM, CRM) using BEx tools, are they also impacted?

Yes. Any system with the SAP_BW component, including embedded BW in SAP ERP systems, is impacted if excel based BEx tools are used for reporting.

Migration and Replacement Tools:

What are the recommended replacement tools for BEx Analyzer and BEx Workbooks?

SAP recommends transitioning to:
- SAP Analysis for Microsoft Office (AO) for Excel-based reporting with similar layout and filtering capabilities. SAP offers Mass Conversion Tool through SAP Services to convert existing BEx Workbooks to Analysis for Office workbooks. Manual conversion of BEx to AO workbook also possible.
- SAP Analytics Cloud (SAC) Excel Add-in for modern, web-based dashboards, stories, and advanced analytics. There is No automated conversion tool exist for converting BEx Workbooks directly to SAC Excel Add-in. Migration requires manual rebuilding of reports and dashboards in SAC

What are the recommended replacement tools for BEx Broadcasting (Pre-calculation server)?

Broadcasting / Scheduling in SAP BW systems is used to schedule and distribute BEx Query and Workbook outputs via email, portal, or printer, leveraging different SAP broadcasting solutions such as Pre-calculation Server, BI Java Scheduling, SAC Publication, Analysis for office scheduling
BEx Broadcaster (Pre-calculation Server) support will end in October 2025, aligning with the broader SAP BEx sunset
Broadcasting via BI Java scheduling is available but not considered a long-term strategic option due to planned EOMM by 2027 and EOEM by 2030
Recommended Alternatives for scheduling and distribution:
- SAP BusinessObjects Business Intelligence: Offers built-in scheduling capabilities through the SAP BusinessObjects platform, including the ability to schedule Analysis for Office Workbooks
- SAP Analytics Cloud Publication: Strategic SAP solution for modern, cloud-based report distribution and scheduling

What are the recommended replacement tools for BEx Web Application Designer (WAD)?

BEx Web Application Designer is supported with BW on HANA and BW/4HANA until 2030, subject to the end of mainstream maintenance in 2027 and the availability of extended maintenance through 2030.
SAP recommends replacing BEx Web with SAP Analytics Cloud (SAC) as primary replacement tool

Is there any impact on BI Java or BOBJ based Broadcasting tools with this BEx tool sunset?

No. there is no impact to BI Java or BOBJ based broadcasting tools.
However, BI Java based broadcasting is supported as per the maintenance timelines for BW 7.50 i.e. until 2027 (mainstream maintenance) and until 2030 (Extended Maintenance) with BW 7.5 and BW/4HANA.

What are the migration paths for our existing BEx workbooks to Analysis for Office?

For customers with a large number of BEx Workbooks, we recommend engaging with SAP MaxAttention or the SAP Services team, which offers a mass conversion tool to automate the migration of BEx Workbooks to Analysis for Office format
For customers with only a limited number of BEx Workbooks, a manual migration using Analysis for Office may be more practical

What are the migration paths for our existing BEx workbooks to SAC?

There is currently no automated conversion tool available to migrate BEx Workbooks directly to SAC
As a result, any migration from BEx Workbooks to SAC requires a manual rebuild of the report content using SAC’s capabilities

What are the migration paths for our existing BEx Broadcasting to SAC Publication?

There is no direct migration path or automated tool to convert existing BEx Broadcaster (Pre-calculation server) to SAC Publications
Customers must manually recreate broadcasting logic using SAC’s Publication and Scheduling features

What resources or support does SAP offer for this migration?

For customers with a large volume of BEx Workbooks, SAP MaxAttention or SAP Services team provide:
- A mass conversion tool developed internally by SAP Services to automate workbook migration
- Expert-led migration assessments, scoping, and planning workshops
- Support for functional validation and post-migration support

Technical and Operational Concerns:

Will our existing SAP BW system (e.g., BW 7.5) still be compatible with BEx tools if we don't upgrade Office?

Technically, your SAP BW 7.5 system will continue to support the excel independent BEx tools (BEx Query Designer) until the end of its own maintenance (mainstream until December 31, 2027, and extended until 2030).
However. excel dependent tools (BEx Analyzer/Workbooks, BEx Broadcasting – Pre-calculation server) will have end of mainstream maintenance support by October 14, 2025 and will enter customer-specific maintenance effective October 15, 2025.

If we are planning to move to SAP BW/4HANA, what is the role of BEx tools in that landscape?

BEx tools are not supported with BW/4HANA and already has replacement path

BEx Analyzer / Workbooks à Analysis for Office (Conversion)
BEx Broadcasting (Pre-calculation server) àBI Java Broadcasting / BOBJ scheduling / SAC Publication (Rebuild)
BEx Queries à Queries (No changes)
BEx Query Designer à Eclipsed based BW-MT Modeling tool (Modeling tool change)

If customers continue using BEx Analyzer / Workbooks / BEx Broadcaster with Office 365 or newer platforms, and something breaks, will SAP support incidents still be accepted?

BEx Analyzer and BEx Precalculation will no longer be supported in mainstream maintenance and will enter customer-specific maintenance effective October 15, 2025.
After the start of customer-specific maintenance, Customers can continue to report issues via customer cases as usual. Technical Support and downstream support teams will continue to accept and process customer cases during the regular message processing.
The reported error is analyzed.
- If the error is already known and has been fixed, the known solution will be made available to the customer.
- If the error is not known yet, it is regarded as a new, as yet unknown error. In this case, SAP will use its discretion to either decline the correction, or may choose to offer a fix depending also on the complexity of the issue and the feasibility of providing the fix. However, this will be regarded as a consulting service and may be subject to additional charge
- You may speak with your Account Executive or Customer Engagement Executive about Professional Services options in order to avail SAP's consulting services that may be subject to additional charge

Since BEx Analyzer is tightly coupled with SAP GUI for Windows, will SAP continue to deliver SAP GUI updates (compatible with BEx) for the full NetWeaver 7.5 maintenance window (i.e., through end of 2027 or 2030 extended)?

The BI Frontend patch 600 of BI 7.0 ADDON FOR SAP GUI 8.00 is the last BI Frontend patch to still contain regular bug fixes for BEx Analyzer and BEx Precalculation that are provided as part of regular mainstream maintenance. All subsequent BI Frontend patches will no longer contain regular bug fixes for BEx Analyzer and BEx Precalculation. However, SAP will continue to include both BEx Analyzer and BEx Precalculation as part of the standard BI 7.x Frontend patches in future also, i.e. even after FEP 600.

Will our existing BEx Queries still work with the BEx Query designer tools?

You can still design and maintain queries using BEx Query Designer until the end of 2030
If you are running BW 7.5 on HANA or BW/4HANA, you also have the option to use the Eclipse-based BW Modeling Tools (BW-MT) for query design and modeling

Are there any plans to support BEx Analyzer and BEx workbooks beyond October 2025, especially for customers planning their BW strategy over the next several years with SAP BW 7.5 PCE?

BEx Analyzer and BEx Precalculation will no longer be in mainstream maintenance and will enter customer-specific maintenance effective October 15, 2025..

Conversion Questions:

When we convert a report from BEx to AFO, does the output stay in the same format (ie same data in same columns)?

Mostly Yes, the table structure and measure/dimensions are replicated like in the source system, which includes respecting common filtering conditions.
- Underlying query logic is preserved when opening BEx workbooks in AFO.
- However, UI rendering, formatting, and charting might look different as AFO uses Excel's engine, so custom formatting from BEx might need manual tweaks.

Is there any limitation on the data AFO can access/any reason to think that if we have something in a BEx report we can’t get it in an AFO report?

No, additional BW authorizations should be required to refresh a BEx Query in Analysis for Office compared to BEx Analyzer.

How do users access AFO? Does it depend/matter which SAP GUI users are on?

Analysis for Office is a client tool which will need to be installed on the end user’s machines. There is no dependency on SAP GUI. Refer to https://support.sap.com/content/dam/launchpad/en_us/pam/pam-essentials/AO_28_PAM_Additional_Info.pdf for more details

What are the limitations of conversion of BEx to AfO Workbooks using Mass Conversion tool?

The following features are not automatically converted but required some adjustment: Styles, Conditions, Exceptions, VBA API, Navigation Panes, Dropdown Boxes, Buttons
The workbooks with given features can be identified during the Pre-Assessment

How can we ensure functional parity when replacing BEx queries with modern tools?

SAP reporting tools such as Analysis for Office, Business Objects Business Intelligence, and SAP Analytics Cloud do not replace the need for BEx Queries. Instead, BEx Queries are consumed by these solutions to query the data.

For conversion effort, let say few thousand of server workbooks were saved in the BW. Is there a way to assess which are effectively in use?

Yes, Pre-assessment service from SAP will identify the Workbooks (saved on BW server) which are frequently used. Local workbooks saved on user desktop can not be identified as part of this assessment.

License:

What are the licensing implications when moving from BEx to new tools like SAP Analysis for Office or SAP Analytics Cloud?

SAP Analysis for Office and SAP Analytics Cloud required additional licensing which is not provided with an SAP BW license. Please discuss the options with your Account Executive.

Is license for Analysis for office based on number of users?

Analysis for Office, Standard Edition is available to use if you have a BusinessObjects license.
Analysis for Office, SAC Edition is available if you have an SAC subscription. The SAC Edition does require you to have an SAC user, so it is effectively user-based licensing.

Do customer need to buy additional license if they already have BOBJ license?

No, every BOBJ license also includes Analysis for Office.

Planning and Next Steps:

What are the first steps we should take to prepare for the BEx end of support?

Assess your current BEx landscape: Identify all BEx reports, their usage, and dependencies.
Educate stakeholders: Inform relevant business and IT teams about the upcoming changes and their implications.
Evaluate replacement tools: Understand the features and capabilities of SAP Analysis for Microsoft Office and SAP Analytics Cloud.
Develop a migration plan: Outline timelines, resources, and a phased approach if necessary.

Who should be involved in planning and executing the migration from BEx?

A cross-functional team is ideal, including IT (SAP BW/BI specialists), business users from various departments who rely on BEx reports, and may be project management.

What kind of training will our users and developers need for the new tools?

Users will need training on how to use SAP Analysis for Microsoft Office or SAP Analytics Cloud for report consumption, ad-hoc analysis, and potentially report creation.
Developers will need training on the new development environments and best practices for the chosen replacement tools

Conclusion:

We have made every effort to cover the important FAQs, however we understand you may have additional questions. Please refer to standard SAP guides or Feel free to use the comments section to ask them. We are committed to keeping this blog up-to-date with the latest information. We hope this has been a helpful resource.

Easy to get in SAP

2025-09-22T22:39:15.645000+02:00

🚀 3 Simple Steps to Break Into the SAP World (No Overwhelm!)
Want to join the $300B+ SAP ecosystem but don’t know where to start? Here’s how to dive in without complexity:

1️⃣ Start with FREE Learning
- Explore SAP Learning Hub (free tier): Bite-sized courses on ERP, S/4HANA, and cloud solutions.
- Try SAP Community: Tutorials, forums, and real-world use cases. No cost, just curiosity!

2️⃣ Pick Your Path
- For Tech Folks: Learn ABAP (coding) or SAP BTP (low-code/no-code tools).
- For Business Roles: Focus on Finance (FI), Supply Chain (MM), or HR (HCM) modules.
- Tip: Start with one module (e.g., SAP S/4HANA Cloud) instead of boiling the ocean.*

3️⃣ Get Hands-On FAST
- Use SAP Free Trials: Test real systems via GROW with SAP (for new users) or RISE with SAP sandbox.
- Join SAP’s Partner Ecosystem: Many offer free workshops and certifications (e.g., SAP Learning Journeys).

💡 Key Mindset Shift
"SAP isn’t just for IT pros—it’s for *problem-solvers. If you understand business processes (finance, logistics, sales), you’re already halfway there."

✅ Your First Move Today:
👉 Bookmark: [SAP Learning](https://learning.sap.com)
👉 Join: [SAP Community](https://community.sap.com)
👉 Try: Free SAP S/4HANA Cloud trial (search "SAP Free Trials").
and don't forget to look at Youtube 😃

You don’t need a Ph.D. in tech—just a structured start. What’s your SAP goal? Let’s chat below! 👇

Warm Wishes 💖

How to Identify Selections Used in RKFs in Rows/Columns of BW/BEx Queries

2025-10-09T12:28:22.271000+02:00

In continuation of my previous blog (Section 5 of All about Bex Query elements in SAP BW/BW4HANA - SAP Community), this post focuses on example involving Restricted Key Figures (RKFs) in SAP BW/BEx queries.

In this blog, I explain the best way to extract or identify the selection criteria applied in RKFs that are used in the rows or columns of a BW/BEx query.

When a query contains only a few rows or columns (e.g., 5–10), it's relatively easy to manually check the selections used in each RKF. However, in more complex reports such as Balance Sheet or Income Statement reports with over 50 rows manually checking each row or column becomes time consuming and inefficient.

To overcome this challenge, we can leverage backend SAP BW tables to extract the relevant details and analyze them in Excel. The key tables involved in this process are:

RSRREPDIR – Query directory
RSZELTXREF – Element cross-reference
RSZRANGE – Selection ranges
RSZELTDIR – Element directory

By correlating these tables, we can efficiently retrieve the selection criteria used in RKFs that are used in the rows or columns of a BW/BEx query, saving significant manual effort.

Steps to Identify Selections Used in RKFs in Rows and Columns of a BW/BEx Query.

Step 1: In the Table RSZCOMPDIR / RSRREPDIR enter the query technical name in the field COMPID to obtain the COMPUID of the query.Screenshot 1 : Output of RSRREPDIR table

Step 2: In the RSZELTXREF table, enter the COMPUID of the query (from step 1) in the field SELTUID to obtain TELTUID.Screenshot 2 : Output of RSZELTXREF table

Step 3: Again, in the RSZELTXREF table, enter TELTUID (from step 2, where LAYTP = ‘SOB’) in the field SELTUID and execute the table.Screenshot 3: Output of RSZELTXREF table

Step 4: Again, in the RSZELTXREF table, enter TELTUID (from step 3, where LAYTP = ‘COL/ROW’) in the field SELTUID and execute the table.Screenshot 4 : Output of RSZELTXREF table

Note : If there are direct selections (i.e., no RKFs) used in the rows/columns of the query, you can skip Step 5 & 6 and proceed directly to Step 7.

Step 5: Again, in the RSZELTXREF table, enter TELTUID (from step 4) in the field SELTUID and execute the table.Screenshot 5 : Output of RSZELTXREF table

Repeat Step 5 until the RSZELTXREF table returns zero entries.

Step 6: Collect all TELTUID values from the previous steps into an Excel sheet and remove any duplicates.Screenshot 6 : List of all TELTUIDs from all steps

Step 7: Go to the RSZRANGE table and enter the TELTUID values (from Excel) into the SELTUID field. Execute the table to retrieve the selection details used in the rows and columns.Screenshot 7 : Selection details

Step 8: Open the RSZELTDIR table and enter the same TELTUID values (from Excel) into the SELTUID field. Execute the table to get the technical names and descriptions of the elements.Screenshot 8: Technical names and descriptions of the elements

Step 9: Download the outputs from Step 7 and Step 8 into Excel. Use the VLOOKUP formula to match and enrich the selection data from Step 7 with the descriptions from Step 8 Screenshot 9 : Final output with all required details

Conclusion : In complex SAP BW/BEx queries, especially those used in financial reports with numerous rows and columns, manually identifying selection criteria in Restricted Key Figures (RKFs) is inefficient. By leveraging backend BW tables such as RSRREPDIR, RSZELTXREF, RSZRANGE, and RSZELTDIR, users/Developers can systematically trace and extract RKF selections. This approach enables efficient analysis in Excel, significantly reducing manual effort and improving transparency in query design.

Happy Learning 😊

Simple understanding of Hierarchies in SAP S/4HANA Embedded Analytics– Part 1 (Basics)

2025-11-21T12:47:55.322000+01:00

Accurate CDS hierarchy modeling and understanding is critical for financial reporting and operational analytics. Without well-defined hierarchies, drill-down analysis and aggregated insights become challenging. This blog demystifies hierarchy concepts in SAP S/4HANA Embedded Analytics and shows how they power SAC,Multidimensiona Reports , AFO and Datasphere scenarios.This blog will give you the basic understanding of Hierarchies in CDS Views (S4 Hana)

What This Blog Covers

Common hierarchy terminologies
Types of hierarchies in CDS Views
Standard hierarchies in S/4HANA
Why custom hierarchies matter

1. Key Terminologies-

Before diving into implementation, let’s clarify the basics:

Root Node : Top-most node in the hierarchy. Has No parent. Signifies the Hierarchy Structure and contains the Hierarchy metadata. A hierarchy can have several root nodes.
Hierarchy Node : Represents a group or element in the hierarchy.
Parent Node : A node that has child nodes beneath it.
Child Node : Belongs to a parent node.
Leaf Node : Lowest node in the hierarchy (end point).
Hierarchy Directory : Stores hierarchy definitions.
Siblings : Nodes sharing the same parent.
Hierarchy Level : Indicates depth of a node in the hierarchy. Levels can be defined as 0,1,2,3 . In S/4 EA change level based hierarchies to Parent child hierarchies .
Recursive Hierarchy: Nodes can reference themselves (e.g., Org Structure). Implemented using self-association in CDS.
Hierarchy Node Texts: These contain the descriptive names or labels associated with the hierarchy nodes, typically derived from the related master data (for example, the name or description of a General Ledger account or Product Hierarchy Description).
Orphan nodes, These are the nodes missing a link to a root. You can choose to ignore them, raise an error, or promote them as alternative roots using annotations like ORPHANS = ROOT

2. Example of a Hierarchy-

Company → Product Category → Product → Variant Shoe Model 1

Example:

Company (ABC Corp) → Root Node -> The top most node in hierarchy (Defined via Hierarchy Directory and Root node has no parent defined)---- To be discussed in details in another Part 2.
Product Category (Footwear) → Child of Company->A Parent Node for Product but this is not the Root node(Since it has Company as a Parent Node).
Product (Shoes) → Child of Product Category->Parent Node for Variant
Variant (Shoe Model 1) → Leaf Node->Lowest Node in the hierarchy

In SAP: For Cost Center or Profit Center hierarchy, Controlling Area could be the root node.

3. Types of Hierarchies in CDS Views-

In S/4HANA Embedded Analytics, hierarchies are modeled using CDS annotations. Most common type:

Parent-Child Hierarchy 🔗 Always recursive. Each node references its parent, forming a tree structure. Example: Cost Center hierarchy where each cost center belongs to a higher-level.

Level-Based Hierarchy 🔗Not supported in S4 Hana Embedded analytics as Analytical engine supports only Parent Child Hierarchy for drill downs and aggregations.

CDS Annotation Example:

@Hierarchy.parentChild:
{ recurse:          {   parent: 'ParentNode',   child:  'HierarchyNode'   },
  siblingsOrder:    {   by: 'SequenceNumber',    direction: 'ASC'   },
  directory:        '_Hierarchy' }

4. Standard Hierarchies in S/4HANA-

SAP delivers several predefined hierarchies:

Cost Center Hierarchy – For controlling and cost reporting
Profit Center Hierarchy – For profitability analysis
GL Account Hierarchy – For financial statements
Product Hierarchy – For material classification
EHS Location Hierarchies – For Environment, Health & Safety compliance

5. Custom Hierarchies-

Business requirements often demand custom hierarchies:

Example: A sales region hierarchy combining geography and product lines.
Implemented using CDS Views by developing a relation between Dimension Views and Hierarchy View.

6. Why Hierarchies Matter?

Enable drill-down reporting in SAC or Fiori Multidimensional Reports/AFO.
Support aggregations at multiple levels
Provide flexibility for planning and analytics

7. Technical Details: Where Hierarchies Are Stored-

HRRP_NODE_N Table: Stores Parent Node info, hierarchy node level details, and relationships between nodes(Example where GL Account/Profit Center/Cost Center Hierarchy details are stored).
HRRP_DIR_N Table: Stores Hierarchy Directory info (name, version, metadata).

👉When you activate or create a hierarchy (standard or custom), these tables are updated.

HRRP_NODE_N = Node-level details (Parent-Child relationships)
HRRP_DIR_N = Directory-level details (Hierarchy header info)

8. Hierarchy Components & Annotations-

A well-defined hierarchy in CDS has multiple views:

Source(Master Data) View: Provides key fields and relationships (Eg GL Account/Cost Center/Product related details).
Hierarchy View: Contains the relationships and parent–child links. Eg - Hierarchy(Child) Node, Parent Node, Node levels etc.
Directory View: Provides metadata about hierarchy variants -- Optional.
Text Views for labeling nodes and directory entries . Eg: GL account and it's text/ Cost center and it's text etc.

Proper annotations (@Hierarchy.parentChild, @ObjectModel.dataCategory: #HIERARCHY) control recursion, sibling order, orphan handling, and directory association

Notes:

Parent–Child Hierarchy: Supported in CDS for analytics; recursive structure.
Level-Based Hierarchy: Not supported in CDS for analytical consumption (only parent–child works for drill-down).
Orphan nodes = Nodes without a parent.
A Parent Node can have multiple Hierarchy Nodes/Child nodes but a hierarchy node cannot have multiple parents
A node can appear under different parents in different hierarchy versions, not in the same hierarchy( It usually refers to alternate hierarchy versions or variants, not simultaneous parents in the same hierarchy. For example:

Hierarchy Variant/Version 1: Region → Country → City

Hierarchy Variant/Version 2: Sales Channel → Country → City.This is managed via Hierarchy Directory.

A CDS hierarchy cannot serve as the underlying source for building another CDS hierarchy.

Next Article (Part 2)

How to activate Standard hierarchies and develop Custom Hierarchies in CDS Views (S4 Hana EA).
How to consume hierarchies in SAC