Mark Van de Wiel

Occasionally I see my wife running SAP reports. She needs the results for budget and planning purposes. I don’t know what reports she runs to get the information she needs, but I do know the SAP reporting system is very slow. Every single one of them. It appears to me that 5 minutes is the very minimum amount of time it takes to run any report.

As someone who works in IT with multiple different databases five minutes to pull up a report is shockingly slow. What are you going to do during the five minutes you are waiting for the results you need? As an organization, consider the cost of employees waiting for results. Over time this cost may be even higher than the implementation cost SAP, which likely wasn’t low (and took a long time)

SAP HANA for Faster Reporting

SAP has a strategy to address slow reports: SAP HANA®. SAP HANA is an in-memory database that makes use of modern CPU features to perform fast data processing. Unfortunately, your organization will have to pay dearly (again) to adopt SAP HANA (both for hardware – to run the SAP database in memory – but even more so for software), and not every organization is ready to do this. Also, even though SAP HANA has been on the market for a few years the stability and level of maturity are still far from the more established databases such as Oracle, DB2, and SQL Server.

Given these performance and cost challenges real-time (and fast) reporting out of SAP systems is a common use case that one would think every SAP client is interested in. SAP has, unfortunately, made this use case harder than we would like it to be for real-time replication technology. There are three different kinds of tables in an SAP system:

  • Transparent tables, with a one-to-one mapping between the table definition in SAP and the database table.
  • Pool tables that include data from multiple logical tables in SAP into a single database table.
  • Cluster tables that not only combine data from a few logical tables in SAP into a single database table but on top of that the data is encoded so it is not understandable using regular database tools unless the data is decoded first.

Add that SAP’s database table and column names are generally four or five character German abbreviations so almost impossible to understand for an average user.

The Future of SAP’s Reporting System

Duplicate color document flat designSAP has traditionally only certified ABAP code (SAP’s proprietary programming language) to extract data out of SAP tables, but the only way to do this is using bulk extracts. Some of HVR’s customers use a hybrid approach to achieve near real-time reporting out of SAP: replicate transparent tables directly using Change Data Capture, and perform a bulk extract of cluster and pool tables using ABAP code (either through hand-written ABAP programs or programs generated by an ETL tool). Systems like this can achieve updates with as little as 30 minutes latency which, given the minimum duration of an SAP reporting system against the ERP system directly appears to be five minutes anyway, isn’t bad.

Some organizations, however, have stricter real-time requirements. For these organizations, there are real-time reporting solutions available from third-party vendors such as HVR’s partner Simplement who provide real-time SAP reporting. Simplement built their own decoder for SAP cluster tables and presents the tables in easy-to-understand table and column names through the SAP dictionary. The technology then hides the actual implementation from the user, and pre-defined reports and dashboards come out of the box.

Rumor has it that SAP is gradually moving away from cluster tables, and they want every SAP implementation to run on SAP HANA at some point in the future. Given an upgrade of an Enterprise ERP system is not something that is performed overnight, I think we will see a lot more real-time reporting use cases on SAP for many years to come.

Related Resources:

Data Replication: SAP HANA to Snowflake
Data Replication from SAP
7 Major Benefits of Using Log-Based CDC for Data Replication from SAP

About Mark

Mark Van de Wiel is the CTO for HVR. He has a strong background in data replication as well as real-time Business Intelligence and analytics.

Test drive
Contact us