BW Background Job - Deletion of Orphaned Entries in Errorstack/Log Job RSBKCLEANUPBUFFER

Another background job that is running in the SAP BW systems is to housekeeping of orphaned entries in DTP’s error stack and execution logs. It is the background job called RSBKCLEANUPBUFFER.

It deletes any existing temporary buffers and error stack data of deleted requests for which this data still exists. The report behind this job is also called RSBKCLEANUPBUFFER. On its selection screen there are dates from/to and check/delete only requests that defines time frame for deletion itself.

More information:

1759601 - P30:DTP:Request temporary storage is deleted too soon

Activating the BW Software Component

As per different operating modes of BW there is a need to activate SAP_BW component in the NetWeaver based systems to indicate that BW is configured/used. There is a dedicated database table that indicates what software components of the NetWeaver are used.  The table is called CVERS_ACT (Active Software Components in the System) and indicator is ACTIVE column. If the ACTIVE columns is set to X the particular component is used within the system.

There is e.g. Function module DELIVERY_SET_ACTIVE_COMPONENT or RS_SET_ACTIVE_COMPONENT_FLAG that sets the ACTIVE column for specific software component.

More information:

Operating modes of SAP BW

Operating modes of SAP BW

In one of my previous blog posts regarding BW client strategy I briefly mentioned a types of the BW system. The type of BW system or let’s say operating mode of the BW defines the scenario which the system is executing and for which it was setup. The SAP BW system can operate in multiple modes.

Most common is Enterprise DataWarehouse mode. It is full blow BW system, running on dedicated server, has its own client as it is running on its own server separated from other SAP systems. The system is capable of loading large scale of data; the data is consumed by different front-end clients. It has set its own client. The component SAP_BW is active in table CVERS_ACT. In the system, there are a repositories of different BW objects like data source, queries, etc. (see TLOGO objects).

Embedded BW mode. The SAP BW functions are automatically available in SAP ERP systems since SAP NetWeaver 7.0. The BW runs in the same server as the ERP thus it is called ‘Embedded BW’. See more details here. Data is loaded usually into separate BW client other than the one for ERP part of the system. The component SAP_BW is active in table CVERS_ACT.

Embedded Analytics mode. Only analytics part of BW is active within the S/4HANA system. Analytical engine of the BW is using CDS views in order to perform OLAP reporting directly on the user data. The component SAP_BW is active in table CVERS_ACT. Separate client is technically not needed but it is advised to have it. There is no datasource repository in such the system.

 

More information:

BW client strategy

What is TLOGO in SAP BW terms?

Embedded BW 1

Embedded BW 2

BW Background Job - DTP Clean Up Job RSBKCHECKBUFFER

Among many other background jobs running in SAP BW system is the RSBKCHECKBUFFER job. This job runs a ABAP program RSBKCHECKBUFFER  that cleans up the DTP Runtime Buffer. What is meant by the DTP Runtime Buffer is a temporary storage of the Data Transfer Process. Basically there are settings for the DTP (like 'Fill Temporary Storage After Following Substep' -> see details here). If those settings are maintained, they represent a retention time for how long the temporary storage should be kept in the BW system.

Now there is a function in the BW system needed that makes sure that those retention periods are fulfilled. The function is represented by the RSBKCHECKBUFFER  job. The job has to be periodically planned. If it is running, it deletes the entries, once the retention time is reached. Similarly, the job handles also the DTPs in the case if the settings of the active version of the DTP do not contain any retention time. Usually it is enough to schedule the clean up job to run every day.

 

More information:

Online docu

Job BI_WRITE_PROT_TO_APPLLOG not running?

Client strategy for SAP BW

While SAP BW system is being installed, a decision needs to be done on a client strategy for the system itself. How to decide which client is to be used as BW Client? One important thing to mention is that SAP BW handles only one client in the particular system (see You can only work in client 001). This is contrary to SAP ERP systems where such the system can have multiple clients (see How to get rid of clients 001 and 066 ?). Sometimes the client strategy is referred by a term Client Distribution. Technically the BW client is stored in table RSADMINA and in column BWMANDT. There are following function modules to work with the BW’s client ID:

·        RS_MANDT_UNIQUE_GET Determine BW Client

·        RS_MANDT_UNIQUE_SET Define BW Client Permanently

As a rule of thumb it is recommended to have BW dedicated client in cases like:

·  If data is physically replicated from SAP application to Embedded BW, both the another SAP app and the Embedded BW runs on the same system

· Organization reasons (data separation due to different companies e.g. holding structure, etc.)

There are several aspects to be considered. One of the major one is depending on what type of BW systems it is. There can be following cases:

1 Standalone BW – a full blow BW system, running on dedicated server, has its own client as it is running on its own server separated from other SAP systems.

2 SAP S/4HANA embedded analytics using ABAP-based CDS and the Analytical Engine (automatically generated transient BEx providers). In case organization is using this scenario heavily for many use cases, it is better to create dedicated client for analytics.

3 SAP S/4HANA BPC Optimized using SAP BPC on PAK models. No separate BW client needed unless (similar to the case above) there will be a use cases combining external data with the S4/HANA data.

4 Embedded BW – BW included in SAP ERP systems since SAP NetWeaver 7.0, see more info here.

4.1 Embedded BW usage creating small customer-specific data models for reporting and planning (incl. BPC on PAK), including external data sources to stage data into the Embedded BW (other SAP system, e.g. other SAP ERP/CRM/etc., stand-alone BW or non-SAP legacy system) – no usage as Enterprise Data Warehouse.

