Skip to Content

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):

 

 

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!

 

Continue to Part 3: The client decides 

All parts of this blog series

 

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Marco Wahler

    Great! I am just in the process to build up such a stack. I am wondering how you are planing to have the stack above SAP HANA redundant…

    (0) 

Leave a Reply