SAP Data Warehousing solutions as of 2023

Data warehousing is a category of enterprise software that integrates a data from different sources, transform it into a consistent and structured format, and provide users with easy access to the information needed for decision-making purposes.

As of Q2 2023 SAP has three data warehouse solutions depending on its deployment scenarios:

 

A) on-prem & private cloud:

1. SAP HANA SQL DWH (Data WareHousing) – brings SAP HANA platform with loosely coupled tools and its platform services (HANA application, integration, processing and database services), best of breed to build own data models

2. SAP BW/4HANA – packaged data warehousing solution, successor of SAP BW, all DWH services in one integrated repository (modeling, monitoring and managing the DWH)

B) public cloud:

3. SAP Datasphere (formerly SAP DataWarehouse Cloud) – cloud based data warehousing service

 

Into the A) section there would be a place for classic SAP Business Warehouse (SAP BW) up to its latest version 7.5 as well. However, the SAP BW is based on SAP NetWeaver stack that reaches its end of maintenance status. Due to this the latest version of SAP BW – 7.5 has a planned expiration of mainstream maintenance as of Dec 31^st of 2027.

Other perspective can be either from application or native (SQL type) of the Data warehouse. SAP Datasphere and SAP BW/4HANA is application driven solution whereas SAP HANA SQL DWH is native driven type of DWH solution.

Each solution caters to different needs and deployment scenarios, enabling customers to effectively manage and leverage their data assets for improved decision-making and business outcomes.

More information:

BW/4HANA

Datasphere

SQL Data Warehouse

Upport Downport Overview (UDO) tool

SAP as any other software vendor needs to support its software thru its whole lifecycle. This involves also providing code changes introduced in higher-level releases to lower ones. Process like that is so called downporting. There can be a e.g. legal reasons for that.

Downporting is the process of porting an application or software component from a higher version of a platform to a lower version of the same platform. Similarly, there is an opposite process called upporting. It involves porting of software from lower to higher version.

In a world of SAP software, downporting and upporting is done using the UDO tool which simplifies the process of by generating a report which will be saved in the system in the normal deliverable package and be shipped in a SAP note.

The UDO tool is continuation of other tools like Correction Workbench (t-code SCWB), ABAP Split Screen Editor (t-code SE39), Version Management (dev pack SVRS), Note Assistant (t-code SNOTE) etc. It compares active version of the ABAP object in remote system (system that has the feature implemented) with version in the local SAP system (system where the feature is to be implemented aka downported). Then it collects DDIC changes, documentation changes and it prepares a new ABAP program. The ABAP program is usually called UDO_NOTE_X or in BW area RS_UDO_NOTE_X, where X stands for SAP Note number e.g. RS_UDO_NOTE_2367512. The report is called UDO report. The UDO report is published in specific SAP Note on SAP ONE Support portal and it can be downloaded from there. When the UDO report is executed (e.g. in customer system) it takes care of the DDICs and documentation and creates and activates them in the target system.

If there would not be the UDO tool in place all of these activities would need to take place manually. Of course, no one wants to do this job. On one hand, responsible developer may forget to write down all the steps needed. On the other hand, person who is implementing those steps manually may forgot to perform few of them. Therefore, a need to automate such activities is it is obvious.

Technically the UDO tool is implemented by ABAP program called SAP_LOCAL_DOWNPORT_ASSISTANT associated with t-code UDO and it is a part of SAP Software Logistics Toolset.

Enhanced Master Data Update

One of a new BW features that were introduced in BW4/HANA version is Enhanced Master Data Update. It can be enabled for a characteristics (attributes and/or texts) type of Info Objects. Only the characteristics that do have master data is supported. This feature brings a possibility of parallel loading of data to the IO. There are new tables created for the IO in case the feature is enabled. The tables are similar to inbound and active tables like aDSO object has. Like in the aDSO case also here the data is loaded first to inbound table. Upon the data activation the attribute and/or text tables of the IO are updated.

Advantage of this feature is while a huge portions of MD is being loaded and/or from multiple sources. It means that the data can be loaded in parallel. Delta mechanism is also supported.

The feature can be enabled in BW Modeling Tools of SAP Hana Studio on IO maintenance screen on general tab.

