SAP Community - BW Business Explorer (SAP BEx)

Date difference calculation BW/4

2019-08-04T13:44:10+02:00

Dear All,

Just a simple approach for a requirement to calculate date difference in BEx query without using Formula Variable with Replacement Path.

Eg : We need to find the difference of posting dates( Stock Age ) of material in inventory with posting date of movement type 531/101 as Stock_Out date and posting date of movement type 601/631 as Stock_In.

Create 2 KFs with type date as below.

2. Add to ADSO and map both KFs to posting date with datasource in TRFN.

3. To restrict on Query level, add the KFs in query and create a selection, restrict on Movement type BWART as 531/101 for Stock_Out and 601/631 for Stock_In.

4. Create a new formula and put below ( If not 0 check is not performed, it will show garbage values in report for Stock Age).

IF("[ZSTOCK_OU] Stock-Out Posting Date" <> 0 AND
"[ZSTOCK_IN] Stock-In Posting Date" <> 0; "[ZSTOCK_OU] Stock-Out Posting Date"
- "[ZSTOCK_IN] Stock-In Posting Date"; 0)

5. Report Output :

Regards

Ruma Ghosh

BW Query on CDS cube?

2019-09-06T10:41:13+02:00

After spending some time in S/4HANA Embedded Analytics building Queries in CDS views I came to a realization that it is a painful exercise. While in some (simple) cases it does, indeed, make a good sense, for real analytical queries probably a Query Designer will be a better choice. By Query Designer I mean BEx (t.b. deprecated) or a BW-MT flavor of it. I will use the latter in my examples.

Start

So, where do I start? I start by connecting to an S/4HANA from BW Modeling Tools perspective in Eclipse.

Then we proceed the same way as in BW cases. When creating a new Query we need an InfoProvider. In S/4HANA this will be a generated TransientProvider (which is based on CDS view), so don't forget to tick that checkbox before searching.

OData?

If you are planning on using the query in KPIs or Reports, it is a good idea to check the box for OData service.

Parameters

In many cases our CDS-based "Cube" will have at least some parameters defined. And there is no such thing as optional parameters in the CDS world. So, we need to fill them somehow. Typically, they are prefixed with a P_* in CDS editor. So we need to find all of them in Query Designer and they look like fields! Take them and add to "Filters" part.

Procedure

Go to transaction RSRTS_ODP_DIS, paste the name of TransientProvider you're dealing with (less 2C prefix) and you will find mapping between parameter name and description.

Find the same field by technical name or description and drag to Filters area, map values for them by clicking "Restrict".

Variables

Chances are you are reading this post because you also would like to use BEx variables. So yes, they can be created and yes, you can use standard ones if your CDS model is properly annotated with @Semantics annotations. I hope you know how to create your own variables. So let us see what is needed to be done to use the SAP-delivered ones.

What you need to do is activate BI Content (same old RSA1) for variables. Decide yourself if it hurts to have all 2000 of them activated...

And voila! They're visible in Query Designer

From this point on, Query build is no different than creating in on e.g. CompositeProvider

Cheers,

Dmitry Kuznetsov

BI Consulting

SAP Analytics Cloud & Currency Conversion (Part 1)

2019-09-12T21:49:15+02:00

Some of you might have the need to create a currency conversion in SAP Analytics Cloud because the backend doesn't provide all the required information. In such a scenario we can easily create a Currency Translation table in SAP Analytics Cloud and then leverage the information to allow for a Currency Conversion in our stories.

For SAP Analytics Cloud to be able to provide the ability to translate data from one currency to another, you will have to configure the source currency in your data, as well as you will have to setup the Currency Translation table with the details on the valid period and the translation details.

For our example we will use a relatively simple data set and we will configure the source currency in the model in SAP Analytics Cloud.

You can download the source file for this exercise following this URL:

https://sapanalyticscloudbook.com/sample-stories and the file name is
Mastering_SAP_Analytics_Cloud_chapter09_DataSource004.xlsx

Our source data contains a dimension for an Order ID, an Order Date, a dimension for the Country, and a dimension for the Currency as well as a measure for the Order Value.

Figure 1: Source Data

Now lets create the necessary model.

Logon to your SAP Analytics Cloud tenant.

Navigate to the Home menu.

Select the menu Create Model.

Select the option Import a file from your computer.

Click Select Source File.

Point to the downloaded file for this exercise.

Ensure the option Use first row as column headers is enabled.

Click Import.

Figure 2: Imported Data

Select the column header for Order Date.

Ensure the Type is set to Date Dimension and the Date Format is set to MM/DD/YYYY.

Ensure the Order ID column is configured as Generic Dimension.

Select the column header for column Country.

Set the Type to Organization.

Click Add Dimension Attributes.

Select the option Currency.

Select column Currency as the Currency Attribute.

Select the column header for Order Value.

Ensure Order Value is configured as Measure.

Click Create Model (bottom right).

Confirm the message by clicking Create.

You will be asked to select a folder.

Select a folder, enter a name and description.

Click OK.

Figure 3: Data Management

Use the disk symbol in the General menu to save the changes.

Navigate to the Home menu.

Select the menu Create • Currency.

Select the option New Currency Conversion Table.

Enter CurrencySample as Name and Description.

Click Create.

Our sample data has values for January 2019 to July 2019 for the currencies USD, EUR, and CAD. Our Currency Translation table will need to have entries to cover the timeline as well as those currencies as source and target currencies.

Enter the following entries:

Source Currency	Valid From	Target Currency	Exchange Rate
USD	2019.01.01	EUR	0.88
USD	2019.01.01	CAD	1.31
EUR	2019.01.01	USD	1.14
EUR	2019.01.01	CAD	1.49
CAD	2019.01.01	EUR	0.67
CAD	2019.01.01	USD	0.76

Table 1: Currency Translation

Use the disk symbol in the toolbar to save the changes.

Navigate to the Home menu.

Select the menu Browse Files.

