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 these reports are very slow. Every single one of them. It appears to me that 5 minutes is the very minimuim 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: HANA. HANA is SAP’s 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 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 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.

SAP 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 report 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 reporting on any data in SAP. 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 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.

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.

Discussion

© 2019 HVR

Live Demo Contact Us