Das ERP-System wurde entsprechend einer 3-Schichten-Architektur entwickelt und besteht im Wesentlichen aus den nachstehenden drei Schichten. In Klammern ist die realisierende Software-Komponente angegeben:

• die grafische Bedienungsoberfläche (Browser)
• die Anwendungslogik (ERP-System-Application-Server)
• die Datenhaltung (Datenbank-Management-System)

Aufgrund dieser Trennung ergibt sich eine ausgezeichnete Anpassungs- und Skalierungsmöglichkeit, da die Schichten voneinander unabhängig sind.

Die grafische Bedienungsoberfläche definiert die Schnittstellen für die Benutzerinteraktionen.

Die Anwendungslogik ist die Verbindung zwischen der grafischen Bedienungsoberfläche und der Datenhaltung. Als Ausführungsplattform dient der ERP-System-Application-Server (SAS), welcher zwingend eine Java Virtual Machine (JVM) voraussetzt.

Durch die Trennung der Schichten können verschiedene realisierte Benutzerschnittstellen für dieselben Anwendungsfunktionen die gleiche Anwendungslogik nutzen.

2.1 Bedienungsoberfläche

Das ERP-System stellt eine grafische Bedienungsoberfläche (Graphical User Interface, kurz GUI) zur Verfügung, die auf der Client-Seite in einem Internet Explorer dargestellt werden kann. Dabei kann sich der Benutzer gleichermaßen im Intra- oder Internet bewegen, weil er mit seinem Client über eine TCP/IP-Verbindung auf das ERP-System zugreift.

2.2 Anwendungslogik

Die Anwendungslogik bildet die mittlere Schicht in der 3-Schichten-Architektur. Hier sind die umfassenden betriebswirtschaftlichen Anwendungen enthalten. Ein ERP-System-Application-Server (SAS) benutzt verschiedene Systemdienste der System-Engine, wie:

• Cache-Management
• Transaktionsdienst
• Persistenzdienst
• Sperrdienst
• Ereignisdienst
• Lizenzdienst
• Hintergrundverarbeitung
• Änderungsjournal
• Ausgabeaufträge
• Web-Server

Über den auf die Anforderungen des ERP-Systems spezialisierten Web-Server kommunizieren die Clients mithilfe des HTTP/HTTPs-Protokolls mit dem SAS.

Die Anzahl der SAS  innerhalb eines ERP-Systems wird durch die Organisationsstruktur eines Unternehmens und die Anzahl der Benutzer bestimmt.

Jeder Benutzer benötigt im SAS eine bestimmte Menge an Speicherplatz, z. B. für Anwendungsdaten etc. Die zu Verfügung stehenden Ressourcen pro SAS sind begrenzt, sodass sich dadurch eine sinnvolle Obergrenze

für die Benutzeranzahl pro SAS ergibt. Rechnenintensive Prozesse, z. B. ODBC, Lager-Logistik-Server, sollten ebenfalls auf einem eigenen SAS betrieben werden.

Ein weiterer Grund für die Aufteilung auf mehrere SAS liegt im Garbage-Collector der JVM. Jeder SAS besitzt eine eigene JVM. Zu bestimmten Zeitpunkten werden nicht mehr benötigte Objekte vom Garbage-Collector entfernt. Dadurch wird Speicherplatz für die anderen Prozesse gewonnen. Moderne Garbage-Colletoren erledigen diese Aufgabe parallel zu anderen laufenden Prozessen. In bestimmten Situation, z. B. wenn der Speicherplatz knapp wird, werden die anderen Prozesse angehalten, damit der Garbage-Collector genügend Zeit hat, Speicherplatz freizugeben. Statt einem großen SAS, sollten besser mehrere kleine SAS betrieben werden. Da der Speicher pro SAS geringer ist, benötigt auch der Garbage-Collector pro SAS gesehen weniger Zeit.

Die Anwendungslogik läuft in einer bestimmten Umgebung. Wichtige Begriffe in diesem Zusammenhang sind Session, Thread und Transaktion. Im folgenden werden diese Begriffe genauer erklärt.

Session