4.2 Embedded BW usage to stage data from the same SAP S/4HANA system - separate client for Embedded BW is recommended. E.g. there are multiple S4/HANA clients (dev, testing, training, etc.) along one client dedicated to the Embedded BW.

More information:

Embedded SAP BW Definition and Positioning

You can only work in client 001

Embedded BW 1

Embedded BW 2

What is embedded BW (part 2)?

I dedicated a blog post to the topic of Embedded BW in past already. However, the topic is quite broad so I decided to write a follow up.

First to sum up a purpose of the SAP Embedded BW (Business Warehouse). It is a data warehousing solution that is integrated within the SAP Enterprise Resource Planning (ERP) system. It allows organizations to collect, consolidate, and analyze data from various sources within the SAP environment, as well as external sources.

As it is “Embedded” BW into NetWeaver based systems (such an ERP (SAP Business Suite, SAP S/4HANA), SAP CRM, etc.) it means it provides a real-time view of an organization's data, enabling decision-makers to make informed business decisions. It provides advanced reporting and analytics capabilities, including ad-hoc reporting, OLAP analysis, and predictive analytics. These capabilities enable users to gain insights into business performance and identify trends and patterns in the data.

One of the key benefits of Embedded BW is that it eliminates the need for separate data warehousing infrastructure and reduces the cost and complexity of managing multiple systems. It is also designed to be scalable, allowing organizations to expand their data warehousing capabilities as their data volumes grow.

However, the Embedded BW just supports processes related to financial planning, consolidation and data analytics but it is not intended to be used as data warehouse solution. For pure enterprise data warehousing (EDW) purpose the SAP BW should be used.

Current version of BW used in the embedded BW SAP BW 7.5 powered by SAP HANA. As per SAP, (see Embedded SAP BW Definition and Positioning document) there are currently no plans to enable SAP BW/4HANA for Embedded BW.

 

More information:

Embedded BW part 1

2935516 - Embedded BW is not intended to be used for data warehousing

2773652 - Recommendations embedded SAP Business Warehouse

1972819 - Setup SAP BPC optimized for S/4 HANA Finance and Embedded BW Reporting (aka Integrated Business Planning for Finance)

BW4 – Parameters of RSADMINA table

I described parameters of table RSADMINA (Control Table That Customer Can Change (Tenant-Specific)) table in my earlier post here. However since introduction of BW/4 systems there are more params in the mentioned table.

 

TLOGO_EXEC_DISAB       TLOGO Types: Automatic Execution Deactivated

 

BW4HANA_SWITCH         SAP BW, Edition for SAP HANA Switch, provides an information about BW4 operating mode.

Possible values:

           unknown (only internal)

0        Add-on not installed

1        Compatibility mode

2        B4H mode

 

TECH_SCOPE                   Operating Scope, so called Data Warehouse mode: Data Warehouse, Embedded BW, and Embedded Analytics

Possible values:

          (NO_BW_SCOPE)

1        Lean Data Warehouse (ANALYTICS_ONLY)

4        BPC Planning only

16      Data Warehouse (DATA_WAREHOUSE)

 

TECH_COMPONENTS        Data element for tech. content component

 

HDI_MODE                       HCPR, IOBJ: Consumption Mode for HANA Native Objects. It checks if HANA DB schema name is equal to ‘_SYS_DI’.

Possible values

0        Repository Version 1 (No HDI Support)

1        Hybrid Support (Repo1 and HDI in parallel)

2        Pure HDI Support (Repo 1 is not supported)

 

ODATA_AUTO_REL           Release OData Service after Generation, whether BW queries are released automatically for OData consumption.

Comparision of RSADMINA table in BW/4 and classic BW systems:

More information:

Parameters of RSADMINA table

DTP ID prefixes

Some time ago I blogged about InfoPackage / DTP prefixes and BW data request's prefixes. That blog post covered most of the InfoPackage and DTP ID prefixes however; I found there are more of them.

 

As there are different types of Data Transfer Processes; similarly there are several DTP ID prefixes that corresponds to those DTP types.

1 DTP_* - Regular DTP ID prefix. So called 'Standard DTP'. This is a case of most of the DTPs is any given BW system. Part identified by asterisk is generated as a random string. Sometimes the standard DTPs are referred as DTPA DTPs.

2 DTPV* - So called 'Virtual DTP' is created during migration to BW/4 systems by ABAP class CL_RSBK_DTP_COLLECTION.

3 DTPT_* - So called 'Transfer DTP' is generated during migration to BW/4 system.  

4 DTPI_* - So called 'Transfer InfoPackage DTP' is generated by replacing first 5 chars of the InfoPackage ID with the prefix 'DTPI_, during migration to the BW/4. Import of InfoPackages (in the case of an remote conversion / transfer), a settings of the InfoPackages for file source systems are not replicated correctly in the DTPs replacing them. The DTPs IDs start with the prefix.

5 RSBC - So called 'Command Package'.

 

Following to different DTP ID prefixes there are below DTP request IDs:

1 DTPR_* - request ID as of Classic BW (pre BW/4 systems)

2 DTPR__* - new request ID as of BW/4 (or BW 7.5) systems, so called Process Transaction Sequence Number (TNS)

3 DTPR_SIMULATION – in case DTP ran in debugging (simulation) mode

 

All these types are stored in data dictionary in Type group RSBC (Constants for the Data Transfer Process).

                      

More information:

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

BW request types: RSSM vs RSPM

My blogs about DTPs

My blogs about InfoPackages