Skip to Content
Author's profile photo Christoph Glania

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

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

 

Assigned Tags

      6 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Shailaja Ainala
      Shailaja Ainala

      Very informative

      Author's profile photo Marco Wahler
      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...

      Author's profile photo Wei-Shang Ku
      Wei-Shang Ku

      Hi Christoph,

       

      Great article. But I still don't understand how the routing actually work.

      In above sequence (Step 1-5) , the step 3, you mentioned :

      "3. The SAP HANA client decides based on the database hints to which SAP HANA node
      (primary or secondary) the statement is routed"

      But how HANA Client know there is a secondary node and it's host/IP address ? Should we put the second host/IP into hdbuserstore entry ?  or the client first ask primary node and then being "Redirect" (w/ 2nd node info) to the 2nd node ?  or primary node delegate the request to 2nd node and return result to client ?

      In addition, should HANA client (or usually the application server) be able to access both primary and secondary individually as well as the VIP ?

       

       

      Author's profile photo Werner Thesing
      Werner Thesing

      Hi Wei-Shang,

      The hint based statement routing described above works with prepared statements. The HANA client connects to the primary system. The primary system sends the host information about the Active/Active configuration to the client.

      The client first sends the new statement to the primary system. The primary checks if the statement with hint can be routed to the secondary system. If so, the primary returns the information about the routable statement to the client. The client than sends the statement to the secondary system. The secondary prepares and executes the statement if the visibility delay is fine.

      The client caches the statements and the routing information. Following executions of the routable statements go directly to the secondary system. The extra-hop to the primary is required only once.

       

      So, the HANA client needs to be able to access both, the primary and secondary. Since, the server sends the host information, you don’t need to put the secondary host information into the hdbuserstore.

      Typically customers use a VIP for the primary a VIP for the secondary system. The VIP assignment change in case of a role switch; i.e. the primary VIP always references the primary and the secondary VIP always references the secondary.

       

      You can find further information about hint based statement routing and direct connections to the secondary in the HANA documentation: Client Support for Active/Active (Read Enabled).

       

      Best regards,

      Werner

      Author's profile photo Manuel Cabello
      Manuel Cabello

      Hi Christoph,

      Can you please explain how the Active/Active (read enabled) method affects the XSA? Can I also set up read processes on the second XSA host?

      Thank you

       

      Regards,

      Manuel

      Author's profile photo Werner Thesing
      Werner Thesing

      Hi Cabello,

      XSA acts as a HANA database application using the JDBC client. HANA Active/Active is a database feature. XSA applications can use HANA Active/Active by either opening direct connections to the HANA secondary system or by sending queries with the result lag hint to the database.
      AFAIK XSA has no integrated solution to use hint based statement routing similar to ABAP NetWeaver and S/4. Nevertheless, XSA SQL query programmers can add the hint to their statements.

      Best regards,

      Werner