Technically the flag is stored in table RSDCHABAS column ENHANCED_MD_UPDATE. Its values referring to domain RSDMDUPDATEENH that has following 2 values:

0        Does not use enhanced master data update

1        Uses enhanced master data update

 

Once the enhanced MD updated is enabled for the characteristics the settings related to that can be maintained in t-code RSDMD_SETTINGS. The t-code refers to class CL_RSDMD_SETTINGS_CTRL and method MAINTAIN_SETTINGS.

In case of issues with the IO activation that error message complains about the Enhanced Master Data Update cannot be used for Char. X due to ... (e.g. message no R7B420, R7B428 etc.) there is an ABAP program RSD_CHA_ADAPT_DEFAULT_ENHMDUPD that fixes those.

 

More information:

Online docu BW/4 2.0

Online docu BW/4 2021

Consuming data from BW or BW/4 in BW based on ODP

In Classic BW systems the scenarios when BW serves a data to other BW systems involves creation of so called export DataSource (DS). That DS is created in source system and it has a naming convention 8*. In other BW system where the DS to be is consumed the export DS is replicated and means afterwards it is visible in the target system. From there on a data flow can be built on topo of that replicated DS.

In case of BW/4 system as target system the export DS are obsolete. There is no need to create the export data source anymore. While leveraging the ODP technology objects from source BW are available in the target DS. There is a large variety of supported objects like aDSO, Composite Providers, former BW Classic objects (infocubes, MultiProviders, Semantically partitioned objects, InfoSets, Query as InfoProviders) and finally InfoObjects as well. In case of the InfoObjects and its attributes, texts and hierarchy are supported within ODP-BW context.

Now how get the data from source BW target one? In the target BW just replicate the ODP-BW context node available BW. That activity is to be done in SAP HANA Studio. While doing it a list of available objects from source BW appears in popup window. From there you just choose the object(s) its data is needed to be loaded to target. Afterwards a newly created DS(s) will appear in the target BW. Their names are the same as the object in the sources just there is a postfix character describing the nature of data for the object:

*$F    - Transaction Data/Facts

*$P    - Master Data/Attributes

*$Q    - Time-Dependent Master Data/Attributes

*$T    - Texts

*$H    - Hierarchies

 

Just to add few more remarks on working with the ODP. Technically when the replication is triggered from target to source BW system there are following Function Modules that are called:

RODPS_REPL_ODP_GET_DETAIL

RODPS_REPL_MODEL_GET_LIST

RODPS_REPL_CONTEXT_GET_LIST

 

There is so called ODP extractor checker that can be used to test the extraction in source system. It is kind of a new RSA3 t-code that checked the extractors in case of classic S-API plug-in based extractor. In ODP based extraction it is an ABAP Program RODPS_REPL_TEST (ODP Replication Test) which serves the same purpose.

In addition, notice that ODP has gone some development are it is recommended to use the latest one, which is ODP Data Replication API 2.0. Version 2.0 is available as of:

SAP_BW 750 SP 0 (incl. former PI_BASIS packages)

DW4CORE 200 SP 0 (incl. former PI_BASIS packages)

 

More information:

Operational Data Provisioning (ODP)

Online docu - Transferring Data from SAP BW or SAP BW/4HANA Systems via ODP (InfoProviders, Export DataSources)

2483299 - BW4SL & BWbridgeSL - Export DataSources (SAP BW/4HANA or SAP Datasphere, BW bridge as Source)

What is a difference SAP RISE vs SAP GROW (GROW with SAP)?

SAP tries to pitch its S/4 cloud solution to its customers very hard for a years. However as per surveys conducted by the SAP User groups like ASUG or DSAG the adoption is not at the level SAP would wish it would be.

Therefore, SAP continues to provide offerings to help customers with their transformation to S/4. It started back in 2021 with SAP RISE followed by this year (March 21^st 2023) Sapphire when another offering – SAP GROW (or Grow with SAP) was introduced.

Let’s look at the both offerings in the nutshell.

The SAP RISE is an offering that combines SAP S/4HANA Cloud public and private edition, accelerated adoption services (e.g. SAP Readiness Check, Custom Code Migration, etc.), SAP Signavio to manage business processes, pre-configured best practices. See more information here.

