With SAP BW on HANA comes ADSO with new table structures and functions. Compared to the InfoProviders which are used on SAP BW systems not based on HANA, ADSOs have the ability to modify their functions without losing filed data. This also includes a modification of the contents of the tables if the type is changed.
In this process, an ADSO always consists of three tables which are filled and processed depending on the ADSO type. Unused tables are created by the system regardless. Thus, the use in routines, HANA expert scripts etc. is possible but in general not always appropriate.
The following diagram shows the tables of an ADSO with the technical name "SAPBLOG".
In order to ensure a stable implementation when changing the object type, two views named /BIC/ASAPBLOG6 (extraction) and /BIC/ASAPBLOG7 (reporting) are created in the course of activating the ADSO. These relate to the table with the respectively active data and/or the extract table. In this process, the views are automatically updated with a modification of the ADSO type and thus enable a stable loading process without side effects, also in case of adjustments of the model.
The following table shows the different configurations of the ADSO which affect the structure of the views. If a view appears in both columns of the following table, this also includes both SAP BW tables via a UNION function.
This results in the general rule that, regardless of the used ADSO type, a lookup in the ABAP or SQL should always follow the 7 view in order to ensure the smooth functioning of the implementation after a modification of the ADSO type. As all tables are created in each case, a malfunction is not immediately noticed in many cases if the table is not used by SAP BW anymore.
Anyone who wants to have a look at the views should best use SAP HANA studio as the ABAP DDIC is not updated immediately. Thus, possible adjustments are not directly visible there.
The example shows the reporting view of an ADSO with all info objects as key (previously named InfoCube).
Do you want to replace the IoT core with a multi-cloud solution and utilise the benefits of other IoT services from Azure or Amazon Web Services? Then get in touch with us and we will support you in the implementation with our expertise and the b.telligent partner network.
Domain Lead Data Platform & Data Management
Domain Lead Data Platform & Data Management
Exasol is a leading manufacturer of analytical database systems. Its core product is a high-performance, in-memory, parallel processing software specifically designed for the rapid analysis of data. It normally processes SQL statements sequentially in an SQL script. But how can you execute several statements simultaneously? Using the simple script contained in this blog post, we show you how.
Many companies with SAP source systems are familiar with this challenge: They want to integrate their data into an Azure data lake in order to process them there with data from other source systems and applications for reporting and advanced analytics. The new SAP notice on use of the SAP ODP framework has also raised questions among b.telligent's customers. This blog post presents three good approaches to data integration (into Microsoft's Azure cloud) which we recommend at b.telligent and which are supported by SAP.
First of all, let us summarize the customers' requirements. In most cases, enterprises want to integrate their SAP data into a data lake in order to process them further in big-data scenarios and for advanced analytics (usually also in combination with data from other source systems).
As part of their current modernization and digitization initiatives, many companies are deciding to move their data warehouse (DWH) or data platform to the cloud. This article discusses from a technical/organizational perspective which aspects areof particularly important for this and which strategies help to minimize anyrisks. Migration should not be seen as a purely technical exercise. "Soft" factors and business use-cases have a much higher impact.
No previous post
No next post