Sessions stellen getrennte Arbeitsbereiche da, die jeweils eine Menge von Objekten enthalten. Eine Session repräsentiert die Wurzel eines Objektgrafen und definiert den Kontext jeglicher Aktivitäten im ERP-System. Unterschieden werden interaktive von nichtinteraktiven Sessions. Interaktive Sessions enthalten Informationen für aktive Anwendungen im Browser, zur Authentifizierung eines Benutzers und zu allen zugehörenden Ressourcen. Prinzipiell kann eine Session beliebig viele Anwendungsinstanzen beherbergen. Nicht interaktive Sessions beginnen mit dem Start eines Dienstes oder eines Verarbeitungsauftrages. Sessions werden mit der Abmeldung durch den Benutzer oder bei einem Verbindungsfehler nach einem Timeout beendet. Alle belegten Ressourcen, wie Speicher und Sperren, werden spätestens beim Beenden der Session wieder freigegeben.

Threads

Ein Tread ist erforderlich, damit die im Rahmen einer Session anlaufenden Aktivitäten bzw. die anfallenden Requests abgearbeitet werden können. Threads sind nebenläufige Ausführungseinheiten, die einer Session für die Bearbeitungsdauer eines Requests zugeordnet werden. Eine Session übermittelt an den Thread, was zu bearbeiten ist. Dieser übernimmt die Verarbeitung und liefert das Ergebnis zurück. Daraus folgt, dass für die Session nur während der aktiven Bearbeitung ein Thread erforderlich ist. Um die knappen Ressourcen wirkungsvoll verteilen zu können, wird sukzessive ein Pool an Threads aufgebaut. Aus diesem Pool können bei Bedarf auch mehrere Threads einer Session zugeordnet werden.

Aus Sicht des Anwendungsentwicklers ist jedoch immer nur ein Thread aktiv. D. h., er muss sich nicht um die Synchronisation zwischen den Threads kümmern.

Threads sind mit Ausführungsprioritäten versehen, um bzw. für die Dialogverarbeitung eine höhere Ausführungspriorität einstellen zu können und für die Hintergrundverarbeitung eine geringere.

Ein Thread stellt zusammen mit der zugeordneten Session eine Arbeitsumgebung dar, in der z. B. Transaktionen ablaufen und Sperren angefordert werden.

Die Threads werden von der JAVA™ Virtual Machine zur Verfügung gestellt. Dabei sorgt sie gegebenenfalls auch für die Aufteilung der Threads auf mehrere Prozessoren.

Transaktion

Eine Session kann mehrere so genannte Toplevel-Transaktionen beherbergen. Eine Transaktion enthält generell eine Folge von Operationen auf Business-Object-Instanzen. Eine Transaktion dient der Bildung einer Einheit. Diese Einheit wird entweder als Ganzes ausgeführt oder zurückgenommen, um die geänderten Daten wieder in einen konsistenten Zustand zu überführen. Das ERP-System besitzt ein eigenes Transaktions-Management, welches geschlossen geschachtelte Transaktionen unterstützt.

Zu Beginn einer Session wird automatisch eine Transaktion (Dummy-Transaktion) auf der OLTP-Datenbank geöffnet, um dem Anwendungsentwickler den Lesezugriff auf Business-Object-Instanzen zu ermöglichen. Die Änderung von Instanzen muss innerhalb einer neuen Transaktion erfolgen, die mit Hilfe des Transaktionsmanagers geöffnet wird. Für den Zugriff auf Instanzen von Business Objects in einer Transaktion stehen dem Anwendungsentwickler der Object-Manager bzw. die Object Query Language (OQL) zur Verfügung.

Beim Zugriff auf eine Business-Object-Instanz, um diese zu ändern, sperrt das ERP-System automatisch dieses Objekt. Es werden gleichzeitige Änderungen desselben Business Objects durch andere Transaktionen ausgeschlossen.

Für die Kommunikation mit der Datenbank wird ein Pool von Datenbankverbindungen genutzt. Für die Übermittlung der Daten wird aus diesem Pool eine Datenbankverbindung angefordert und eine Datenbank-Transaktion geöffnet. Erst nachdem die Datenbank-Transaktion erfolgreich mit commit bestätigt oder mit rollback abgebrochen wurde, ist die Toplevel-Transaktion im ERP-System tatsächlich abgeschlossen. Daraus resultiert unter anderem, dass die Sperren auf den Business Objects erst mit dem Abschluss der Toplevel-Transaktion wieder freigegeben werden.