The SAP GROW is also build on SAP S/4HANA Cloud public edition with the focus on midsize companies where the business processes are more standardized.

The main difference between them is that RISE with SAP is more flexible and customizable, while GROW with SAP is more standardized and out-of-the-box. RISE with SAP targets larger and more complex businesses, and offers both public and private cloud options for SAP S/4HANA. On the other hand GROW with SAP focuses on midsize companies, and only provides SAP S/4HANA Cloud, public edition.

 

More information:

SAP RISE (RISE with SAP) blog

RISE page

RISE online docu

GROW page

SAP Smart Data Integration (SDI) and difference vs Smart Data Access (SDA)

HANA as data management platform needs to connect to other data sources to get a data. There are many integration patterns to follow to enable the connection. There is an ETL processing, real time replication, data integration etc. Each of them has its own advantages as well as disadvantages. With the introduction of SAP HANA Smart Data Integration (SDI) the SAP is pursuing to get the best of some of them.

SAP Smart data integration (SDI) is an extension of SAP HANA Smart Data Access (SDA). The SDA leverages the concept of virtual tables (data federation type of thing). That means a data replication is eliminated by providing a virtual layer that abstracts the underlying data sources. Metadata of tables of the source system are imported as virtual tables into the HANA. On top of the SDA the SDI brings broader set of preinstalled adapters from Data Provisioning Agent (DP Agent) component. The adapters in case of the SDI are no longer part of HANA DB. They run as separate processes in DP Agent component.

The SDI is part of the Enterprise Information Management (EIM) solution of SAP. Its purpose is to connect data sources to the HANA, provision data from them and load the data from them to HANA.

As the SDI brings more functions into the EIM process, some customers are opting for this option. Therefore e.g. in SAP BW area they are migrating the SDA based data sources to the SDI one.

 

SDA is available since SAP HANA 1.0 SPS06

SDI is available since SAP HANA 1.0 SPS09

More information:

SDA

SDI online docu

2400022 - FAQ: SAP HANA Smart Data Integration (SDI)

2180119 - FAQ: SAP HANA Smart Data Access

2600176 – SAP HANA Smart Data Access Supported Remote Sources

Stack-ability of Composite Providers

Composite Providers do have a settings that enables them to be reused in other the Composite Providers. In other words, the settings is describing reusability or stack-ability of the Composite Providers. The settings in available in SAP HANA Studio - BW Modelling tools in Composite Provider maintenance screen under General tab. Composite View is re-usable as PartProvider of other Composite Views.

Technically the settings is implemented in table RSOHCPR, and its field STACKABLE. In case the flag is set, the Composite Providers is type of stacked Composite Provider (STACKABLE = X). The setting is handled in methods like IS_STACKABLE, CHECK_STACKABLE and SET_STACKABLE of ABAP class CL_HCPR_COMPOSITE_PROVIDER.

More information:

Using a CompositeProvider as a Provider in Other CompositeProviders

Scenarios for Using CompositeProviders in CompositeProviders

2271658 - Design Considerations for Composite Provider

SAP background jobs and processes behind transports (CTS)

Transport system of SAP objects is a component that enables the controlled movement of software configurations, developments, and customizations across different systems in a landscape. It ensures deployment of changes from development to testing, quality assurance, and ultimately to production systems.

There are several steps involved while particular objects is being moved. Proper sequence and list of the steps executed depends on what type of objects are present in the transport request (TR).

Some of the ABAP steps are performed in the SAP system. These are:

- ABAP Dictionary activation (A)

- Distribution of ABAP Dictionary objects (S)

- Table conversion (N)

- Matchcode activation (M)

- Import of application objects (D)

- Update of version management (U)

- Execution of XPRAs (R), XPRA = EXecution of PRograms After import  or Executable Program for Repair and Adjustment

 

When there is a transport request being imported into target systems following steps are executed:

Step                                                                     Program (ABAP prg/OS level cmd) executing step

SHADOW_IMPORT()                                              OS cmd: R3trans

DD IMPORT (H)                                                    OS cmd: R3trans

DD ACTIVATION (A)                                             ABAP prg: RDDMASGL