Navigate to the folder where you saved the previously created model.

Open the model.

Select the option Model (top left).

Navigate to the General menu in the toolbar.

Figure 4: Menu General

Open the Model Preferences.

Navigate to the area Currency.

Figure 5: Currency Preferences

Enable the option Currency Conversion.

Ensure the Currency Dimension is set to Country.

Set the Currency Rates Table to the CurrencySample table.

Set the Date Dimension to Order Date.

Click OK.

Save the changes to the model.

Select the option Model (top left).

Now click on the Account dimension.

Select the entry Order Value.

In the Details panel on the right-hand side scroll down to the area Formatting.

Ensure the option Units & Currencies is set to Currency.

Figure 6: Formatting

Navigate to the menu General

Save the changes to the model.

In the last few steps we create a model and uploaded data with values for three different currencies. We also created a currency translation table and enabled the currency conversion in the model. We have now all the information, so that we can create a story in the next set of steps and use the newly modeled information.

SAP Analytics Cloud & Currency Conversion (Part 3)

2019-09-13T17:10:31+02:00

In part 1 and part 2 we reviewed the option to create a model and a currency conversion table in SAP Analytics Cloud.

.... but what if you are a customer using SAP Analytics Cloud in combination with SAP BW or SAP BW4HANA and you have already done all the modelling for your currency conversions in BW / BW4HANA and all what you would like to do, is to simply re-use it ?

Yes - that's exactly what you should be doing and what SAP Analytics Cloud is offering you as an option.

So lets assume we created a table in SAP Analytics Cloud based on an BEx Query and our table shows the measures Profit and Sales Revenue broken down by Country.

In SAP Analytics Cloud - available in Edit Mode as well as in the View Mode - we can now open the context menu for the table (see image below) and we can use the menu option "Select Conversions".

The "Select Conversions" menu then will show the classic menu to choose your Target Currency and the Conversion Type and you can choose from the options that you already created in BW / BW4HANA.

Important, this does not require any specific setting in the BEx Query nor does it require variables for the Currency Conversion.

After we selected the Target Currency - in this example EUR - and the conversion type, our table is updated and now shows the values converted into EUR.

Not only is the table offering the capability, but also the charts are providing the same functionality - as shown below.

Please be aware that the option to use the Currency Conversion on the fly, is something the user can leverage per visualization (Table, Chart) - it is not something that is triggering the currency conversion based on the BEx Query for all visualizations that are based on that particular BEx query, but instead the currency conversion is only used on a visualization by visualization basis.

Some recommendation:

In case you have to guarantee that with a Currency Conversion all visualizations are being updated in a single step, then I would suggest to use BEx Queries with Variables for the Currency Conversion

In case you prefer to have the flexibility to choose the currency conversion per visualization, you can use the approach outlined above.

BEx Query based Fiori App

2019-10-09T13:52:39+02:00

We all know BEx queries have been the traditional Sap BW reporting method to analyze the dataset of the BI system. Info Objects are combined in a query and data is evaluated in a tabular report.

Now Enterprise Reporting can be taken to the next level with the advent of Fiori and SAP UI5. Here are a few points why you should consider creating a custom SAPUI5 app to analyse BI data.

Single query can yield multiple reports

Attractive graphical representations of BI data

On the go slicing and dicing and much more...

Steps to consume Bex queries in Fiori Analytical applications

Create an ODATA compatible BEx Query.

Activate ODATA service for the Query. This ODATA service will expose the BI data.

Develop a custom UI5 app consuming query ODATA Service

And the final output will look something like this :

First chart represents Preventive Maintenance Count by District.

Second chart represents PM Count ACTUAL and PLAN values with respect to district.

Step 1 : Create ODATA compatible BEx Query

There are a few points to remember when creating a query in query designer with the motive of generating an ODATA for the same

Key Figures can go only in the columns section.

Characteristics have to be in rows section.

At least one characteristic in rows.

No additional structures are allowed.

To keep it simple, we are not going to add any filters in query level, rather implement all filter related details (like filter defaults, select options etc) at the app level

- To get the above output, we need to create a query ZFIORI_SAMPLE with

PM Count in Column

District and Value Type in Rows

and then save the query as seen below.

Now go to extended tab of query and select By OData option and hit SAVE again. You can see a message that Gateway service has been generated.

Now change the technical name of PM Count and save.

Step 2 : Activate ODATA service for Query ZFIORI_SAMPLE

Now to see the metadata, replace ?$format=xml with $metadata

Query ODATA Service is ready to be consumed in Fiori App!

Step 3: Develop Custom SAPUI5 app in WebIDE

This step is explained in detail in my next blog post-

https://blogs.sap.com/2019/10/14/simple-sapui5-app-to-display-charts/

Measuring Performance for Real-time BW on HANA Report

2020-03-10T00:23:34+01:00