Der Umgang mit Ressourcen

Die Skalierbarkeit und Leistungsfähigkeit eines Client-Server Systems sind davon abhängig, wie mit knappen bzw. teuren Ressourcen umgegangen wird. Die beiden Grundprinzipien lauten:

• Gemeinsame, abwechselnde Benutzung knapper Ressourcen
• Pooling teurer Ressourcen

Der Webserver verwendet einen Thread-Pool, um eingehende Requests mit einer festen Menge von Threads zu bearbeiten. Das ermöglicht, die Last auf dem ERP-System-Application-Server gleichmäßig zu verteilen und die Erzeugung einer teuren Ressource, ein neuer Thread, zu vermeiden. Nach dem gleichen Prinzip werden die Session-Anfragen an die Datenbank auf eine feste Menge von Datenbankverbindungen verteilt. Somit wird der Overhead reduziert, den das Anfordern einer Datenbankverbindung mit sich bringt.

2.3 Datenhaltung

Die dritte Schicht umfasst die Datenhaltung in relationalen Datenbanken. Es werden die Datenbank-Management-Systeme (DBMS) Oracle^®, MS-SQL-Server und DB2/AS400^® unterstützt.

Für eine effiziente Datenhaltung wird die folgende logische

Partitionierung verwendet:

• Systemkonfigurations-Datenbank
• Repository-Datenbank
• Online-Transaction-Profession-Datenbank (OLTP)
• Online-Analytical-Processing-Datenbank (OLAP)

Dieses Datenbankdesign bietet die Möglichkeit spezifische Datenbestände auf verschiedene Datenbank-Managementsysteme zu verteilen, damit wird eine angemessene Flexibilität und Skalierbarkeit erreicht. Eine Leistungssteigerung resultiert aus der Verwaltung gleichartiger Datenbestände auf den einzelnen Datenbanken. Das lässt sich bereits anhand des ähnlichen Änderungsverhaltens der Datenbestände feststellen: Die Datenbestände in der Repository-Datenbank werden zur Laufzeit eines Systems kaum verändert, die in der OLTP-Datenbank hingegen laufend.

Bei der Entwicklung des ERP-Systems wurde der schnelle Zugriff auf Daten aus den Datenbanken fokussiert, um kurze Anwortzeiten zu realisieren. Das ERP-System nutzt deshalb nur die notwendigen Mechanismen der relationalen Datenbank-Managementsysteme. Dabei handelt es sich um eine effiziente persistente Datenhaltung und optimierte Abfragen. Auf herstellereigene Trigger, referentielle und semantische Integrität oder sowie „stored procedures“ wird bewusst, auch aus Kompatibilitätsfragen, verzichtet. Der schnelle Zugriff wird vor allem durch ein eigenes Cache-Management realisiert, dem alle Datenbanken unterliegen. Es hält die Anzahl der Datenbankzugriffe möglichst gering und erhöht insgesamt den Datendurchsatz.

2.3.1 Datenbankkommunikation

Für die Kommunikation mit den Datenbanken verwenden verschiedene Hersteller unterschiedliche Schnittstellen, bzw. diverse SQL-Dialekte. Um diese Kommunikation zu vereinheitlichen, wurde eine Object-

Query-Language (OQL) implementiert, die auf objektorientierten und relationalen Konzepten basiert. Die OQL ist angelehnt an den

SQL-Standard. Bei einem ähnlichen Funktionsumfang wie in SQL, wird die

OQL für alle aufgeführten Datenbank-Managementsysteme unterstützt. Aus der Sicht des Anwendungsentwicklers spielen somit SQL-Dialekte keine Rolle mehr.

Die Abfragesprache OQL ist im ERP-System eingebettet. Bei ihrer Übersetzung werden u. a., entsprechend den Namensraumkonventionen, die spezifischen ERP-System-Namen in technische Datenbanknamen umgewandelt. Damit werden eindeutige Bezüge zu den Objekten hergestellt und Namenskollisionen in einem System ausgeschlossen.

Der Anwendungsentwickler verfügt mit dem Object-Manager über eine einfache Möglichkeit auf Daten zuzugreifen. Er stellt dem Entwickler die Einzeloperationen Lesen, Einfügen, Ändern und Löschen auf Business Objects zu Verfügung. Zudem kann der Anwendungsentwickler in diesem Zusammenhang OQL-Statements nutzen, um gleichzeitig eine Menge von Business-Object-Instanzen zu bearbeiten.

