Admin Cockpit Sanity Check Tool

BI Administration Cockpit is important function within SAP BW system. It basically brings all pieces needed to run BI Statistic together. Even when we talk about the BI (or BW) Statistic we refer to it as BI Administration Cockpit. The cockpit or Statistic is not deployed in many even productions BW systems. It is really a pity as it provides many useful functions.

There is a tool to quickly check what a status of deploying of BI Statistics is. It is available via tcode ACPTOOL (ABAP program RSTCT_ADM_CP_CHECK_TOOL).

Selection screen:

Output Log:

Useful posts:

Difference between DB and BW statistics

Importance of BW objects – BI Admin Cockpit (TA RSTCIMP)

ABAP Statistics Data – BI Technical Content

BEx Query Mass Maintenance tool

In case we need to change some settings of BEx query we either do it in BEx Query Designer or in tcode RSRT. Sometimes we need to setup same settings for several queries. In such a case it would be a lengthy process to perform the same activity all over for multiple queries.

Luckily there is a possibility to perform a mass maintenance of BEx Queries. This function is available within tcode RSRT -> menu: Environment -> Query Mass Maintenance. Once you enter the tool you get a selection screen where you can enter any InfoProvider. Based on the InfoProvider entered all queries associated with the InfoProvider are shown in a list below.

Here you can select particular queries for which you want to do the maintenance. Once confirmed you enter next screen dedicated to the maintenance itself. Over here it is possible to select particular property/ies to be maintained and its/their values. Once saved all queries are maintained.

External SAP HANA view for BW object

As mentioned in my previous post there is a possibility to generate external SAP HANA view for BEx Query. There are also other BW objects which the external SAP HANA view can be generated for. In case a particular BW object has flag enabled than the HANA once it is accessing the BW objects is using this view. This means that whole data access is faster as no BW runtime is used but an external SAP HANA view is used instead.

Basically following are BW object types for which it is possible to use external HANA views:

·         BEx Query, flag is visible at BEx Query Designer->Query Properties->Extended

·         InfoObject, flag is visible at RSA1->Modelling->IO maintenance screen->tab Master Data/Texts

·         InfoProvider (e.g. (a)DSO/Cube/CompositeProvider), flag is visible at RSA1->Modelling->InfoProvider properties at Settings section

However there are many limitations as of now. Always check documentation or documentation  for this feature. The flag is stored in following physical database tables:

RSDDBOBJPROP-HANA_VIEW – in case of InfoCube or InfoObject

RSDCHA or RSDCHABAS field HANAMODELFL in case of InfoObject

RSDCUBE-HANAMODELFL - in case of cube

RSOADSO or RSDODSO field HANA_VIEW – in case of DSO

RSLTIP-HANA_VIEW - in case of Transient Provider

RSOHCPR-HANAMODELFL - in case of HANA CompositeProvider

RSQISET- HANAMODELFL in case of InfoSet

RSPLS_ALVL-HANAMODELFL - in case of Aggregation Level

RSZELTPROP-HANAMODELFL – in case of BEx Query

As the external view is stored in the HANA DB it needs to be able customize in which HANA’s content package the views are stored. The customizing of the HANA content package is available in tcode RS2HANA_VIEW (ABAP program RS2HANA_VIEW_SETTINGS). It is stored under identificator called RS2HANA_PACKAGE and its default value is 'system-local.bw.bw2hana' in the table RS2HANA_VIEW_SET.

Among the content package also other thigs relevant to external view can be customized. It is basically how the HANA privileges are assigned to the HANA user. In case the HANA privileges are assigned to BW’s roles then field RS2HANA_ASSIGN_TYPE has value R in the same table. In addition it can be specified whether the HANA privileges are directly assigned to the SAP HANA user then field RS2HANA_DBMS_USER_MAPPING has value D.

More information:

External SAP HANA view for BW

Automatic HANA View Generation from BW7.4 on HANA system

BEx Query: Release of external access to query

BW queries can be consumed by 3^rd party BI tools for long time. This feature needs to be enabled for particular query. To enable it there are settings that are to be done in BEx Query Designer. Furthermore there are even more settings that can be set in the query level with regards to external access to the query’s data. In this blog post I look at these settings.

Following flags are available in BEx Query Designer under Properties section of the query and on tab called “Extended”.