DISTRIBUTION OF DD OBJECTS (S)                       ABAP prg: RDDDIS0L

TBATG CONVERSION OF DD OBJECTS (N)               ABAP prg: RDDGEN0L

tpmvntabs                                                          OS cmd: tp

MAIN IMPORT (I)                                                 OS cmd: R3trans

tpmvkernel (C)                                                    OS cmd: tp

TBATG CONVERSION OF MC OBJECTS (N)               ABAP prg: RDDGEN0L

IMPORT OF SELFDEFINED OBJECTS (D)                  ABAP prg: RDDDIC1L

VERSION UPDATE (V)                                           ABAP prg: RDDVERSL

EXECUTION OF REPORTS AFTER PUT (R)                ABAP prg: RDDEXECL

 

Transport related jobs (RDD*) jobs:

Job/ABAP program RDDIMPDP (or JOB_RDDNEWPP) - a dispatcher (transport deamon) program for transport activities running within NetWeaver/ABAP platform based systems. It receives information from the external transport program (OS level programs) tp and R3trans via table TRBAT. The job is normally scheduled by ABAP program RDDNEWPP.

Shadow import – SAP system upgrade relevant only. It importss the upgrade data into Customizing tables, as well as the transport requests of add-ons, support packages, and languages.

DD import – is a phase where the Data Dictionary (DDIC) objects are imported into the target system during the transport process. The DDIC objects include data elements, tables, views, domains, and other dictionary-related components.

DD activation - Job/ABAP program RDDMASGL - runs Data Dictionary Activation, if there is an object in the TR has Data Dictionary object and it was imported before, during Data Dictionary Import.

DISTRIBUTION OF DD OBJECTS - Job/ABAP program RDDDIS0L – phase where the Distribution tasks related to DDIC objects are performed during the transport process. This phase handles the distribution and activation of DDIC objects across the SAP system landscape. RDDDIS0L runs the report RDDGENBB, if the transport request object list has at least one DDIC object, its DDIC import and DDIC activation already happened and the object has to be adopted on database level. Table structures are changed if necessary.

TBATG CONVERSION OF DD OBJECTS - Job/ABAP program RDDGEN0L - this phase refers to the conversion of DDIC objects during the transport process. It is the conversion from the original system format to a format of the target system.

Tpmvntabs - phase is responsible for updating the database tables related to transport management in the target system. During this phase, the transport tool performs various tasks related to transport management tables to ensure their consistency and synchronization with the transported objects. These tables store information about TR, their status, logs, and other relevant data.

MAIN IMPORT - phase where the actual objects contained in the TR are imported into the target system. Tasks like object integration, object activation, dependency resolution, conflict resolution and post-import activities are executed.

TBATG CONVERSION OF MC OBJECTS - Job/ABAP program RDDGEN0L - this phase refers to the conversion of Modifiable Customizing (MC) objects during the transport process. This phase is responsible for converting the MC objects from the original system format to a format suitable for the target system. Modifiable Customizing objects are system-specific configurations and settings that can be customized by customers. These objects are typically maintained in client-dependent tables and are specific to individual systems. During the transport process, these objects need to be converted to make them compatible with the target system.

Tpmvkernel -

IMPORT OF SELFDEFINED OBJECTS - Job/ABAP program RDDDIC1L – it does import of ADO (Application Defined Objects) from table TRBAT.

VERSION UPDATE - Job/ABAP program RDDVERSL - refers to the process of updating the version information of the transported objects in the target system. This phase ensures that the system recognizes and tracks the correct versions of the imported objects.

EXECUTION OF REPORTS AFTER PUT - refers to the execution of specific reports or programs after the objects contained in the transport request have been successfully imported and applied to the target system. Job/ABAP program RDDEXECL - runs as Method Execution (XPRA), if an application has their own object in the transport object list and it was imported during Main Import, and their application specific method/function/program has to run.

 

Other ABAP programs related to transports:

RDDPROTT - displays the log for a specific transport request. Used by t-code SCTS_LOG -Transport Log Overview.

RDDFDBCK - import feedback process, Message After Exporting or Importing Requests

RDDDIC3L - deleting obsolete or no longer required entries from the transport request buffer in the SAP system.