OQL und der Object-Manager bilden

für den Anwendungsentwickler die Schnittstelle zu den Datenbanken. Beide

verwenden intern das plattformunabhängige JDBC™3-Protokoll. Die verschiedenen JDBC™-Treiber sind in der Regel mit zusätzlichen hersteller-spezifischen Parametern versehen, welche vom ERP-System genutzt werden, um von den Besonderheiten der Datenbank-Management-Systeme profitieren zu können und mögliche Leistungsgewinne auszuschöpfen.

2.3.2 Systemkonfigurations-Datenbank

Ein ERP-System ist potenziell über verschiedene Rechner verteilt. In der Systemkonfigurations-Datenbank werden deshalb zentral die Objekte hinterlegt, die für eine Systemkonfiguration benötigt werden. Die Konfigurationsobjekte beeinflussen die Laufzeitumgebung und umfassen alle Daten der eingebundenen Ressourcen sowie die Authentifizierungsdaten der Benutzer. Über die entsprechenden Dialog-Anwendungen können neben einzelnen Systemen auch Systemfamilien konfiguriert werden.

2.3.3 Repository-Datenbank

In der Repository-Datenbank sind alle Entwicklungsobjekte hinterlegt. Sie beschreiben bzw. definieren ein ERP-System. Auf die Entwicklungsobjekte wird in einer Produktionsumgebung nur lesend zugegriffen. Diese Daten werden ausschließlich in der Entwicklungsphase und durch das Installieren von Softwareaktualisierungen verändert. Alle Entwicklungsobjekte unterliegen der konsequenten Versionierung und werden in den ERP-System-Namensräumen verwaltet, die analog den JAVA™-Namensräumen aufgebaut sind.

Das Data-Dictionary des ERP-Systems ist ebenfalls in der Repository-Datenbank hinterlegt. Es beschreibt das Datenbankschema des ERP-Systems durch ein objektrelationales Typsystem. Dabei arbeitet das Typsystem unabhängig von Datenbankplattformen. Das Data-Dictionary bildet die Grundlage für das statisches Mapping, welches die Dateninhalte der relationalen Datenbanken auf die objektorientierte Laufzeitumgebung abbildet.

Die Repository-Datenbank ist die zentrale Stelle für das Installieren, Aktivieren und Verteilen von Softwareaktualisierungen. Somit können Erweiterungen und Anpassungen für ein ERP-System zentral administriert werden. Es ist nicht notwendig die einzelnen beteiligten Datenbanken und Rechner jeweils separat zu betrachten.

Neben den Entwicklungsobjekten sind in der Repository-Datenbank auch andere Daten gespeichert. Hier ist bzw. das Systemprotokoll hinterlegt, welches Informationen zu Systemereignissen speichert. Auch Berechtigungsfestlegungen sind zu finden, um diese systemweit oder spezifisch für die OLTP-Datenbanken definieren zu können. Die Repository-Datenbank übernimmt die Rolle der zentralen System-Datenbank.

2.3.4 Online-Transaction-Processing-Datenbank (OLTP)

In der Online-Transaction-Processing (OLTP)-Datenbank werden Stamm- und Bewegungsdaten für die betriebswirtschaftlichen Anwendungen verwaltet. Die OLTP-Datenbank wird in einem Produktivsystem von den Benutzern am stärksten belastet. Es können auch mit mehreren OLTP-Datenbanken isoliert Datenbestände gepflegt werden (Mandanten), wie es bzw. für verschiedene juristische Unternehmenseinheiten erforderlich sein kann.

2.3.5 Online-Analytical-Processing-Datenbank (OLAP)

Die Online-Analytical-Processing-Datenbank (OLAP) dient der Analyse betriebswirtschaftlicher Daten, so wie es auch andere Data Warehouse-Lösungen ermöglichen. Es werden für Statistiken die relevanten Stamm- und Bewegungsdaten aus einer OLTP-Datenbank extrahiert und im wesentlichen nach dem „Star-Schema“ in einer OLAP-Datenbank gespeichert. Dadurch werden Anfragen mit Selektionen, Zusammenfassungen bzw. Aggregationen und Gruppierungen über große Datenmengen möglich.