Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
christoph_glania
Employee
Employee

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

 
6 Comments
former_member262988
Active Contributor
0 Kudos
Very informative
marcowahler
Explorer
0 Kudos
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...
wei-shang_ku
Participant
0 Kudos
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 ?

 

 
werner_thesing
Explorer
0 Kudos
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
former_member662987
Discoverer
0 Kudos
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
werner_thesing
Explorer
0 Kudos
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