1. flag 'By OLE DB for OLAP' = Allows to consume the query in external reporting tools that uses the query as data source. Sometimes such a query is it is referred as ODBO provider or just ODBO (Ole DB for Olap. The flag is present physically in following database tables:

RSRREPDIR-RFCSUPPORT - Report supports access using OLAP API

RSZELTPROP-RFCSUPPORT

2. flag 'By Easy Query' = so called Easy Query (EQ) flag. It allows an access of the query for external access as an Easy Query. The EQ is static query with no formatting settings and it can be used as SOAP service. Once this flag is enabled for particular query then it needs to be managed in Easy Query Manager (tcode EQMANAGER) in BW’s backend system. The flag is present physically in following database table:

RSZELTPROP- EQSUPPORT - Query: RFC Publishing as VirtualProvider (yes/no)

3. flag 'By OData' = so called OData Query flag. It allows consuming of the query data by ODATA service. It is also an integration of SAP Business Warehouse with SAP Gateway system where it provides analytic queries of in BW system as BW OData Queries for mobile scenarios. The flag is present physically in following database table:

RSZELTPROP-ODATASUPPORT

Both the EQ and OData techniques are focused on so called lightweight consumption. This means that need SAP Gateway to be used. Easy queries can be used also via SOAP or RFC as REST based services.

The above two techniques are also part of BW’s Open Analysis Interfaces. This is meat with regards to extraction of the data from source systems and analyzing of the data in BW in various reporting front-end tools.

4. flag 'HANASUPPORT' – Means generation of external SAP HANA view for BW object. There are many BW’s objects for which the HANA view can be generated and the BEx query is one of these. The HANA view is not used by BW itself but by SAP HANA natively while accessing the SAP BW. The flag is present physically in following database table:

RSZELTPROP-HANASUPPORT

For assigning the HANA external view flag to other SAP BW objects see here.

Please note that flag no 1 is available for long time and was introduced in BEx Query Designer 7.x. However for flags 2 and 3 there is a prerequisite to run SAP NetWeaver 7.0 BW Front End for GUI 720.

Useful information:

SAP BW Easy Query

SAP Gateway

Open Analysis Interfaces

1598778 - Query property 'Release for External Access by Easy Query'

1601473 - Query property 'Release for External Access by Easy Query'

2103222 - Generation and Transportation of BEx Query with active OData-Flag

Qlikview's SAP connectors

Qlikview is popular BI tool used also by organization running SAP BW systems as frontend tool. As every tool that is used on top of the SAP BW it needs to extract the data from out of the BW and render it to user. To do this Qlikview uses so called SAP Connector.

There are following types of SAP Connector’s delivered by Qlikview:

Connectors for Any SAP systems:        Purpose:

Qlikview SAP SQL Connector                    Connector for any DB table in the SAP system.

QlikView SAP Report Connector                Connector for SAP ABAP reports.

Qlikview SAP Query Connector                 Connector for classic SAP Query.

QlikView SAP Extractor Connector             Connector for DataSources in SAP system .delivered by SAP BW API

Qlikview SAP BAPI Connector                   Connector for remote function modules in SAP systems (so called BAPIs).

Connectors for SAP BW systems:        Purpose:

Qlikview SAP OLAP Connector                  Connector for BW BEx Queries and cubes.

QlikView SAP DSO/ODS Connector            Connector for BW’s objects like DSO/ODS, capable of fetching also metadata of DSO/ODS objects (e.g. DSO’s structure).

Physically the Qlikview SAP Connector is delivered as SAP transport which consists of following development packages:

/QTQVC/QTDEV                  Developmentclass QlickTech

/QTQVC/QTDEV_BW            Qlik development for BW systems

White / Black Lists

In general similar to any other industry or area of people's interests also in terms of SAP we talk about white and black lists.

Basically anything which is on the white list is approved or recognized or just simply speaking it is considered to be safe. On other hand anything which is on the black list is forbidden, unknown or just not safe.

In terms of SAP we can talk similarly here in here about programming objects. It can be also an access to certain objects where there are some objects that can be accessed (while list) and objects to which an access is denied (black list).

Let focus on e.g. RFC function modules. Some of them can be protected by authorization and therefore are on the white list. Access to some other RFC FM can be forbidden and they are put to black list. Usually the RFC FM are protected by authorization object S_RFC.

last update: 07/08/2018

Related information:
Unified Connectivity Framework - UCON

1664340 - Documentation of authorization object S_RFC is unclear

Special characters in Analysis Authorization values

First a brief info on what Analysis Authorization is.

Analysis Authorizations (AAUT) is concept used in BW systems to grant an access to the data in the system for users. This AUT concept is not based on the standard authorization concept of SAP as it is used in SAP transactional systems like ECC. The AAUT concept serves the purpose of users that access query data.

Unlike standard authorization concept of SAP which is based on classic authorization objects the AAUT concept is based on so called Analysis Authorization object. Such an object includes a group of characteristics and there are values defined for these characteristics which an access will be granted to. The AAUT object (or so called authorization objects for reporting) can include any characteristics that are flagged as authorization-relevant characteristics. This flag is available on maintenance screen of the characteristics in RSA1 -> Modeling -> Business Explorer -> Authorization Relevant. Once the flag is enabled AAUT objects for reporting can be generated for the characteristic.

While BW report or query is running by user the system selects the data from infoprovider. Once there is an authorization relevant characteristics part of the data set the system evaluates whether user has enough authorization for the whole data set. Only in case use fulfills the AUT values they the data is displayed.

The AAUT objects are maintained in tcode RSECAUTH (you can jump there also via tcode RSECADMIN). One AAUT object can have multiple characteristic included and each of them can have multiple values against which an access is evaluated. Basically the values can be of two types: flat values or hierarchy values. All operators like EQ, BT, GT, LE etc. are possible.

Now let’s see what different flat values that can be entered here are. Except regular values where the value is precisely spelled out there can be also following ones:

* (asterisk): represents any number of characters

+ (plus): represents exactly one character

: (colon): authorization for aggregated values, serves for purposes of displaying aggregated values (e.g. totals), in case there are two characteristic values tied to different key figures and user is only authorized to see the data for characteristics of one value having Colon in the AAUT object will enable the user to see the total coming from both values of the characteristic.

$ (dollar sign): enables usage of BW variables of type customer exit in authorizations, the variable name is introduced by dollar sign.

Few examples:

I EQ      02                                   //fixed value

I EQ      0TCT_24                           // fixed value          

I CP      A*                                   // patter                

I EQ      $VAR_SECT                       //variable

I EQ      :                                     //for aggregated values

A little about InfoPackage / DTP prefixes and BW data request's prefixes

In this post I try to sum up brief information on topic of different InfoPackage and DTPs prefixes. In addition I’m also providing information on BW’s data request numbers prefixes.

InfoPack prefixes:

ZPAK_* - custom developed InfoPack

0PAK_* - InfoPackage activated from BI Content

0GRU_* - BI Content InfoPackage groups, assignment of InfoPacks into Group is in table RSPAKPOS

0GRU_* - custom InfoPackage groups

PRNR_* - automatic update from the PSA into the data targets

INFO_* - InfoPackage for BW-WHM runtime statistics, used on old BW systems(below version 3.x)

DTP prefixes:

DTP_* - regular DTP, has corresponding DTP request ID with naming convention: DTPR_*     

D* - in general any the DTP ID can start with just D prefix

DTPR_SIMULATION    - not real the DTP run, only debug run of the DTP = debugging DTP

Request numbers prefixes:

- General prefixes:

REQU_* - generic request ID created by run of InfoPackage, any request that can be displayed in tcode RSRQ

DTPR_* - generic request ID created by run of the DTP

REBU_* - rebuilding request, it is not real (independent) request, it is the request that has not yet written any RSSELDONE entry, it cannot be displayed in monitor, because it is only number under which an additional rebuilding monitor log for normal load requests is stored.

APO_R* or APO_* - request for APO Demand Planning data, InfoProvider is switched to transactional behavior

- DSO/ODS relevant prefixes:

ODSR_* - ODS activation request or the request loaded from change log of an upstream ODS object using a "Reconstruction" function

ODSA_* - change log activation prefix

ODSU_* - change log update prefix

- Other request prefixes: 

STOR_* - reversal of a request

ARCH_* - requests generated by Data Archiving Processes (tcode RSDAP)

- Request prefixes not more used anymore (as of BW version 3.0B) prefixes:

MDMT_* - generated by master data maintenance functions of BW

R3RD_* - similar as above

RNDI_* - load of master data or text for characteristic using 'RSNDI API' functions

SPOK_* - looks like it was related to InfoSpoke functions

Shadow InfoPackage

There are a special InfoPackages in the system. They are called Shadow InfoPackages. The shadow infopack is created when BW DataSource objects are activated from the Business Content (BCT). BW system reads the shadow InfoPackages from the table RSLDPIOSH for each DataSource that is to being activated.

Similarly in case of BW is used as a BW content development system, inconsistencies may occur between the A and D versions of the InfoPackage means between the shadow version and version of InfoPackage in cross-reference table RSSHIPDVERS.

All these situations are caused by inconsistencies between the tables RSLDPIOSH, RSLDPIO and RSSHIPDVERS. To remove the inconsistencies there is a SAP standard report which can be used to fix these issues. The report is called RSSM_SHIPDVERS_CLEANUP. It can recognize and corrects these inconsistencies.

When using the report a checkbox "Check Shadow Infopackages' needs to be activated on its selection screen. The report then lists out all Shadow Infopackages along no of records in tables RSLDPIOSH, RSLDPIO and RSSHIPDVERS. By using Repair functionality inconsistencies can be removed.

More information:

onlinedocu

HANA versions / revisions

 Last update:           22.2.2022

In this post I will try to summarize all versions of HANA that are (or were) available per Support Package Stack (SPS) and covering revisions ranges. SPSs and revisions are fixes (corrections) shipped by SAP for the HANA product. SPSs are numbered incrementally starting from 000. They are normally released twice a year.

Meaning of version code:

Version: major_version.minor_SPS.patch/revision.build

A.BC.DEF.GH.IJKLMNOPRS

ABC - indicates major HANA version 1 or 2 currently

DEF - indicates minor HANA version - so called SPS level

GHI - JKL - indicates patch/revision

MNOPRS - indicates build

Examples:

1.00.122.12.1502962396    HANA 1 SPS 12

1.00.100-1.00.109             HANA 1 SPS 10 (every revision between 100 and 109 is SPS10)

 

HANA2 - SAP HANA PLATFORM EDITION 2.0

SAP HANA SPS       Release Date          Note             Revisions Range

SPS 06(12/2021)     03.12.2021             2945239       060 - 061

SPS 05(06/2020)     26.06.2020             2932865       040 - 048

SPS 04(04/2019)      05.04.2019             2656575       010 - 041

SPS 03(04/2018)     06.04.2018             2551355       010 - 033

SPS 02 (07/2017)     26.7.2017               2460914       020 - 024

SPS 01 (04/2017)     12.04.2017             2404375       010 - 012

SPS 00 (11/2016)     30.11.2016             2380257       000 - 002

 

HANA1

SAP HANA SPS       Release Date          Note             Revisions Range

SPS 12 (05/2016)     12.05.2016             2298750       120 – 122

SPS 11 (11/2015)     24.11.2015             2227464       110 – 111

SPS 10 (06/2015)     01.06.2015             2165826       100 - 109

SPS 09 (11/2014)     28.11.2014             2075266       90 - 97

SPS 08 (05/2014)     28.05.2014             2004651       80 - 85

SPS 07 (12/2013)     03.12.2013             1921675       70 - 74

SPS 06 (06/2013)     28.06.2013             1848976       60 - 69

SPS 05 (11/2012)     29.11.2012             1771591       50 - 58

SPS 04 (05/2012)     10.05.2012             1703675       40 - 48

SPS 03 (11/2011)     15.11.2011             1642937       30 - 37

SPS 02 (07/2011)     27.06.2011             1600147       20 - 29

SPS 01 (12/2010)      27.06.2011             N/A               10 – N/A

Initial Shipment Stack         N/A               N/A               N/A

 

 

There are different Revision Types for SAP HANA. The “Revision” refers to packages containing fixes for the SAP HANA core components (like SAP HANA Database, Studio, Clients, AFLs, LCapps, SDA, HWCC tool, etc). Here are different Revision Types:

1. Release to customer (RTC) Revision – new features and fixes, for early adapters and Non-production systems, released every 6 months

2. Standard Revision – incremental fixes, based on latest SPS feature set, for early adapters and Non-production systems, released on demand

3. Datacenter Service Point (DSP) Revision – incremental fixes, based on latest SPS feature set, released every 6 months after having run in SAP production system for 2+ weeks

4. Maintenance Revision – incremental critical fixes only, production systems (targeting planned and unplanned maintenance), released on demand provisioned for previous SPS between RTC and DSP only as of SPS10: provided after DSP for the current SPS

 

There is another term used within release management of SAP HANA. A ”weekstone”. The HANA weekstone is a build generated from source code every week. It is not released for customers and serves only for SAP internal purposes. Tests of the HANA like regressions and other tests related to quality happen on the weekstones. Once the particular weekstone passes all the tests it becomes Revision which is afterwards released to our customers/partners.

 

Useful information:

2115815 - FAQ: SAP HANA Database Patches and Upgrades

2021789 - SAP HANA Revision and Maintenance Strategy

2378962 - SAP HANA 2 Revision and Maintenance Strategy

1999997 - FAQ: SAP HANA Memory

SAP HANA Revision Strategy