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:
- The client tells the backend (explicitly or implicitly, come to this later) if it accepts data that is slightly outdated.
- The ABAP server gets this information by the client at runtime and converts it into database hints for SAP HANA.
- The SAP HANA client decides based on the database hints to which SAP HANA node (primary or secondary) the statement is routed.
- The respective SAP HANA node answers the request and may return not only the result set, but also metadata about the data age.
- 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):
In the next chapters, I plan to give more details on the E2E process, helping you to understand and analyze in your landscape why and where your calls are routed.
Again, I appreciate your feedback!