SAP

You’re probably in the same boat as many of our clients facing a challenge: how best to integrate SAP BW (SAP Business Warehouse) as the data source for Microsoft Power BI (Power BI). It’s not always an easy task, since it requires due attention to diverse factors, potential challenges, and possible ways to tune performance.

We have compiled a thorough guide of best practices and limits, underscored by our extensive in-depth experience into integrating Power BI with SAP BW. Now we offer you a brief insight in this blog.

With the Q2 2023 updated titled "New optimized story experience - unified strories and applications", SAP analytics cloud offers users new ways to develop reports and dashboards even more flexibly and easily in an integrated design enviroment. We'll showyou which new features theupdate provides and how it supports you in creating reports,

SAP Data Warehouse Cloud offers new ways of processing and utilizing enterprise data. SAP BW Bridge for SAP Data Warehouse Cloud now makes it easier for customers with an on-premise SAP BW to proceed to the cloud. Here we show you what BW Bridge is all about, and how it supports your journey into the cloud!

If you choose SAP Analytics Cloud, you are soon confronted with the question of which capabilities to make available to users. The answer to this is provided in the operating concept. We will now show you what needs to be considered.

During selection of a connection type, several aspects must be considered. Find out here which these are, and which scenarios can be covered with the various connections.

By deciding in favor of the SAP Analytics Cloud (SAC), you are choosing an innovative, flexible and high-performance cloud solution for your company. The next step is to choose the right analysis and visualization method for your use case. Here, we'll give you an insight into the SAC develoopment environments.

As a business intelligence package, SAP BW provides many opportunities for efficient reporting – but also contains numerous barriers which significantly slow down performance. Using the example of report filters available in the application, this article shows how the smallest adaptations impair SAP BW performance, and how efficient settings for filtering options can improve results.

In previous years, there were repeatedly reports and rumours about the future of SAP BusinessObjects.

Some interesting new details have emerged in the meantime:

News on SAP Business Objects BI 4.2 SP07

On 04.03.2019, SAP issued support package 07 for the SAP Business Objects Business Intelligence Platform 4.2 (SBOP BI 4.2). According to SAP, this is the last feature pack for release 4.2 . Though support package 08 is planned, it will constitute purely a maintenance release containing "only" bug fixes but no new functional extensions.

Before HANA, exception aggregations in SAP BW more frequently posed a challenge at runtime, this also applying to the distinct count operation. This operation is used, for example, to obtain a customer count from orders.

Earlier, distinct count operations were often implemented as follows:  A calculated key figure with a value of 1 was established, and additions then performed via exception aggregation. However, what worked well in environments without HANA currently causes the pushdown to stop functioning. This can prevent calculations from being optimally performed, depending on settings.

A solution is therefore required for HANA environments: Accordingly, let us concentrate next on optimal implementation of distinct count with business warehouse on HANA or BW/4HANA.

I’d like to once again delve into the issue of memory usage. Other blogs like “SAP HANA – no more memory? Implement early unload!” have shown the importance of properly configuring SAP BW objects for the intended usage. Briefly:  anything not queried regularly and immediately should be unloaded early to storage. For this you set the “early unload priority” attribute in the HANA database table. Since this setting is not a part of the ABAP transport system (CTS), the developer or operation must always ensure that the configuration is correct. Otherwise, only data needed for staging from the data acquisition layer perform well in RAM, which burdens the system and is unnecessarily expensive.

Optimise Main Memory Use With SAP BW on HANA

Main memory capacity is always a fascinating issue for SAP HANA and data warehouse scenarios when compared with ERP applications, or applications with relatively steady volumes of data. There is one key point to remember: make sure that you never run out of main memory space.

With the launch of SAP BW on HANA in 2010, many previous measures for enhancing performance in BW systems became obsolete. At the same time, however, many new questions are cropping up regarding the novel platform. Here, one very relevant question is whether it still makes sense to cache the Advanced Business Application Programming routines. For with HANA, the data is, on the one hand, stored in the database located under an application server in the main memory and, on the other hand, optimised for requests. In addition, the requests in routines are executed systemically on the application server. Therefore, the question regarding the sensibleness of the use of a cache for ABAP routine requests is to be commented on in detail in the following blog contribution:

In the event of frequently recurring data, the answer is yes. If, for example, the attribute "continent" is to be read by the information object "country", the temporal overhead of access by the SQL parser, the network, etc. to HANA is recurringly too high for each line. There are several technical layers between the ABAP program and the actual data, which are to be executed repeatedly. However, if it is necessary to perform several joins between tables or if the number of lines to be read is very large, the advantage tilts towards the HANA database again.

According to my experience with customers with large data quantities, a cache in ABAP partially triples the speed of the DTP execution in a SAP BW on HANA system. Of course, this always depends on the situation (e.g. data distribution, homogeneity of the data, etc.), as well as the infrastructure that has been built up. All still without use of the shared memory. For all data packages together, i.e. per load, the shared memory performs only one request of the database. In handling, however, it is unnecessarily complicated.