RDDMNTAB - runs a move nametab, for a new ABAP objects that were imported, their runtime objects have to be put in the active runtime environment.

RDDDIC0L – Exports ADO (Application Defined Objects) objects

RDDDIC1L – Imports ADO objects

RDDDIC3L - Generates ABAP programs and screens

RDDVERSE –Version Management: Version at Export

 

Important tables:

TRBAT - it forms the interface between the transport control program tp and the SAP system. To trigger an ABAP step, tp writes control information to this table. The JOB_RDDNEWPP phase schedules the event-driven background job.

TRBATS - Communication Table for Deployment Control

TRJOB - Job ID (e.g. 07444600) that is running at some point of time in teh SAP systems is entered in this table.

 

More information:

Change and Transport system

2147060 - Import steps not specific to transport request

Semantic Grouping set in a DTP or in TRFN?

Semantic Grouping enables grouping of data based on its semantics into the same data pack that is process by the BW load. In BW classic based systems, this function is normally called the Semantic Grouping whereas in BW/4 based systems it is called Grouped Extraction.

If the function is used, data records are extracted from a source as per a logical key and they processed together. The function can be switched on by selecting particular fields on DTP or in TRFN (Transformation). The DTP part was there since BW 7.0 and availability on TRFN came with BW 7.2

Why there is an option to use the Semantic Grouping / Grouped Extraction in the TRFN level as it is available at the DTP level already? Is there any difference between the DTP and TRFN?

Instead of finding a difference, it is better to looked at it as what they can do if they are combined. There can be following cases:

1. Error handing on the DTP is activated (‘Cancel Request, Track First Incorrect Record, No Update’) only the sources fields of key fields can be selected in the DTP. Grouping uses the intersection of these selected key fields and the fields selected from the transformation for semantic grouping.

2. Error handing is deactivated (‘Cancel Request, Do Not Track Records, No Update’), all the sources fields that were also selected in the transformation can be selected in the DTP. The Grouping is formed from this intersection.

3. For compatibility reasons - similar case as no 2 but no source fields have been selected in the transformation for the semantic grouping, all the source fields can be selected in DTP.

SAP is recommending (see in online doc links below) a selecting fields for grouping at the transformation level.

More information:

Online docu BW 7.3

Online docu BW4/HANA

SAP BW DTIS - Data Transfer Intermediate Storage

SAP HANA license types

There are several license types available for the SAP HANA database. Below is a brief overview of the most common ones:

 

SAP HANA Runtime License: This license allows users to run the SAP HANA database in a production environment. It is available for both on premise and cloud deployments and is typically based on the amount of memory utilized by the database. The runtime license is most likely more purchased database license type. This is also the more restrictive license since customers can only leverage it for SAP applications and the underlying SAP and non-SAP data can only be loaded, exported, and managed via SAP technologies.

 

SAP HANA Full Use License: This license provides full access to all of the SAP HANA features, including data integration, advanced analytics, and development tools. It is typically purchased as an add-on to the SAP HANA Runtime License. The full use license type is less restrictive one. It is because there are less restrictions of SAP HANA Runtime. Organizations can use HANA full use for any combination of SAP, non-SAP, custom, or third-party applications. In addition, no limitations exist on the loading and exporting of SAP and non-SAP data directly in and out of SAP HANA.

 

SAP HANA Platform Edition: This license includes both the SAP HANA Runtime and Full Use licenses, as well as additional tools for data modeling and administration. It is designed for organizations that require a comprehensive data management solution.

 

SAP HANA Enterprise Cloud License: This license provides access to the SAP HANA database via a cloud-based subscription model. It includes both the SAP HANA Runtime and Full Use licenses, as well as cloud-specific features such as automated backups and disaster recovery.

 

SAP HANA Edge Edition: This license is designed for small to medium-sized businesses and includes a subset of the SAP HANA Platform Edition features. It is typically based on the number of users or CPU cores utilized by the database.

 

SAP HANA Express Edition: This license is a free, streamlined version of the SAP HANA database that is intended for non-production use. It includes a limited set of features and is typically used for development, testing, and training purposes. It is a free up to 32GB of use with the ability to purchase more, making it suitable for individuals.

 

