Kompromisse bei der SAP Datenbank-Integration verstehen

Die Entwicklung von Geschäftsanwendungen ist ein Kompromiss zwischen Leistung, Preis und Zuverlässigkeit. Das zeigt sich auch bei SAP Anwendungen.

Die Entwicklung von Geschäftsanwendungen ist ein ständiger Kompromiss zwischen Leistung, Bezahlbarkeit und Zuverlässigkeit. Auch wenn die Geschichte von SAP-Entscheidungen in diesem Bereich einen eigenen Artikel wert ist, konzentriere ich mich in diesem Beitrag auf den Strategiewechsel von SAP bei der Datenbank-Integration. Dabei geht es in erster Linie darum, SAP Kunden und Partner zum Nachdenken über eigene Anwendungs-Designs anzuregen.

Bisher versuchte SAP Anwendungslogiken aus der Datenbank heraus zu halten und die Verwendung einer spezifische Datenbank zu vermeiden. Partnern und Kunden riet das Softwareunternehmen eine ähnliche Strategie. Besonders deutlich wird das in den SAP Guidelines for Best-Built Applications that Integrate with SAP Business Suite. Darin heißt es: „Entwickler sollten ihre Software von der darunter liegenden Datenbank entkoppeln, um die maximale Flexibilität für Unternehmenskunden zu gewährleisten.“

SAP bevorzugt Flexibilität vor Leistung

Diese Strategie wurde in leicht unterschiedlicher Weise für verschiedene Arten von Anwendungen umgesetzt. Transaktionale Anwendungen wie die Komponenten der SAP Business Suite führen viele Rechenoperationen auf einem Anwendungsserver aus. Gleichzeitig soll bei einer analytischen Anwendung wie SAP BusinessObjects BI möglichst viel vom Datenbank-Server per SQL berechnet werden. Wenn eine Berechnung nicht in SQL möglich ist, wird sie auf dem Anwendungsserver implementiert. Hochleistungsfähige und hybride Anwendungen, die transaktionale und analytische Logiken vereinen müssen, haben mit der angesprochenen Strategie allerdings Probleme.

Bei anderen Enterprise Plattformen ist der Einsatz abgespeicherter Prozeduren und die feste Bindung der Anwendung an eine spezifische Datenbank üblich. Der Ansatz von SAP ist zwar flexibler. Der Nachteil ist aber, dass wichtige Datenbank-Funktionen, wie zum Beispiel Transaktionen und Abfrage-Optimierungen, auf Ebene des Anwendungsservers wieder neu aufgebaut werden müssen. Zudem sind unter Umständen große Datentransfers zwischen Datenbank und Anwendungsserver notwendig.

Kompromiss zwischen Preis und Zuverlässigkeit

Die Strategie von SAP ist eine Reaktion auf den Kompromiss zwischen Leistung und loser Kopplung von Anwendungskomponenten. Die lose Kopplung und die Wiederverwendung von Komponenten sind Argumente für Bezahlbarkeit – Komponenten wiederverwenden zu können ist günstiger als die Neuanschaffung – und Zuverlässigkeit, da erprobte Komponenten verlässlicher sind.

SAP hat bei seinen Anwendungen traditionell Bezahlbarkeit und Zuverlässigkeit vor Leistung gestellt, um Komponenten über verschiedene Datenbanken hinweg wiederverwenden zu können. Einige SAP- und die meisten nicht-NetWeaver-Anwendungen, die von Kunden und Partnern entwickelt wurden, gehen einen anderen Kompromiss ein, indem sie sich auf die Integration einer Datenbank konzentrieren, um den Leistungsvorteil zu genießen.

Das HANA-Versprechen und die neue Strategie von SAP

Ein Teil des Versprechens von SAP HANA ist die Abwandlung dieses Kompromisses. SAP behauptet, dass HANA nicht nur eine Datenbank ist, sondern eine Plattform. Damit zeigt sich zugleich der neue Ansatz. Die zitierten SAP Guidelines benennen daher auch Ausnahmen für SAP HANA: „SAP empfiehlt, dass die Persistenz-Schicht frei von Anwendungslogiken sein sollte, außer SAP HANA wird als Persistenz-Schicht verwendet.“

HANA umfasst die meisten traditionellen Komponenten einer Datenbank – unter anderem Datenmanagement und Query-Funktionen, gespeicherte Prozeduren sowie Workload Management. Doch HANA bietet auch Komponenten, die typisch für Anwendungsserver sind, wie zum Beispiel die XS Engine und einen JavaScript Web- und Anwendungsserver.

Ein Grund für das Umschwenken von SAP ist, dass es Engpässe bei Latenz und Bandbreite zwischen Datenbank und Anwendungsserver verringert. Damit ist es für Entwickler weniger entscheidend, wo sich die Anwendungslogik befinden muss. Stattdessen bearbeitet HANA alle gängigen Datenbank- und Anwendungsserver-Funktionen.

Eine Anwendungslogik auf Basis von HANA verwendet HANAs proprietäre Programmierschnittstelle (API) und bedeutet damit einen Verlust bei der Wiederverwertbarkeit. Die Komponenten können zwar auf beliebigen Plattformen eingesetzt werden. Diese müssen aber immer auf HANA basieren. Der Vorteil ist, dass dies für SAP Raum schafft, um Optimierungen bei der Zusammenarbeit zwischen verschiedenen Komponenten des HANA-Systems vorzunehmen. Zum Beispiel verlagert die XS Engine bereits Logiken in gespeicherte Prozeduren aus, die vorkompiliert sind. Damit erreicht SAP einen Leistungsschub und eine tiefere Integration in das HANA Datenmanagement.

Hybride transaktionale oder analytische Anwendungen, die hohe Anforderungen bei der Datenverarbeitung und Laufzeit haben, lassen sich aufgrund der Kombination aus Datenbank und Anwendungslogik in einem System einfacher entwickeln. Anwendungen, die keine so hohen Anforderungen stellen, können ebenfalls auf HANA entwickelt werden. Dabei ist der Hinweis wohl überflüssig, dass HANA auch als eine traditionelle Datenbank agieren kann und normale SQL APIs zur Verfügung stellt. Letztlich sollten sich Entwickler immer fragen, wo sie die Grenze zwischen Performance und Flexibilität ziehen. HANA bietet zusätzliche Optionen, doch die bestehenden Kompromisse bleiben erhalten.

Erfahren Sie mehr über Business-Software

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close