Essential Guide

ERP consolidation and integration

A comprehensive collection of articles, videos and more, hand-picked by our editors

Understanding performance tradeoffs in SAP database integration

SAP database integration has always affected application performance, affordability and reliability. An expert lays out the tradeoffs to consider.

Enterprise application design is an exercise in tradeoffs, and much of the tension is between performance, affordability and reliability. While the history of SAP's decisions in this area is interesting, in this article I'll focus only on a recent shift in SAP's strategy on database integration that should inform the way SAP customers and partners think about their own application designs.

Until recently, SAP tried to keep application logic out of the database, avoided using database-specific features and recommended customers and partners do the same. SAP advocates this approach in many places, but makes it especially clear in its SAP Guidelines for Best-Built Applications that Integrate with SAP Business Suite, which states, "Developers' apps should attempt to decouple their software from the underlying database in order to provide maximum flexibility for enterprise customers."

SAP traditionally favored flexibility over performance

This strategy has played out in slightly different ways for different types of applications.

SAP, application server layer, SQL
Figure 1. SAP's traditional design strategy calls for using only SQL to execute logic on the database. This can work well when most logic happens either on the application server or on the database via SQL, but a tension can arise, especially in hybrid apps.

With transactional applications like the SAP Business Suite components, it results in a lot of calculation happening on the application server. Meanwhile, for analytic applications in both the SAP and BusinessObjects BI world, the strategy has been to push down as much mass calculation as possible to the database server by using pure SQL. When calculations cannot be done in SQL, the logic is implemented on the application server. But high-performance and hybrid applications, with their need for both transactional and analytic logic in a single application, have proven problematic under this design strategy.

On other vendors' enterprise application platforms, it has been common to see heavier use of stored procedures, triggers and tight binding of the application to a single type of database. SAP's approach is more flexible, but the drawbacks are the need to rebuild key database functionality such as transactions and query optimizers at the application server level and, sometimes, more round trips, and higher-volume data transfers between the database and the application server.

Strategies for dealing with application design tradeoffs

Broadly, these strategies represent a reaction to tradeoffs between performance and loose coupling of application components. Loose coupling, or the ability to reuse components, is a key driver of both affordability -- reusing components is cheaper than building them new -- and reliability, since proven components tend to be more reliable.

By reusing components across databases, SAP's applications have historically sacrificed squeezing better performance out of specific databases to be more affordable and reliable. Some apps from SAP and many non-NetWeaver apps developed by customers and partners have made a different tradeoff, integrating heavily with database platforms to reap the performance benefits of those databases.

The promise of HANA and SAP's new strategy

Part of the promise of HANA is to change the tradeoffs that guide these application architecture strategies. SAP maintains that HANA isn't just a database, but a platform, and that claim provides insight into SAP's new approach to application design. Notably, SAP Guidelines now include exceptions for the HANA platform, stating: "SAP recommends that the persistency layer should be free of application logic except if SAP HANA is used as the persistence layer."

More on SAP database integration

Learn about trends in SAP middleware

Watch a video on SAP Sybase-HANA integration

Read a book chapter on SAP ERP integration

HANA includes most of the traditional components of a database -- data management and query engines, stored procedures, workload management, etc. -- but it also has components that are more typical of application servers, such as its XS engine and a JavaScript Web and application server built into HANA.

Part of the reason for this new design direction is that it relieves some of the latency and bandwidth bottleneck between the database and the application server, making it less important for developers to decide where the application logic should reside. Instead, you just have HANA handle all the usual database and application server functions. Think of it as a new take on two-tier architectures.

Application logic that is implemented on HANA uses HANA's proprietary application programming interfaces (APIs), which causes some loss in reusability. (Use them on any platform you want -- as long as it's HANA.) But the advantage is that this leaves room for SAP to optimize the interaction between different components of the HANA system. For example, the XS engine already pushes down logic to stored procedures that are pre-compiled, which gives them a performance boost, and might see deeper integration into HANA's data management engine in the future.

For applications like hybrid transactional or analytical apps that have high data-processing and latency requirements, designs that combine database and application logic in a single system could result in easier development. For applications that don't have such requirements, it's worth remembering that HANA can also act as a traditional database, providing the standard SQL APIs and accompanying flexibility enterprises are accustomed to. The question to keep in mind when developing applications is where best to draw the line between performance and flexibility. HANA provides additional options, but the old tradeoffs are still there.

This was last published in August 2013

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

ERP consolidation and integration

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Hi Ethan,

I thought SAP chose application servers approach over DB server for 2 reasons:

1) H/W processing constraints on resources - memory, CPU etc. several decades ago. (Could single non-RAC(sorry Oracle talk) DB server support what several application servers + CI have been doing?).

2) DB's locking mechanism wouldn't allow the applications to scale(read the level of concurrency, enqueue/dequeue in SAP, VB tables etc) had SAP decided to use DB's stored procedures, triggers etc.

Actually when I moved to SAP from non-SAP world, the first thing I noticed was the absence of lock related errors or waits in SAP applications -- in non-SAP world, in order to improve the level of concurrency, one can set the lock mode to wait.
In SAP programs, I don't believe I've ever seen "the lock mode to wait" option.

Even today we've multiple application servers because one or two application servers can't perform efficiently.

When SAP announced one version to support all DBs - HANA or non-HANA - I was curious to know how SAP would handle the concurrency, scalability etc in disk based DBMSs assuming there're no HW constraints. (HANA as I understand it rarely uses locks due to "insert-only"(mostly?) processing).

The application servers approach also provide the flexibility in terms of scaling up or out.

Best regards,
Bala

Cancel

-ADS BY GOOGLE

SearchManufacturingERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchCRM

SearchContentManagement

SearchFinancialApplications

Close