The licensing terms and conditions for SAP HANA may vary depending on the specific product and deployment model. SAP clients need to always check with their SAP account manager about appropriate license type for their needs.

 

 

More information:

What type of SAP HANA (License) do you need ?

3247198 - SAP HANA License

Vanilla vs customized SAP systems

Vanilla is the term used when computer software (also other computing related things like hardware) are not customized from their original form, i.e., they are used without any customizations or updates applied to them (see wikipedia).

A vanilla SAP system refers to a standard installation of the SAP software without any additional customizations or enhancements. It is also known as a standard SAP system or a SAP system without any modifications.

When an organization decides to implement an SAP system, they can either choose to use the vanilla SAP system or customize it to meet their specific needs. The vanilla SAP system can be flexible and configurable, in a way that to some extent it meets the requirements of the organization without requiring significant customization. However, it is not uncommon for the organizations to require additional functionality that are not provided by the standard system.

In such cases, the organizations may choose to customize the vanilla SAP system by developing custom programs, reports, and interfaces, or by implementing add-on modules or third-party software solutions. However, customizing the SAP system can be a complex and expensive process that requires significant resources and expertise.

In summary, a vanilla SAP system is a standard installation of the SAP software without any customizations or enhancements. It provides all the standard modules and features that are offered by SAP and can be configured to meet the requirements of different businesses to some extent. However, companies may choose to customize the system to meet their specific needs, although this can be a complex and costly process.

In an era of cloud computing when the organization are moving to the cloud it becomes important to analyze into what extend their SAP installation are customized. Heavy SAP customization can be challenge for the cloud. Mostly because of the customization may not be compatible with the cloud environment or the cloud platform on which the SAP instance is being hosted. In addition, there might be a security and compliance issues, impact on scalability and performance, and maintenance and support challenges. It is important to carefully evaluate the impact of customization when moving SAP to the cloud and plan accordingly to minimize any potential issues.

No Routine (ROUT) objects in BW4 transport of transformations

You may notice that in BW4 based systems transporting of Transformation is simplified. In classic versions of BW there were usually objects like Routine included in the transport requests in case particular Transformation contained them. The objects (OBJECT = ROUT) represent either formula in transformation rules or Start/End/Expert Routine. Such transport requests look like below one:

Routine objects of the Transformations are stored in table RSTRANSTEPROUT (Rule Type: Routine). They still are there in the table in case of BW4 systems.

However, in BW/4 based systems there are no transport entries like that anymore. Reason is that, routines and formulas are embedded with transformation metadata. The table RSTRANSTEPROUT has a column CODE that contains all the code of a particular routine and formula. Because of that the ROUT object are not necessary anymore. This change is in place since SAP BW/HANA 1.0 SP04.

 

More information:

2548884 - Formula handling and transport related problems in BW/4HANA

SAP GUI 8

SAP released a new version of SAP GUI for Windows – version 8 on 20 Jan 2023. It is the first version that is 64-bit version that is delivered along 32-bit version. While installing the version 8 on WINDOWS OS 64-bit user needs to decide which version of the GUI will be installed. Parallel install of both versions the 32 and 64 bits is not possible. What are other new features of the new version of SAP GUI? Here I’m mentioning just a subset of new features that I find interesting.

UI point of view:

Themes:

1. Quartz theme got new rendering engine

Usability:

1. Changes to combo box control and the "normal" combo box

2. Tree control has a scrolling indicator now. This will be useful while navigating in BW’s RSA t-code e.g. in Info Object or Process Chain trees. But who is now using the SAP GUI for BW? We all moved to Eclipse based SAP HANA Studio with BW modeling tools, right? :-)

3. Table Control and Dialog box Container supports additional hot keys to enable faster navigation, e.g. CTRL + UP/DOWN/HOME/END.

4. ALV grid support a paste with gaps feature.

5. Branding support: selected branding image per SAP system and client can be defined now.

Technical point of view:

HTML Control based on WebView2 (package that enables to render web content via MS Edge browse rendering engine) supports a browser tabs, which were missing in SAP GUI 77 via browser extension from the Microsoft Edge Add-Ons.

 

More information:

Online docu

3075781 - New and changed features in SAP GUI for Windows 8.00