After upgrading to BW on HANA and Suite on HANA, the scenario for providing real time reports from BW is greatly simplified. (See blog: https://blogs.sap.com/2019/12/13/cds-based-data-extraction-part-i-overview/). Even with HANA everywhere, you could run into performance issues. For complex ABAP CDS models that combine several other ABAP CDS views, the first step is to find which included view is the root cause of the performance issue. This blog may help you in identifying the component CDS view that maybe resulting in overall poor performance. There are several blogs on best practices for ABAP CDS design.

System Landscape

1. BW 7.5 SPS16 on HANA
2. Suite on HANA ECC EHP 08
3. Business Objects 4.2 SP6 with Lumira Server Add-on

Reporting Scenario

A typical real time reporting scenario can be setup with ABAP CDS views in ECC that is the source for BW open ODS and BW query. Here are the detail steps:

You have created a model with several ABAP CDS views to fulfill real-time reporting needs. The ABAP CDS view are combined in a Consumption ABAP CDS view with @analytics dataExtraction and dataCategory annotations

BW on HANA system has a source system of type ODP – ABAP CDS context pointing to ECC system. Let us assume that the connection uses ALEREMOTEBW as userid

You have created a datasource DS1 in BW that points to the ABAP CDS consumption view

You have created an open ODS view OD1 pointing to DS1 data source. Some of the fields in OD1 are identified by existing infoobjects in BW

You have created a composite provider CP1 in BW on top of open ODS view OD1

You have a query Q1 on composite provider CP1

End users access query Q1 from Lumira Generic analysis in Business Objects and you would like to evaluate query performance.

Measurement Setup

1. Execute Lumira Generic analysis to execute the query Q1. I used a BW OLAP connection in Business Objects to connect to the BW query. Navigate to the step for which you would like to measure performance

2. Using ST05 in SAPGUI, activate SQL trace with filter in Suite on HANA. Set userid ALEREMOTEBW in the filter

3. Execute the reporting step in Lumira

4. Deactivate trace in Suite on HANA

5. Display captured trace

6. Select the row that gives duration of the select statement on the ABAP CDS view and select

Display Execution Plan For Recorded Statement

7. SQL statement and its execution plan is displayed. A user friendly way to display the plan data is in the HANA Modeler perspective of Eclipse or HANA Studio. Use the Execution trace button in the toolbar to save the trace file on your local file system.

8. Open the file saved in the previous step in Eclipse HANA Modeler perspective. Select Executed Plan to display a graphical representation of how the result set was built and which components of the ABAP CDS view model took how much time.

9. Execution times are displayed

Getting BEx query ID in customer exit for authorization variables

2020-05-29T17:30:36+02:00

Introduction:

The importing parameter "I_S_RKB1D"(query attribute) is not getting filled for authorization variable(I_STEP=0) in the FM "EXIT_SAPLRRS0_001"(FM for customer exit variable). Recently I have faced this issue in our system and came up with a workaround and thought to share it so that it will be helpful for someone who is having the same issues.

Problem Statement:

In customer exit/BAdI for BEx Variable, we often have requirements to get the query related attributes (e.g., ID of the query) so that we can mold our code accordingly. We already have an importing parameter(I_S_RKB1D in case of customer exit) for the query attributes in the FM/Class of the Customer exit/BAdI respectively. The importing parameter works fine for customer exit variables for I_STEP=1 and 2(work fine in the sense, the query id is filled in the imparting parameter). However, for authorization variables(that is when the value of I_STEP is 0), the values are not filled in the query attributes and remain blank.

Below screenshot for reference. We can see the variable "I_VNAM" which have the value for authorization variable name, "I_STEP" which have the value "0" which is for authorization check. We can see the value of the variable "I_S_RKB1D-COMPID" is empty, which should have the value of the query being run.

(The above screenshot is from the function module "EXIT_SAPLRRS0_001" which belongs to the customer exit "RSR00001"-BI: Enhancements for Global Variables in Reporting).

We can see in the below screenshot, the value of I_STEP is "2" and the query id is populated successfully in the variable "I_S_RKB1D-COMPID".

So, to summarize the issue, the query ID is not getting populated for Authorization Variable (I_STEP=0) but, it is working fine for the customer exit variable(I_STEP =1 or 2).

Proposed Solution:

There is a standard class "CL_RSBOLAP_SELECTION_OBJECT" which is responsible for calling the customer exit/BAdI for authorization/customer exit variable of BEx. The class has an attribute "IF_RSBOLAP_MD_SELECTOR~N_S_COMPKEY" which stores the query attributes of the query which is being run.

So, we can take the help of the "static attribute" of Object-Oriented Programing. We will create a custom class and create a static attribute in the class for the query id. We set the value of query attribute from this class using a "Pre-exit" in the method. Then inside the customer exit/BAdI, we can use our custom class to get the query Id.

Those who are new to Object-Oriented programming, static attributes are the attributes of the class which are not associated with the object of the class directly and exists on per class basis. Which means, there will be only one instance of the attribute for one class and these attribute can be accessed without creating the object of the class. For more information, please refer to the below link.

https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-us/abapclass-data.htm

As mentioned already, we will be creating a pre-exit in the class of the method. Pre-exit is nothing but the enhancement technique, where we can associate our code to the class which will be called automatically by the system whenever that particular method is called anywhere. As this is the pre-exit, so our code will be called followed by the code of the standard method. For more information, please refer to the below link

https://wiki.scn.sap.com/wiki/display/ABAP/Enhancement+Framework+-+Class+Enhancements+-+Pre-exit,+Post-exit+and+Overwrite-exit+methods+-+Concept+and+Simple+Scenarios

So, let's start.

Step 1: Creation of custom class

Let's create a custom class "ZCL_BW_QUERY_NAME". This class will be used to get the Query Id. This class will have below component:Attribute:

MV_QUERY_ID - To store the query Id

Methods:

SET_QUERY_ID - Sets the query ID - This will be used in the Pre-exit of the method of class "CL_RSBOLAP_SELECTION_OBJECT" to set the value

GET_QUERY_ID - Gets the query ID - This will be used in customer exit/BAdI to get the query id

Method: SET_QUERY_ID

  METHOD set_query_id.

    "Set the query id

    mv_query_id = im_v_query_id.

  ENDMETHOD.

Method: GET_QUERY_ID

  METHOD get_query_id.

    "Return the query id

    rt_v_query_id = mv_query_id.

  ENDMETHOD.

Step 2: Creation of pre-exit for setting the value of Query in the custom class

To create the Pre-exit go to the class "CL_RSBOLAP_SELECTION_OBJECT" in class builder(t-code: SE24) and click on "Class--> Enhance" in the menubar.

If you have already an enhancement implementation, then the created enhancement implementation will be shown in the pop-up. Select the implementation to proceed. In my case, there is no existing implementation, so I will go ahead and create one.

Once the Enhancement Implementation is created, place the cursor on the method "CREATE_OLAP_OBJECT". Then create a pre-exit method.

Please click on "Yes" in the pop-up if the pop-up is displayed.

Now click on the button shown in "Pre-exit" column of the method "CREATE_OLAP_OBJECT".

Please add below code inside the pre-exit of the method method

METHOD IPR_ZEHN_QUERY_DETAILS~CREATE_OLAP_OBJECT.

*"------------------------------------------------------------------------*

*" Declaration of PRE-method, do not insert any comments here please!

*"

*"methods CREATE_OLAP_OBJECT

*"  importing

*"    !I_AUTHCHECK type RS_BOOL

*"  raising

*"    CX_RSBOLAP_UNKNOWN_DATA_PROV .

*"------------------------------------------------------------------------*

  "Set the query ID  

  zcl_bw_query_name=>set_query_id( im_v_query_id = core_object->if_rsbolap_md_selector~n_s_compkey-compid ).

ENDMETHOD.

So, we have created the custom class and set the query Id. We are all done. No kidding. Now we can use our method "GET_QUERY_ID" of our class "ZCL_BW_QUERY_NAME" inside customer exit to fetch the query id.

Step 3: Get the query id in customer exit

Now, let's go our customer exit for BEx Variable to use our class to get the query id. Let's

IF i_s_rkb1d-compid IS INITIAL.

  "Get the query id

  i_s_rkb1d-compid = zcl_bw_query_name=>get_query_id( ).

ENDIF.

We can call the method "GET_QUERY_ID" of the class "ZCL_BW_QUERY_NAME". We can see we get the name of the query in the which is being run. Please note the value of "I_STEP" is "0", which confirms we are dealing with the authorization variable.

Conclusion:

As we saw, we had an issue to get the Query Name for the authorization variable(I_STEP=0). The I_S_RKB1D-COMPID was blank. However, for I_STEP=1 or 2, there is no issues and the variable "I_S_RKB1D-COMPID" is filled correctly. To overcome the issue, we have created a pre-exit in the method "CREATE_OLAP_OBJECT" in the class to set the query id in the custom class "ZCL_BW_QUERY_NAME". Then, we used the class "ZCL_BW_QUERY_NAME" in the customer exit(for BAdI also it will work fine) to get the name of the query. Cheers!

Conversion SAP BW 7.x to SAP BW/4HANA: How to handle missing SAP Exit Variables

2020-06-09T16:43:30+02:00

Update April 2023:

In case you are currently on an SAP BW/4HANA conversion project, happy to announce that around 400 Function Modules belonging to standard content SAP Exit Variables previously shipped with BI_CONT (SAP BW) are now included with SAP BW/4HANA Content Add-On 2.0 SP13 (applicable for SAP BW/4HANA 2.0 and SAP BW/4HANA 2021).

Check SAP Note 3301981 for further information. It is highly recommended to update the BW/4HANA Pre-Checks to at least Revision 22 (SAP Note 3296875 - Revision 22 - PRECHECK)

End of Update April 2023

*****

This technical blog post is for BW consultants who are involved in SAP BW 7.x to SAP BW/4HANA conversion projects.

During a SAP BW/4HANA conversion project the existing content artifacts will be automatically replaced by the new, future-proofed and HANA-optimized objects such as advanced DataStore objects, CompositeProvider and Open ODS views. Before this is done, following the SAP BW/4HANA conversion guide, a code scan report is executed to detect various possible issues. Beside other checks, the code scan report detects standard function modules or programs that are used in the data model, for example by BW Transformations or Exit Variables, that are obsolete and not longer available in SAP BW/4HANA.

How to handle these kind of issues, where obsolete standard function modules and programs are used inside your data model, is generally addressed in SAP Note 2673734.

In this blog post let us focus on problems related to missing function modules called by SAP Exit Variables.

Why are some SAP Exit Variables and their function modules not longer available in SAP BW/4HANA?

In SAP BW and the corresponding BI Content add-ons, there were a very high number of standard SAP Exit variables available. Some of these SAP Exit variables had similar logic as others, e.g. there were five variables providing the last month. At the same time the variables in the classic BI Content for SAP BW did not follow a clear naming convention. This made it hard to find the right variable for a particular reporting use case and many projects ended up creating their own SAP Exit Variables.

With the new standard content for SAP BW/4HANA a new streamlined set of variables following clear naming conventions is introduced to make it easier for content modelers to find the right variable. A full list of the new variables including the definition of the used naming conventions can be found as attachment in SAP Note 2395579.

Naming Conventions for Variables - BW/4HANA Standard Content

What can I do when the function module of a currently used SAP Exit Variable is not longer available in SAP BW/4HANA?

While the new set of variables following a consistent naming convention is helpful for greenfield implementation projects, this certainly comes as a one-time hurdle when doing a conversion project.

To ease the conversion effort, the new BW/4HANA Content SAP Exit Variables with their function modules have been down ported to SAP BW 7.31 / 7.40 / 7.50 and SAP BI Content 737 / 747 / 757 by the SAP Notes

2851061 - New BEx variables for simplification of conversion to SAP BW/4HANA

2857063 - BI_CONT: New BEx Variables to simplify conversion from SAP BW to SAP BW/4HANA

By implementing the SAP Notes, these SAP Exit Variables are available in your SAP BW 7.x system and all you need to do - prior to the conversion - is to replace the previous used BI_CONT SAP Exit Variables by the new variables in the queries.

The list below shows all down ported SAP Exit variables. With assistance of this table, you can lookup for a currently used variable (column 'Replaced Variable') the functional equivalent variable (column 'Variable (new)') that can be used as replacement. To make things more complicated, there are some SAP Exit Variables that dependent on other SAP Exit Variables. As an example the SAP Exit variable 'Current Fiscal Year Period' itself reads the SAP Exit variable 'Fiscal Year Variant'. These kind of dependencies you need to take into account when replacing the SAP Exit variables. To assist you with that, all dependencies are properly documented in the column 'Comment' and in the detailed footnotes below.

Replaced Variable	Variable (new)	Description	Comment	InfoObject
0CD_L14D	0CEIO_CDL14CDCY	Last 14 Days		0CALDAY
0CD_L7D	0CEIO_CDL7CDCY	Last 7 Days		0CALDAY
0CD_LD	0CEPO_CDPDCY	Last Day		0CALDAY
0CDFY	0CXIM_CDFYCY	Current Fiscal Year		0CALDAY
0CDLFY	0CXIM_CDFYPY	Last Fiscal Year		0CALDAY
0CMCMLY	0CXPO_CMCMPY	Current Month (Comparison) Previous Year		0CALMONTH
0CMCQUAR	0CXIO_CMCQCY	Current Quarter		0CALMONTH
0CMCQULY	0CXIO_CMCQPY	Current Quarter (Comparison) Previous Year		0CALMONTH
0CML12CM	0CXIO_CML12CMCY	Last 12 Months Including Current Month		0CALMONTH
0CML12LM	0CXIO_CML12PMCY	Last 12 Months Excluding Current Month		0CALMONTH
0CML3CM	0CEIO_CML3CMCY	Last 3 Months Including Current Month		0CALMONTH
0CMLMLY	0CXPO_CMPMPY	Last Month (Comparison) Previous Year		0CALMONTH
0CMLMON	0CEPO_CMPMCY	Last Month	(10)	0CALMONTH
0DPM_BV0	0FIPO_GRID_WIDTH	Grid Width		0GRID_WIDTH
0F_LASTDTCD_IFPER	0CXSM_LASTCLDTV	Clearing Dt.(Derive last CalDay using Var. 0CIIN_FISCPER)	(6)	0CLEAR_DATE
0F_LASTDTCD_IFPER2	0CXSM_LASTCLDTV_CMP	Clearing Dt.(Derive last CalDay by 0CIIN _FISCPER_CMP)	(7)	0CLEAR_DATE
0F_LASTDTND_IFPER	0CXPM_LASTNDDTV	Net Due Dt.(Derive last CalDay using Var. 0CIIN_FISCPER)	(6)	0NETDUEDATE
0F_LASTDTND_IFPER2	0CXPM_LASTNDDTV_CMP	Net Due Dt.(Derive last CalDay by 0CIIN _FISCPER_CMP)	(7)	0NETDUEDATE
0F_LASTDTPD_IFPER	0CXPM_LASTPDDTV	Posting Dt.(Derive last CalDay using Var. 0CIIN_FISCPER)	(6)	0PSTNG_DATE
0F_LASTDTPD_IFPER2	0CXPM_LASTPDDTV_CMP	Posting Dt.(Derive last CalDay by 0CIIN_ FISCPER_CMP)	(7)	0PSTNG_DATE
0I_BA104	0CXIO_FPYTCPVCY	Cumulated Up To Period (Var. 0CIPM_FISCPER)	(1)	0FISCPER
0I_BA106	0CXIO_FPYTCPVPY	Cumulated Up To Prior FY Period (Var. 0CIPM_FISCPER)	(1)	0FISCPER
0I_CUFQU	0CXIO_FPCQCY	Current Quarter of Fiscal Year		0FISCPER
0I_CUFYE	0CXIO_FPALLPCY	All Periods of Current Fiscal Year		0FISCPER
0I_FPER	0CIIN_FISCPER	Fiscal Year/Period		0FISCPER
0I_FPER2	0CIIN_FISCPER_CMP	Comparison Fiscal Year/Period		0FISCPER
0I_L6MON	0CEIO_CML6CMCY	Last 6 Month Including Current Month		0CALMONTH
0I_PRFQU	0CXIO_FPPQCY	Previous Quarter of Fiscal Year		0FISCPER
0I_PRFYE	0CXIO_FPALLPPY	All Periods of Previous Fiscal Year		0FISCPER
0LQUART	0CXIO_CMPQCY	Last Quarter		0CALMONTH
0P_AUGDT	0CXPM_DATE_KEY_CLEAR	Key Date for Clearing Date	(3)	0DATE
0P_BA101	0CXPO_FPCPVPY	Previous Year Period (Var. 0CIPM_FISCPER)		0FISCPER
0P_CHAEX	0CXPM_CHRT_ACCTS	Determine Chart of accounts		0CHRT_ACCTS
0P_CSDT2	0CIPM_DATE_KEY_CMP	Key Date for Comparison		0DATE
0P_DATE_OPEN	0CEPM_DATE_OPEN	Open on Key Date / Default System date		0DATE
0P_FI_DOCSTAT_OPEN	0CIPO_FI_DOCSTAT_NI	Item Status Open (No Input)		0FI_DOCSTAT
0P_FPER	0CIPM_FISCPER	Fiscal Year/Period		0FISCPER
0P_FVAEX	0CXPN_FISCVARNT	Fiscal year variant		0FISCVARNT
0P_KEYDT	0CEPM_NETDUEDATE	Key Date for Due Date Analysis		0NETDUEDATE
0P_SIMD1	0CIPM_UC_SIM_ID1	Simulation ID 1		0UC_SIM_ID1
0S_1ST_QUART	0CXPO_CQQ1CY	First Quarter of Current Year		0CALQUARTER
0S_CLEAR_DATE	0CXSO_CLEAR_DATE	Clearing Date	(4)	0CLEAR_DATE
0S_FC_ERDA	0CESO_ERDAT	Creation Date		0ERDAT
0S_FI_DOCSTAT	0CISO_FI_DOCSTAT	Item Status		0FI_DOCSTAT
0S_FI_DOCSTAT1	0CISO_FI_DOCSTAT_NI	Item Status Cleared/Open (No Input)		0FI_DOCSTAT
0S_GL_CLRSTAT	0CISO_GL_CLRSTAT	Clearing Status		0GL_CLRSTAT
0S_NETDUEDATE_L0	0CXIO_NETDUEDATE_G0	Due Date Grid 0	(8)	0NETDUEDATE
0S_NETDUEDATE_L1	0CXIO_NETDUEDATE_G1	Due Date Grid 1	(8)	0NETDUEDATE
0S_NETDUEDATE_L2	0CXIO_NETDUEDATE_G2	Due Date Grid 2	(8)	0NETDUEDATE
0S_NETDUEDATE_L3	0CXIO_NETDUEDATE_G3	Due Date Grid 3	(8)	0NETDUEDATE
0S_NETDUEDATE_L4	0CXIO_NETDUEDATE_G4	Due Date Grid 4	(8)	0NETDUEDATE
0S_NETDUEDATE_L5	0CXIO_NETDUEDATE_G5	Due Date Grid 5	(8)	0NETDUEDATE
0S_PSTNG_DATE	0CXSO_PSTNG_DATE	Posting Date	(5)	0PSTNG_DATE
0S_SIMR1	0CXSO_INVDAT_SIM1	Invoice Data <= Simulation Run 1	(2)	0INVOICEDAT
0T_FIBUCKET0	0TXPO_FIBUCKET0	Due Date Grid 0 - Text	(9)	1TEXT
0T_FIBUCKET1	0TXPO_FIBUCKET1	Due Date Grid 1 - Text	(9)	1TEXT
0T_FIBUCKET2	0TXPO_FIBUCKET2	Due Date Grid 2 - Text	(9)	1TEXT
0T_FIBUCKET3	0TXPO_FIBUCKET3	Due Date Grid 3 - Text	(9)	1TEXT
0T_FIBUCKET4	0TXPO_FIBUCKET4	Due Date Grid 4 - Text	(9)	1TEXT
0T_FIBUCKET5	0TXPO_FIBUCKET5	Due Date Grid 5 - Text	(9)	1TEXT
none (new)	0CXIO_CDCMCY	Current Month		0CALDAY
none (new)	0CXIO_CDCQCY	Current Quarter		0CALDAY
none (new)	0CEIO_CDN365CD	Next 365 Days		0CALDAY
none (new)	0CXIO_CMPQPY	Last Quarter (Comparison) Previous Year		0CALMONTH
none (new)	0CXPO_CQCQPY	Current Quarter of Previous Year		0CALQUARTER
none (new)	0CXPO_FYPY	Previous Fiscal Year		0FISCYEAR

(The table above can be also found in SAP Note 2857063)

(1): 0CXIO_FPYTCPVCY, 0CXIO_FPYTCPVPY

The new SAP Exit Variables read selection values from variable 0CIPM_FISCPER. The functional equivalent BI_CONT classic variables 0I_BA104 and 0I_BA106 read values from variable 0P_FPER.

Therefore, if you replace 0I_BA104 by 0CXIO_FPYTCPVCY or 0I_BA106 by 0CXIO_FPYTCPVPY in a BEx Query, you will need also to replace variable 0P_FPER by 0CIPM_FISCPER.

(2): 0CXSO_INVDAT_SIM1

The new SAP Exit Variable reads selection values from variable 0CIPM_UC_SIM_ID1. The functional equivalent BI_CONT classic variable 0S_SIMR1 reads values from variable 0P_SIMD1.

Therefore, if you replace 0S_SIMR1 by 0CXSO_INVDAT_SIM1 in a BEx Query, you will need also to replace variable 0P_SIMD1 by 0CIPM_UC_SIM_ID1.

(3): 0CXPM_DATE_KEY_CLEAR

The new SAP Exit Variable reads selection values from variable 0CIPM_DATE_KEY_CMP. The functional equivalent BI_CONT classic variable 0P_AUGDT reads values from variable 0P_CSDT2.

Therefore, if you replace 0P_AUGDT by 0CXPM_DATE_KEY_CLEAR in a BEx Query, you will need also to replace variable 0P_CSDT2 by 0CIPM_DATE_KEY_CMP.

(4): 0CXSO_CLEAR_DATE

The new SAP Exit Variable read selection values from variables 0CISO_GL_CLRSTAT, 0CISO_FI_DOCSTAT, 0CISO_FI_DOCSTAT_NI, 0CEPM_DATE_OPEN. The functional equivalent BI_CONT classic variable 0S_CLEAR_DATE reads values from variables 0S_GL_CLRSTAT, 0S_FI_DOCSTAT, 0S_FI_DOCSTAT1, 0P_DATE_OPEN.

Therefore, if you replace 0S_CLEAR_DATE by 0CXSO_CLEAR_DATE in a BEx Query, you will need also to replace the four variables 0S_GL_CLRSTAT, 0S_FI_DOCSTAT, 0S_FI_DOCSTAT1 and 0P_DATE_OPEN by 0CISO_GL_CLRSTAT, 0CISO_FI_DOCSTAT, 0CISO_FI_DOCSTAT_NI and 0CEPM_DATE_OPEN.

(5): 0CXSO_PSTNG_DATE

The new SAP Exit Variable read selection values from variables 0CISO_GL_CLRSTAT, 0CISO_FI_DOCSTAT, 0CISO_FI_DOCSTAT_NI, 0CIPO_FI_DOCSTAT_NI 0CEPM_DATE_OPEN. The functional equivalent BI_CONT classic variable 0S_PSTNG_DATE reads values from variables 0S_GL_CLRSTAT, 0S_FI_DOCSTAT, 0P_FI_DOCSTAT_OPEN, 0S_FI_DOCSTAT1, 0P_DATE_OPEN.

Therefore, if you replace 0S_PSTNG_DATE by 0CXSO_PSTNG_DATE in a BEx Query, you will need also to replace the five variables 0S_GL_CLRSTAT, 0S_FI_DOCSTAT, 0P_FI_DOCSTAT_OPEN, 0S_FI_DOCSTAT1 and 0P_DATE_OPEN by 0CISO_GL_CLRSTAT, 0CISO_FI_DOCSTAT, 0CISO_FI_DOCSTAT_NI, 0CIPO_FI_DOCSTAT_NI and 0CEPM_DATE_OPEN.

(6): 0CXPM_LASTNDDTV, 0CXPM_LASTPDDTV, 0CXSM_LASTCLDTV

These new SAP Exit Variables read selection values from variables 0CIIN_FISCPER and 0CXPN_FISCVARNT. The functional equivalent BI_CONT classic variables 0F_LASTDTND_IFPER, 0F_LASTDTPD_IFPER and 0F_LASTDTCD_IFPER read values from 0I_FPER and 0P_FVANT.

Therefore, if you replace 0F_LASTDTND_IFPER by 0CXPM_LASTNDDTV, 0F_LASTDTPD_IFPER by 0CXPM_LASTPDDTV and/or 0F_LASTDTCD_IFPER by 0CXSM_LASTCLDTV in a BEx Query, you will need also to replace the two variables 0I_FPER and 0P_FVANT by 0CIIN_FISCPER and 0CXPN_FISCVARNT.

Note: The used variable for fiscal variant 0CXPN_FISCVARNT (new) is defined now as a SAP Exit variable whereas 0P_FVANT (classic BI Content variable) is defined as an user input variable.

(7): 0CXPM_LASTNDDTV_CMP, 0CXPM_LASTPDDTV_CMP, 0CXSM_LASTCLDTV_CMP

These new SAP Exit Variables read selection values from variables 0CIIN_FISCPER_CMP and 0CXPN_FISCVARNT. The functional equivalent BI_CONT classic variables 0F_LASTDTND_IFPER, 0F_LASTDTPD_IFPER and 0F_LASTDTCD_IFPER read values from 0I_FPER2 and 0P_FVANT.

Therefore, if you replace 0F_LASTDTND_IFPER2 by 0CXPM_LASTNDDTV_CMP, 0F_LASTDTPD_IFPER2 by 0CXPM_LASTPDDTV_CMP and/or 0F_LASTDTCD_IFPER2 by 0CXSM_LASTCLDTV_CMP in a BEx Query, you will need also to replace the two variables 0I_FPER and 0P_FVANT by 0CIIN_FISCPER_CMP and 0CXPN_FISCVARNT.

Note: The used variable for fiscal variant 0CXPN_FISCVARNT (new) is defined now as a SAP Exit variable whereas 0P_FVANT (classic BI Content variable) is defined as an user input variable.

(8): 0CXIO_NETDUEDATE_G0, 0CXIO_NETDUEDATE_G1, 0CXIO_NETDUEDATE_G2, 0CXIO_NETDUEDATE_G3, 0CXIO_NETDUEDATE_G4, 0CXIO_NETDUEDATE_G5

These new SAP Exit Variables read selection values from variables 0CEPM_DATE_OPEN and 0FIPO_GRID_WIDTH. The functional equivalent BI_CONT classic variables 0S_NETDUEDATE_L0, 0S_NETDUEDATE_L1, 0S_NETDUEDATE_L2, 0S_NETDUEDATE_L3, 0S_NETDUEDATE_L4 and 0S_NETDUEDATE_L5 read values from 0P_DATE_OPEN and 0DPM_BV0.

Therefore, if you replace 0S_NETDUEDATE_L0 by 0CXIO_NETDUEDATE_G0, 0S_NETDUEDATE_L1 by 0CXIO_NETDUEDATE_G1, 0S_NETDUEDATE_L2 by 0CXIO_NETDUEDATE_G2, 0S_NETDUEDATE_L3 by 0CXIO_NETDUEDATE_G3, 0S_NETDUEDATE_L4 by 0CXIO_NETDUEDATE_G4 and/or 0S_NETDUEDATE_L5 by 0CXIO_NETDUEDATE_G5 in a BEx Query, you will need also to replace the two variables 0P_DATE_OPEN and 0DPM_BV0 by 0CEPM_DATE_OPEN and 0FIPO_GRID_WIDTH.

(9): 0TXPO_FIBUCKET0, 0TXPO_FIBUCKET1, 0TXPO_FIBUCKET2, 0TXPO_FIBUCKET3, 0TXPO_FIBUCKET4, 0TXPO_FIBUCKET5

These new SAP Exit Text-Variables read selection values from variables 0CEPM_NETDUEDATE and 0FIPO_GRID_WIDTH. The functional equivalent BI_CONT classic variables 0T_FIBUCKET0, 0T_FIBUCKET1, 0T_FIBUCKET2, 0T_FIBUCKET3, 0T_FIBUCKET4 and 0T_FIBUCKET5 read values from 0P_KEYDT and 0DPM_BV0.

Therefore, if you replace 0T_FIBUCKET0 by 0TXPO_FIBUCKET0, 0T_FIBUCKET1 by 0TXPO_FIBUCKET1, 0T_FIBUCKET2 by 0TXPO_FIBUCKET2, 0T_FIBUCKET3 by 0TXPO_FIBUCKET3, 0T_FIBUCKET4 by 0TXPO_FIBUCKET4 and/or 0T_FIBUCKET5 by 0TXPO_FIBUCKET5 in a BEx Query, you will need also to replace the two variables 0P_KEYDT and 0DPM_BV0 by 0CEPM_NETDUEDATE and 0FIPO_GRID_WIDTH.

(10): 0CEPO_CMPMCY is defined as "Ready for Input", whereas 0CMLMON is not defined as "Ready for Input".

I cannot find the SAP Exit Variable in the list, what can I do?

If your SAP Exit Variable is not included in the list, it is still possible that one of the standard variables can fulfill your requirement. For example you are looking for a SAP Exit Variable that computes the current quarter based on calendar quarter. Although there is not such SAP Exit variable provided by the standard, there is however a standard SAP Exit variable available that restricts the query to the current quarter based on calendar day (0CXIO_CDCQCY) and could be used instead.

For missing SAP Exit variables on time characteristics you may also want to consider Replacement Path variables from variables. With this functionality you can define own variables accessing the value(s) of another SAP Exit variable, with the flexibility to read for example only a subset of the computed variable value (can be used to derive e.g. month from a calendar day SAP-Exit Variable), access the lower range limit (from value) or the upper range limit (to value) in case of an interval variable, and/or working with offsets (e.g. current calendar month -3).

No, there is no other SAP Exit Variable I can use and replacement path variables do not fill my gap. What can I do?

In this case the only option is as discussed in SAP Note 2673734:

"In general, we recommend in such case to copy the missing DDIC and/or ABAP objects to the customer namespace and to adjust the BW objects accordingly. This will then allow you to use the objects in SAP BW/4HANA or transfer them to compatible objects."

Will Analytics Cloud (SAC) put an end to the agony of choice?

2020-08-31T21:35:45+02:00

Since Business Explorer (BEX) Suite was introduced, back in 1998, SAP’s portfolio of Business Intelligence (BI) tools has continued to grow. The first major boost came in 2007 with the acquisitions of BusinessObjects (BO) as well as Outlooksoft (BPC) and their software products. In 2015 the now called Analytics Cloud was introduced enhancing the portfolio once more. By then, however, a point had been reached where it became difficult to keep track. This vast selection of different products lacked a clear roadmap and guidance for SAP customers. And making the right decision for a future proof BI frontend was a hard thing to do given the diversity.

The result: customers started to use a confusing variety of tools. This could be just the BEX suite as it is still in maintenance, a mixture of different BO products or even a mixture of BO and BEX. In addition, and quite understandably, many customers intended to protect their investments and consider every new tool introduction carefully, without knowing if their current tools are future proof and meet their future demand.

Cloud first provides for new direction

Given SAP’s strategy of pushing cloud software and services, it now appears that one of the analytical frontends could outshine the others. Analytics Cloud (SAC) is the product, which introduces future improvements, very frequent enhancements and bug fixing. Today already, the most common use cases like standard reporting, dashboards, planning or ad hoc analytics are covered by SAC. The tool itself, from our experience, seems a lot more intuitive, especially compared to BO Web Intelligence or Lumira. Clearly, SAP has learned a lesson and again shows better guidance in terms of choosing the right analytics frontends. Since 2020 SAP Analytics Cloud features a new add-in for Microsoft Excel, which also works with web-based versions of the Office suite. It seems, that SAP now succeeds in consolidating the BEX and BO products and moving them to a modern future-proof environment.

Possible migration paths

In many blogs and SAP notes there are hints, that Analytics Cloud is the recommended successor of the above-mentioned products. So, the ultimate question no longer seems to be ‘Which tool to choose’ but ‘When and how to migrate’.

The following matrix shows a high-level overview of possible migration scenarios. It does not cover every detail but should give some hints on risks and chances.

	Analytics Cloud	SAC Excel add-in
BEX
Web Application Designer	Simple applications can be migrated to SAC; complex applications can be rebuilt with SAC Application Designer, which offers scripting capabilities	-
Analyzer	Excel based analytics could be moved to a web-based approach; this would reduce maintenance costs, especially when updating	Simple and intermediate analytic scenarios should already be covered; complex workbooks with heavy use of scripting need to be checked; a solution might be to rebuild them with SAC application designer
Query Designer	Queries don’t need to be adapted; SAC can read BW queries; in some cases, it is sensible to directly access Composite Providers	Queries don’t need to be adapted; SAC can read BW Queries; in some cases, it is sensible to directly access Composite Providers

BusinessObjects		-
Web Intelligence	Simple applications can be migrated to SAC; complex applications can be rebuilt with the SAC Application Designer, which offers scripting capabilities	-
Lumira	By now there is no way to migrate or import Lumira applications into SAC; a migration approach would be similar to Web Intelligence or BEX Analyzer	-
EPM	SAC is integrated with BPC; there is a chance to move reporting and even planning from an excel-based solution to a web-based approach	The SAC Excel add-in allows access to SAC data models and also an integration with BPC; BPC functionality like confirming tasks etc. needs to be checked
Analysis for Office	Similar as for EPM and BEX Analyzer, there is an opportunity to find out if some or even all excel-based applications can be moved to SAC	Most reporting and analytics functionality is already covered; access to data models is now managed via SAC; as soon as SAC is established within a cmpany, excel users can access the same models

Getting prepared

There are a number of prerequisites when migrating to SAC. Most are of a technical nature, e.g. network settings and upgrades to related systems. Existing dashboards and standard reports for example can already be replaced. But switching to a modern tool like SAC creates much more opportunities, especially through the features that enable BI self-service. However, these require more preparation than just technical migrations: organizational changes for example, like establishing a decent key user structure and a well-defined authorization concept.

Further technical improvements with SAC strongly depend on the available data sources. Often, a data warehouse like SAP BW is one of the main data sources, delivering a harmonized data model. To allow self-service analytics for non-technical users, all directly accessible datawarehouse layers should have a clear, easily understandable structure, which is also free from inconsistencies. For instance, the harmonization of master data (like InfoObjects) is a key aspect.

Conclusion

Bottom-line of recent hands-on experience with SAC: the product has matured a lot. As of yet, it offers good coverage of many BI and analytics scenarios and shows constantly growing stability – enough reason for SAP customers to prepare for migration and leave their on-premise frontends behind. Still, introducing SAC in an organization is not a quick and easy task. Many users are in doubt about the move and are seeking advice. With good support from SAP and external partners, adopting SAC is a worthwhile endeavor and a meaningful project to start. Always remember that having top management support is a very decisive factor and starting with a small but well-chosen set of reports and analytic applications is the beginning of a rewarding journey.

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 from 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 Contacts:

m.ezzat Germany CoE, Analytics, Customer Success

carsten.egner Germany CoE, Analytics, Customer Success

CoE North America Contacts:

mandanna.mu CoE Analytics, Customer Success

Selvakumar Sithavan CoE Analytics, Customer Success

CoE Ireland Contacts:

muralikrishnan.e CoE Analytics, Customer Success

Ram Ravi Srinivas CoE Analytics, Customer Success

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

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 )