Real time reporting with (almost) 2-Tier architecture

[rahul_aware]

I recently watched this excellent youtube video on ALV and FPM on SAP HANA (Part 1/3) - The Difference.

Video talks about FPM/WDA based reporting on top of SAP HANA. For me, its a strong argument of using SAP native reporting capabilities as against jumping onto fully custom UI5 reporting.After all, all the investment done to get latest SAP application sever and HANA should be justified by making use of the features provided out of the box.

Believe me - many SAP customers hold to the fallacy that UI5 custom application is a silver bullet when it comes to UI applications so as to liberate business from the drudgery of classical ABAP reports and WDA applications.

Have you come across such thought process at your place of work? I am curious to know.

SAP Netweaver running on HANA- an almost 2 tier architecture

Here's a screen shot from the video that summarized the 2-tier vs 3 tier approach for reporting.

With HANA in landscape, it helps to think applications being 2 tier instead of 3 tier. UI layer has almost direct access to database. Application server which is still required - is more transparent and acts more like an adaptor that can be configures to plug data in to UI. It uses mostly SAP standard packages (FPM, SADL, BOPF) which got nice adapters to consume HANA database artifacts directly. So, the only work required to create real time reporting applications with millions of records is:

1) configuring application server components(Zero ABAP code)

2) HANA database development - Analytical views, database procedures (code push down)

Typically, with 3 tier architecture - where database is more rigid without any native programming support, we try to prefetch the high volume data to application server via online(spinning wheel effect) or batch processes. Do the aggregation, filtering, sorting or in other words - make it UI consumable via ABAP code. The UI data is staged in a separate database table, on which Reporting application run.

I have developed such kind of applications many times - and can easily point out some of the issues with it.

Issues with 3 tier reporting architecture:

1. Data aging - staging makes data non-real time. Reporting runs on aged data, age depends on background job frequency which is responsible to fetch and process data regularly


2. Too much of application server processing - ultimately leads to production support basis guys unhappy.


3. Redundancy in data processing - Here I can try to explain via an example. Say, you want to report on delayed flights at a particular airport in (near)real time. This involves finding all the flights that are in transit and then compare scheduled landing time with current time. By the nature of the report, same set of records will be processed repeated just to get few positive hits that qualify for report output- that is delayed flights. I am pretty sure that event based architecture is better suited - where data speaks for itself via events. (Think ABAP Push/Message Channel. BTW, I am super fan of web socket and reactive programming, to the point that I have started hating background jobs :-))

Slightly better reporting architecture with traditional databases

In past, for the 3 tier architecture based reporting applications, I developed cluster table based staging solution that goes in line with POWL. However, the key difference was reusability of clustered data sets(staged) across multiple users. POWL inherently is geared towards single user. It prepares and stores report output by user. This causes redundancy in processing and data storage if same report is ran by multiple users.

The solution provided neat API to define selection fields, fetching logic, and output structure- just like POWL feeder class. It had feature to save different variants of the selection field values. Background job can be scheduled to fetch and process records for particular variant. It had synchronous and asynchronous modes for fetching data.

Synchronous and asynchronous modes of fetching data:

Synchronous mode was more end user driven and triggered from UI when a report variant is selected. Staging the output in cluster table helped avoid re-fetching the same records from database when same query is selected again. Effectively avoiding redundant processing.

Asynchronous mode triggered data fetching in a separate task if triggered by end user via report. ABAP Notification service was used to inform user when the task is completed and data is ready. Note, this was before APC (ABAP Push Channel) and AMC(ABAP Message Channel) days.

Conclusion

I think HANA as a database with latest SAP Netweaver components (FPM, SADL, BOPB) can help throw all these reporting workarounds into trash. I foresee, with HANA, reporting architecture becoming more clearer and standards based with better ROI and happier business users.