Making use of an Active/Active (read only) HANA database in S/4 HANA part 2: Architecture Overview

In the first part if this blog series I described the motivation to use a secondary SAP HANA database for executing expensive analytical queries. In block diagrams, I showed the major building blocks:

It is clear that only purely reading calls for purely analytical applications shall be enabled to read from the secondary SAP HANA node (whose data may have a delay of typically 1- 15 seconds).

But which of the building block has the information if the current call is purely analytical? The answer is clear: Only the client knows this. So the architecture is built on what I call the client imperative:

1. The client tells the backend (explicitly or implicitly, come to this later) if it accepts data that is slightly outdated.
2. The ABAP server gets this information by the client at runtime and converts it into database hints for SAP HANA.
3. The SAP HANA client decides based on the database hints to which SAP HANA node (primary or secondary) the statement is routed.
4. The respective SAP HANA node answers the request and may return not only the result set, but also metadata about the data age.
5. The result set and the information about the data age is returned to the client and can be displayed there.

I illustrate this in a sequence diagram (note the diagrams I show may include some simplification):