3218166 - SAP GUI for Windows: Functional differences of the 64-bit version compared to the 32-bit version

2035293 - Known and open issues of SAP GUI for Windows

Package based aDSO activation

In SAP BW, aDSO (advanced DataStore Object) or DSO (DataStore Object) is used as a persistence layer for storing and processing data. In case of e.g. standard DSO a data activation is the process of moving the data from inbound table of the DSO to active table. Data is aggregated accordingly within this process. See Flavors of aDSO object for more details.

In case there is a huge number (10k+) of data loads requests in specific aDSO objects and they all are being activated together there can be problems. Mostly with the respect to memory issues.

This is solved in the newer BW releases (7.50, BW/4HANA 1.0, BW/4HANA 2.0, BW/4HANA 2021) while introducing so called package based activation. This type of the data activation is available when the activation runs over Process chain – by process variant "Clean Up Old Requests in DataStore Objects (Advanced)". Here in this process s package size can be defined for specific aDSO object by a user. If it is not defined, a default package size of 10k is used.

The value itself is stored in table RSPCVARIANT (Generic Variant Storage):

The new way of the package based data activation only works when it is triggered from the in process chains via above mentioned process variant. In case the activation is performed manually, either via t-code RSMNG or via BW/4 Cockpit the activation work in the old way – no package size used.

Technically the activation is performed by a method _OPEN_PROCESS_ACTIVATE of class CL_RSDSO_MNG_ACTION / CL_RSDSO_DATA_TASK) triggered by IF_RSPM_RUNTIME~ACTIVATE_PROCESS (CL_RSPM_RUNTIME) ) and/or FM RSDSO_COMPRESS_REQUESTS.

 

More information:

3108217 - ADSO: packaged activation of requests

3038366 - Activation of requests in an aDSO with a huge number of request fails

Flavors of aDSO object

Watermarks of a BW data target object

Watermarks in BW can be considered as set of an internal counters (so called watermarks) of a technical information of the BW data target. Following are the BW data target objects that may have the watermarks: InfoCube, DataStore Object, Master Data Table and Text Table.

There is an ABAP program (RSPM_ADSO_WATERMARKS) in SAP BW systems that displays the aDSO watermarks like:

·        Number of all requests in aDSO

·        Number of nonactive requests in aDSO

·        Number of deleted requests in aDSO

·        TSN of lowest active request (AQ) in aDSO

·        TSN of high
est active request (AQ) in aDSO

·        AQ Status

·        TSN of lowest active request (AT) in aDSO

·        TSN of highest active request (AT) in aDSO

·        AT Status

·        Count

·        Count AT

·        Data in aDSO must be activated

·        Proc. Type

·        Process ID

·        Datamarted source TSN

·        Requests not datamarted

·        Delta information

 

The program gathers information from many tables like RSOADSO, RSPMREQUEST, RSMDATASTATE_DMO (DMO - DataMart Out), RSMDATASTATE_DMI (DMI - DataMart In) and others. For non BW4 optimized objects like classic infocube there is an function module RSSM_SHOW_WATERMARKS that gathers the watermarks for those objects. 

Selection screen of the report RSPM_ADSO_WATERMARKS:

Example output screen of the same report:

Reassigning of Process Chain’s InfoArea

When I needed to reassign a process chain (PC) between infoareas (IA) I was always struggling. Only way, how to do it I knew; was a drag and drop type of thing in backend t-codes like RSA1, RSPC1, etc. In this way, I moved my PC within the IA’s tree from current IA node to new one. In case a distance between the old and new node was quite big I ended up with moving the mouse until I got into the new IA. And sometimes it took even couple of minutes to get there.

However, with an introduction of BW Cockpit the PC’s IA reassignment gets a lot more easier. There a functionality built in the BW Cockpit to do it very easily. While in Process Chain Editor part of the BW Cockpit there is a Properties button on top right part of the page.

The button shows up a dialog window where an InfoArea can be easily changed to new one among other attributes of the PC. The information of the assigned IA is saved in table RSPCCHAINATTR and column APPLNM.

More information:

How to find out InfoArea for particular BW object type – in BW/4 systems?

BW’s InfoArea vs Application components

BW/4HANA Cockpit

Other posts on Process Chains topic