Einführung: Externe Schnittstellen

Kurzbeschreibung

Große Software-Systeme bestehen naturgemäß aus verschiedenen Komponenten. Dies dient unter anderem der Komplexitätsreduktion der einzelnen Komponenten, der Verteilung von Last bzw. der gezielten Nutzung begrenzter Ressourcen und nicht zuletzt der Erweiterbarkeit. Eine im Rahmen der Erweiterbarkeit häufig auftretende Anforderung ist die nach der Integration eines bestehenden Software-Systems mit einer neuen Komponenten oder gar einem weiteren Software-System. Die Fragestellungen, die in diesem Umfeld auftreten, sind in großen Teilen unabhängig vom konkreten Software-System, der gewählten Plattform oder Programmiersprache. In einem konkreten Integrationsszenario gilt es darüber hinaus die für die gegeben Rahmenbedingungen passende Schnittstellentechnologie und Architektur zu wählen.
Dieses Dokument soll eine Hilfestellung bei der Findung der richtigen Entscheidung sein. Im ersten Teil werden die verschiedenen Aspekte, die bei der Integration von Software-System eine Rolle spielen aufgeführt und ihre Auswirkungen auf Faktoren wie Performance, Antwortzeiten, Ressourcenverbrauch usw. beschreiben. Im zweiten Teil werden konkrete Möglichkeiten für die Integration eines Software-Systems beschreiben, wobei speziell auch die Besonderheiten bei der Integration mit Comarch ERP Enterprise ausgeführt sind.

Ziel dieses Dokumentes ist auch, aufzuzeigen, dass es nicht „die“ Schnittstellentechnologie gibt – und nicht geben kann – die alle Anforderungen gleichermaßen gut erfüllt. Die richtige Wahl hängt vom konkreten Szenario und den Rahmenbedingungen ab. Die beste Lösung kann gleichwohl der Austausch einer Datei im Datensystem als auch der Aufruf eines Web-Service über das Internet sein.

Die inhaltlichen Fragen einer Integration, d.h. welche Dienste, Datenstrukturen und Daten eine Schnittstelle bieten muss, sind nicht Teil dieses Dokumentes und auch sind nicht durch die Wahl der Schnittstellentechnologie zu beeinflussen.

Zielgruppe

  • Entscheider
  • Entwickler

Beschreibung

Client und Server

Wenn Abläufe in Software-Systemen verteilt stattfinden, übernimmt eine Komponente die Rolle eines Clients, der Anfragen stellt und eine andere Komponente die Rolle eines Servers, der Anfragen beantwortet. Im Allgemeinen befindet sich zwischen Client und Server ein Netzwerk, welches die Anfragen mit einem gegebenen Protokoll und einen bestimmten Codierung überträgt. In machen Fällen können sich die Rollen von Client und Server im Verlauf der Kommunikation oder der Zeit ändern. Beispielsweise ist ein Comarch ERP Enterprise Application Server der Server für einen Browser-Client, er ist jedoch gleichermaßen selbst ein Client eines Datenbank-Servers. Als Client wird im Folgenden immer die Komponente bezeichnet, die eine Anfrage absetzt.

Qualität von Software-Systemen

Bei der Erweiterung eines Software-Systems sollte darauf geachtet werden, dass nicht nur die Erweiterung selbst eine entsprechende Qualität besitzt, sondern auch dass die Auswirkungen auf das bestehende Software-System dessen Qualität nicht beeinträchtigen. Folgende Qualitätsmerkmale sind bei der Umsetzung von Client und Server unter anderem zu berücksichtigen

  • Durchsatz
    Die meisten Software-System arbeiten transaktionsorientiert. Der Durchsatz beschreibt die Anzahl der Transaktionen pro Zeit.
  • Antwortzeiten
    Speziell bei interaktiven Systemen, bei denen Benutzer direkt Antworten auf ihre Eingaben erwarten, sollten die Zeiten dafür ein gewisses Maß (ca. 0,5-2 Sekunden) nicht überschreiten. Es ist zu beachten, dass ein hoher Durchsatz nicht gleichbedeutend mit geringen Antwortzeiten ist und umgekehrt.
  • Ressourcenverbrauch
    Ressourcen sind beispielsweise Rechner, Hauptspeicher, Festplattkapazität, Netzwerkkarten, Netzwerkverbindungen, Prozessoren, Threads. Die Mengeder Ressourcen in einem Software-System ist begrenzt. Um möglichst viele Anfragen schnell bearbeiten zu können, sollten für eine Anfrage möglichst wenige Ressourcen angefordert werden und die angeforderten Ressourcen möglichst schnell wieder freigegeben werden. Gemeinsam genutzte Ressourcen müssen dabei über Sperrmechanismen geschützt werden. Dies kann den Durchsatz beeinträchtigen.
  • Skalierbarkeit
    Ein System sollte mit einer wachsenden Anzahl an Clients mitwachsen können um den Durchsatz zu steigern ohne dass die Antwortzeiten steigen. Dies erreicht man insbesondere über die Minimierung der Netzwerkkommunikation durch Nutzung von Caching (Datenbank-Cache, Server-Cache, Client-Cache) und durch die Parallelisierung von Aufgaben innerhalb einer Anfrage.
  • Portierbarkeit
    Um bei Bedarf auch andere, leistungsfähigere Hardware nutzen zu können sollte die Erweiterung portierbar sein. Einfluss haben hierbei
    • die Programmiersprache
    • die Betriebssystemplattform, sie bestimmt beispielsweise die Syntax für Pfadangaben
    • das verwendete DBMS, denn trotz der Standardisierung von SQL verwenden unterschiedliche DBMS abweichende Syntax und bieten unterschiedliche Datentypen an
    • das Kommunikationsprotokoll zwischen Client und Server
  • Auslieferbarkeit
    Wenn eine Erweiterung mehrfach installiert werden soll, muss darauf geachtet werden, dass Korrekturen und Neuerungen, die im Rahmen der Wartung und Weiterentwicklung entstehen, kontrolliert weitergegeben und mit möglichst geringen Ausfallzeiten installiert werden können.
  • Sicherheit
    Um die Verfügbarkeit des Systems zu gewährleisten und die in ihm enthaltenen Daten vor Zugriffen von Unbefugten zu schützen, muss es sich gegen unberechtigte Anfragen schützen können. Es gibt verschiedenste Möglichkeiten dies mit Authentifizierungs- und Authorisierungs-Mechanismen zu erreichen. Erweiterungen sollten die Sicherheitsmechanismen des bestehenden Software-Systems nicht umgehen.
  • Tetstbarkeit
    Erweiterungen an einem System sollten möglichst leicht testbar sein, um das korrekte Funktionieren von Erweiterungen prüfen und Probleme untersuchen zu können.

Nutzung der Infrastruktur

Wenn eine Erweiterung eines Software-System erstellt wird, muss sie sich geeignet in die Infrastruktur des bestehenden Systems integrieren. Dies bedeutet zum einen, dass
  • bestehenden Dienste wie Caching, Sperren und Berechtigungen usw. genutzt werden sollten um Ressourcen zu schonen und den Administrationsaufwand zu minimieren, und zum anderen, dass
  • an den Stellen, wo diese Dienste bewusst oder gezwungener Maßen nicht verwendet werden, dadurch keine Konflikte oder Fehler entstehen.
Beispiele für solche Dienste, die berücksichtigt werden müssen sind:
  • Caching
    • Browser-Cache
    • Shared-Cache auf dem Comarch ERP Enterprise Application Server
    • Seiten-Cache auf dem Datenbank-Server
  • Sperren
    • Semaphoren in Java (synchronized-Anweisung)
    • Business-Object-Sperren und Logische Sperren in Comarch ERP Enterprise
    • Tabellen-, Seiten- und Zeilensperren auf der Datenbank
  • Berechtigungen
    • Client-Zertifikate
    • Comarch ERP Enterprise Berechtigungen und Berechtigungsrollen
    • Datenbankberechtigungen auf den Objekten und Benutzern des DBMS

Das Netzwerk

Beim Aufruf einer entfernten Schnittstelle wird jede Anfrage eines Clients über das Netzwerk übertragen. Mit wachsender Anzahl an Clients wächst auch der Einfluss des Netzwerkes. Folgende Eigenschaften sind dabei charakteristisch für ein Netzwerk:
  • Blockgröße
    Netzwerke senden Daten standardmäßig in einzelnen Blöcken. Im Fall von TCI/IP heißen diese Blöcke Pakete können Nutzdaten bis zum Umfang von standardmäßig 4 Kilobyte tragen.
  • Bandbreite
    Dies ist die Menge an Information, die gleichzeitig über eine Leitung übertragen werden kann.
  • Latenz
    Die ISO-OSI Netzwerk-Infrastruktur definiert verschiedenen Transportschichten der ISO-OSI).Jeder Übergang in eine andere Schicht und jede Weiterleitung einer Anfrage z.B. Weiterleitung eines TCI/IP-Paketes von einem Router an den nächsten Router, kostet Zeit.
  • Topologie
    Die Anzahl der Knotenpunkte und ihre Verbindungen untereinander beeinflussen den Weg eines Paketes von der Quelle zum Ziel.

Hieraus ergeben sich folgende Konsequenzen:

  1. Jede Anfrage kann höchstens so schnell beantwortet werden, wie es die Latenz zulässt. Dies lässt sich auch durch einen beliebig große Bandbreite nicht ändern.
  2. Die Übertragungszeit einer Datenmenge, die in die Nutzdaten eines einzelnen Paketes passt, wird praktisch ausschließlich durch die Latenz bestimmt. Es ist also kontraproduktiv, Daten in Blöcken zu übertragen, die kleiner als diese Größe sind.
  3. Die Erhöhung der Bandbreite hilft, die Übertragungszeit großer zusammenhängender Datenmengen zu minimieren. Wenn große Datenmengen übertragen werden, sollten sie blockweise übertragen werden, um die Bandbreite ausnutzen zu können.

Das Protokoll

Um über das Netzwerk zu kommunizieren, verwenden Client und Server ein Protokoll. Es definiert, wie eine Verbindung aufgebaut, eine Anfrage abgesendet, eine Antwort empfangen und eine Verbindung wieder abgebaut werden kann. Darüber hinaus definiert ein Protokoll auch, welche Fehlerzustände auf-treten können und wie mit diesen umzugehen ist. Folgende Eigenschaften des Protokolls sind besonders relevant:
  • Zustandsbehaftetes oder zustandsloses Protokoll
    Hält der Server einen Zustand je Client oder wird jede Anfrage als neue Anfrage von einem beliebigen Client interpretiert?
  • Verschlüsseltes oder unverschlüsseltes Protokoll
    Handeln Client und Server eine Verschlüsselung der Verbindung aus oder werden die Daten unverschlüsselt übertragen?
Zustandsbehaftete Protokolle kennen das Prinzip einer stehenden Verbindung, ähnlich einer Telefonverbindung zwischen zwei Teilnehmern. Die Verbindung wird einmalig aufgebaut, die Identifizierung der Teilnehmer wird ebenfalls nur einmal durchgeführt und alle weiteren Anfragen übertragen nur noch Nutzdaten. Die kostenintensiven Schritte werden daher nur ein Mal durchgeführt. Ein prominentes Protokoll, das in diese Kategorie fällt, ist das Protokoll mit dem die Object Request Broker im Fall von CORBA über TCP/IP kommunizieren.
Das wohl bekannteste zustandlose Protokoll ist HTTP (Hypertext Transfer Protokoll). Bei diesem Protokoll wird an eine Adresse einen Anfrage mit Parametern gesendet, die der Server mit Senden mit einer HTML-Seite beantwortet. Da der Server hierbei weder den Client noch den Benutzer des Clients kennt, kann er zusammenhängende aufeinander folgende Anfragen nicht als zusammenhängend erkennen. Für einfache Webseiten ist dies kein Problem, die Realisierung von komplexen Abläufen reicht dies jedoch nicht aus.
Abläufe wie beim Online-Banking oder auch die Bedienung von Comarch ERP Enterprise oder der Export großer Datenmengen erfordern das Speichern von Zuständen je Client. Wenn aus technischen Gründen die Verwendung eines zustandbehafteten Protokolls nicht möglich ist, muss das Vorhandensein eines solchen Protokolls simuliert werden. Dies setzt mehr Logik sowohl auf der Client- als auch auf der Server-Seite voraus. Wenn ein Client nicht über diese Logik verfügt und nicht erweitert werden kann, muss dies beispielsweise dadurch wettgemacht werden, dass beispielsweise bei jeder Anfrage eine erneute Authentifizierung stattfindet.
Entsprechende Logik am Client vorausgesetzt (z.B. Cookies im Falle eines Web-Browser-Clients), kann der Zustand in sehr einfachen Fällen am Client selbst gespeichert und bei jeder Anfrage als Parameter mitgesendet werden. Der Sever ist in diesem Fall zustandslos und Ressourcen werden immer nur für die Dauer der Abarbeitung einer Anfrage gehalten. In komplexeren Fällen muss der Zustand auf dem Server gespeichert werden. Der Client hält und sendet in diesem Fall meist nur noch eine „Session-Identifikation“, die nach einer initialen Authentifizierung vom Server vergeben wurde.

Die Anfragen

Anfragen von Clients lassen sich durch folgende Eigenschaften beschreiben:
  • Anzahl der Clients
    Wie viele Clients stellen parallel Anfragen?
  • Frequenz der Anfragen
    Wie viele Anfragen stellt ein Client pro Zeit?
  • Erwartete Antwortzeiten
    Muss die Antwort im Mittel schnell verfügbar sein?
  • Datenvolumen
    Welche Menge an Daten wird bei der Anfrage mitgeschickt und welche Menge an Daten wird als Antwort zurückerwartet?
  • Datenformat
    Sind die Daten binär oder als Text codiert?
    Ist die Struktur der Daten proprietär oder standardisiert?
    Werden die Daten in der Anfrage selbst verschlüsselt?
  • Lesender oder Schreibender Zugriff
    Will der Client nur Daten abfragen, oder diese auch verändern?
    Wie aktuell müssen die gelesenen Daten sein?
  • Synchroner oder asynchroner Aufruf
    Wie viel von der Antwort erwartet der Client unmittelbar?
  • Aktiver Aufruf oder Polling
    Sendet der Client überhaupt eine spezifische Anfrage oder prüft an periodisch das Vorhandensein gewisser Daten an einer definierten Stelle?
  • Zustandsloser oder zustandsbehafter Aufruf
    Hält der Server einen Zustand über mehrere Anfragen hinweg?
Anzahl der Clients

Bei zustandbehafteten Servern bedeutet jeder angemeldeten Client eine für die Dauer der Anmeldung reservierte Menge an Hauptspeicher auf dem Server. Dieser Speicher wird selten angefordert und über einer vergleichsweise lange Zeit gehalten. Bei zustandlosen Servern ist die Menge an Speicher pro Anfrage dominierend und meist höher als bei einen Anfrage an einen zustandsbehafteten Server. Wenn die Übertragung der Antwort zum Client nicht über mehrere Aufrufe aufgeteilt werden kann, werden hierbei temporär potenziell sehr große Menge an Hauptspeicher allokiert.

Frequenz der Anfragen
Wenn mit vielen Anfragen pro Zeit zu rechnen ist, und die Server-Logik es zulässt, sollten auf dem Server mehrere Ausführungseinheiten parallel die Anfragen der Clients abarbeiten um den notwenigen Durchsatz zu erreichen.
Erwartete Antwortzeiten

Damit die Latenz des Netzwerks nicht zu stark in Gewicht fällt, sollten Anfragen von Clients immer gebündelt (d.h. in Blöcken) erfolgen. Nur so kann die zur Verfügung stehende Bandbreite ausgenutzt werden.

Datenvolumen

Bei Anfrage sollten nur die Daten mitgesendet und angefordert werden, die auch tatsächlich benötigt werden. Im Fall eines SQL-Zugriffs auf die Datenbank sollte beispielsweise die Menge der Spalten und Zeilen im Ergebnis so klein wie möglich gehalten werden.

Datenformat

Bei der Verwendung von binären Datenformaten reduziert die zu übertragende Datenmenge und ist vor allem vor hochvolumige Datenübertragungen vorzuziehen. Inwiefern die binären Daten auf verschiedenen Plattformen korrekt interpretiert werden können hängt noch von anderen Faktoren ab. So bietet CORBA beispielsweise ein über die Plattformgrenzen hinweg kompatibles Binärformat, welches vom der ORB-Zwischenschicht wenn notwendig transparent auf die Plattformspezifika (Byte Order: Litte oder Big Endian, Encoding von Zeichen) umgesetzt wird.

Die Verwendung von textbasierten Formaten ist sinnvoll für kleine Datenmengen und wenn die beteiligten Clients und Server nur wenig Logik oder auch stark unterschiedliche Technologien (z.B. ein C++ Server und ein Perl Client) verwenden. Generell bedeutet die Verwendung textbasierten Formaten einer Vergrößerung des zu übertragenden Datenvolumens bei gleicher Menge an Nutzdaten. Diese liegt je nach Format zwischen 1,5-4 (Base64-Codierung, Hex-Codierung) bis 10-15 (XML mit Start-, Ende- und Meta-Tags). Teilweise kann das erhöhte Datenvolumen durch Komprimierungen wieder aufgefangen wer-den. Jedoch ist abzuwägen ob der daraus resultierende erhöhte Rechen- bzw. Hardware-Aufwand gerechtfertigt ist.

Die Verwendung proprietärer Datenstrukturen kann für geschlossene Systeme bei denen Client und Server aus der gleichen Hand stammen durchaus sinnvoll sein. Bei Änderungen an den Anforderungen kann so schneller und angemessener reagiert werden. Bei der Kommunikation über die Grenzen des eigenen Systems hinaus ist i.A. die Nutzung von standardisierten Formaten (z.B. EDI) angemessen.

Bei der Kommunikation über die Grenzen des eigenen Systems hinaus ist die Verschlüsselung der Daten dann relevant, wenn sie über unsichere Kanäle, z.B. über das Internet via HTTP oder als E-Mail, übertragen werden sollen. Die hier zum Einsatz kommenden Verfahren setzen dabei wieder zusätzliche Logik und Metadaten zur Verschlüsselung auf dem Client- und dem Server voraus.

Lesender oder Schreibender Zugriff

Lesende Zugriffe erfordern im Allgemeinen weniger Ressourcen als schreibende Zugriffe. Wenn das Ergebnis eines lesenden Zugriffs darüber hinaus nicht zu 100% aktuell sein muss, kann auf die Anforderung von Sperren verzichtet wer-den und es können Daten aus einem Cache zurückgeliefert werden.

Synchroner oder asynchroner Aufruf

Bei einem synchronen Aufruf wartet der Client auf eine unmittelbare Antwort des Servers. Dies ist der Normalfall, da zumindest die Bestätigung, dass die Anfrage vom Server angenommen wurde berücksichtigt werden soll. Wenn die eigentliche Antwort nicht oder erst zu einem späteren Zeitpunkt benötigt wird, hat der Server die Möglichkeit, auf das Freiwerden von Ressourcen zu warten.

Aktiver Aufruf oder Polling

Beim aktiven Aufruf des Servers durch den Client müssen Client und Server zumindest zeitweise synchron kommunizieren. Der Vorteil ist, dass der Server nur dann Daten bereitstellt, wenn der Client sie erwartet. Beim Polling prüft der Client ohne vorherige Anfrage an den Server, periodisch ob an einer für beide Seiten zugreifbaren Stelle Daten, z.B. in Form einer Datei, vorhanden sind. Polling eignet sich für die Übertragung großer Datenmengen, die vom Server ohne zusätzliche Eingangsparameter zur Verfügung gestellt werden können. Eine Rückmeldung von Fehlern auf dem Client an den Server erfolgt hierbei normalerweise nicht. Es gibt auch die Möglichkeit die Varianten „aktiver Aufruf“ und „Polling“ zu kombinieren. Hierbei sendet der Client zunächst eine Anfrage an den Server und beginnt erst danach mit dem Polling.

Zustandsloser oder zustandsbehafteter Aufruf

Bei der Verwendung von zustandslosen Aufrufen muss die Authentifizierung bei jeder Anfrage erneut erfolgen, was sich negativ auswirkt, wenn die Frequenz der Anfragen hoch ist. Darüber hinaus müssen bei zustandlosen Aufrufen komplexe Abläufe immer in eine einzige Anfrage verpackt und das gesamte Ergebnis in einer Antwort gesendet werden. Dies führt zu wenig modularen Schnitt-stellen. Da für die Bearbeitung der Anfrage hierfür meistens, zumindest temporär, die Anfragen und die Antwort vollständig im Hauptspeicher aufgebaut wer-den müssen, eignet sich diese Art des Aufrufs auch nicht für die Übermittlung von Massendaten. Bei zustandsbehafteten Aufrufen entsteht der Overhead der Authentifizierung nur ein Mal, komplexe Aufruf können in wieder verwendbare Teile gegliedert werden und die Übertragung der Eingangsparameters als auf des Ergebnisses der Anfrage kann in mehreren Blöcken erfolgen.

Schnittstellentechnologien

In diesem Abschnitt werden Schnittstellentechnologien vorgestellt, die zur Integration von Software-Systemen verwendet werden können. Dabei wird auch auf den Grad an Unterstützung eingegangen, die Comarch ERP Enterprise dafür im Standard bietet.

Eine konkrete Lösung eines Integrationsproblems wird im Allgemeinen auf einer Kombination mehrerer dieser Technologien beruhen, wie an einigen Beispielen gezeigt wird.

Dateien

Bei der Übertragung von Daten in Form von Dateien werden die Daten an einer zentralen Stelle zur Verfügung gestellt, auf die der Server schreibenden und der Client zumindest lesenden Zugriff hat.

Dateien sind auch für große Datenmengen gut geeignet. Ein Beispiel für die Verwendung von Dateien zum Datenaustausch zwischen verschiedenen Systemen bietet der BIS. Mit dem BIS lassen sich Daten automatisiert importieren oder exportieren.

Einer der Nachteile von Dateien ist das Fehlen von Transaktionen. Wenn eine Datei für einen anderen Prozess sichtbar bzw. zugreifbar wird und welcher In-halt gelesen wird hängt sehr stark vom Betriebssystem ab.

Comarch ERP Enterprise unterstützt dabei das Dateisystem des Application-Servers sowie den Knowledge Store.

Dateisystem des Application-Servers

Comarch ERP Enterprise kann auf das Dateisystem des Application-Servers zugreifen. Je nach Konfiguration des Betriebssystems stehen hier sowohl das lokale Dateisystem also auch entfernte Dateisysteme („Netzlaufwerke“) zur Verfügung.

Dateien werden über ihren Dateipfad angesprochen. Dabei ist zu beachten, dass Dateipfade vom Rechner und vom seinem Betriebssystem abhängig sind und daher möglicherweise nicht Application-Server-übergreifend verwendet werden können. Ein Möglichkeit diese Unabhängigkeit wieder zu erreichen, ist die Verwendung vom Dateipfaden relativ zum Ordner „semiramis/usr“. Der Dateiserver-Pfad zum „semiramis“-Ordner kann auf jedem Comarch ERP Enterprise Application Server in der für ihn gültigen Schreibweise abgefragt werden. (Methode com.cisag.pgm.util.ServerInfo.getFileServer Directory). Im BIS, bei der Ausgabe von Dokumenten und bei Reorganisationen stehen hierfür auch schon entsprechende Variablen („{semiramis}“) zur Verfügung.

Knowledge Store

Der Knowledge Store stellt ein datenbankgestütztes Dateisystem zur Verfügung. Seine Dateipfade sind Application-Server-übergreifend gültig und vom Betriebssystem unabhängig.

Fremdsoftware kann auf den Knowledge Store per WebDAV über https zugreifen. Die ermöglicht Zugriff direkt von Client-Rechnern aus, die keinen Zugriff auf das Dateisystem des Application-Servers besitzen. Da es sich bei WebDAV um einen relativ neuen Standard handelt, wird diese Art des Zugriffs noch nicht von allen Betriebssystemen und Anwendung angeboten. Die Authentifizierung erfolgt dabei per Zertifikat oder Kennwort.

Datenbanken

SQL (Direkter Zugriff)

Ein direkter Zugriff auf Datenbanken ist von Java aus beispielsweise über die JDBC-Schnittstelle möglich, wobei ein JDBC-Treiber für die jeweilige Datenbank verwendet werden muss. Der Zugriff auf die Datenbank kann trotz der Verwendung von JDBC vom DBMS abhängig sein.

Zugriff auf fremde Datenbanken

Aus Comarch ERP Enterprise heraus kann auch auf fremde Datenbanken zugegriffen werden. Hierfür kann beispielsweise die Standard-JDBC-Schnittstelle des JDK verwendet werden.

  • Die Abbildung der Comarch ERP Enterprise Business Objects und der jeweiligen Datentypen ist DBMS-spezifisch und ihre Form wird von der Comarch ERP Enterprise Software AG nicht garantiert.
  • Auf DBMS-Ebene liegt ein technisches Datenmodell vor, in dem GUIDs binäre Daten sind, und Zeitstempel in einem kompakten Format gespeichert werden, das kein DBMS direkt auswerten kann.
  • Lesende Zugriffe umgehen das Comarch ERP Enterprise -Caching. Damit sinkt die Geschwindigkeit der Zugriffe.
  • Schreibzugriffe umgehen das Comarch ERP Enterprise -Caching und -Locking. Damit werden potenziell inkonsistente Daten gelesen.
  • Es finden, bis auf die Mittel des DBMS, keine Berechtigungsprüfungen statt.

Stattdessen sollten Comarch ERP Enterprise-ODBC oder der Comarch ERP Enterprise-Persistenzdienst verwendet werden.

Comarch ERP Enterprise-ODBC

Comarch ERP Enterprise-ODBC erlaubt den Zugriff auf Comarch ERP Enterprise-Datenbanken über eine in Comarch ERP Enterprise integrierte ODBC-Schnittstelle, die von externer Software verwendet werden kann. Der Zugriff ist unabhängig vom DBMS der Comarch ERP Enterprise-Datenbanken.

Bei Comarch ERP Enterprise-ODBC ist zu beachten, dass nur lesende Zugriffe auf die Datenbanken möglich sind. Technisch setzt der Zugriff die Verwendung von HTTPS voraus.

Comarch ERP Enterprise-ODBC stellt ein auf Basis der Comarch ERP Enterprise-Metadaten angereichertes Datenbankschema zur Verfügung. Als virtuelle Attribute sind darin Business Keys aus Beziehungen und die natürlichsprachliche Beschreibung von Valueset-Werten enthalten. Weiterhin sind virtuelle Tabellen für den Zugriff auf den Knowledge Store und dynamische Objekte enthalten. Sie können auch eigene zusätzliche Daten und Berechnungen in Form von virtuellen Tabellen und virtuellen Funktionen zugreifbar machen. Für jedes Attribut im Datenbankschema ist eine übersetzbare Beschreibung verfügbar.

Berechtigungen auf Business-Entity-Ebene werden beim Zugriff auf Comarch ERP Enterprise-ODBC ausgewertet.

Comarch ERP Enterprise-Persistenzdienst

Der Comarch ERP Enterprise-Persistenzdienst kann nur innerhalb Comarch ERP Enterprise verwendet werden. Mit einer Zwischenschicht ist jedoch ein entfernter Zugriff realisierbar. Hierfür kann beispielsweise in Comarch ERP Enterprise eine Hintergrund-Anwendung erstellt werden, die dann über CORBA oder Web-Services von extern aufgerufen wird. Durch die Unabhängigkeit vom aufrufenden Kanal sind Hintergrund-Anwendungen eine investitionssichere Alternative, da sich die Programmierer nicht mit den Gegebenheiten und Versionsabhängigkeiten eines speziellen Kanals befassen müssen.

Der Comarch ERP Enterprise-Persistenzdienst ist vom DBMS unabhängig. Er erlaubt lesende und schreibende Zugriffe und die Nutzung des Comarch ERP Enterprise-Cachings, der Sperren und optional der Berechtigungen. Es unterstützt sowohl objekt- als auch tupelbasierte Zugriff, sowie Einzel- und Massenoperationen. Es können sehr einfache Hintergrund-Anwendungen, z.B. das Ausführen eines einzelnen Datenbankzugriffes mit Hilfe von Comarch ERP Enterprise-OQL, als auch beliebige komplexe Logiken realisieren. Durch die Nutzung von bereits bestehenden Logikklassen lässt sich zudem ein hoher Grad an funktionaler Wiederverwendung erreichen.

Entfernte Aufrufe

Über entfernte Aufrufe werden auf einem entfernten System bestimmte Aktionen synchron ausgeführt. Für den Aufruf wird ein bestimmtes Protokoll verwendet.

CORBA

CORBA ist ein Protokoll für entfernte Aufrufe, der plattformübergreifend verwendbarer ist. CORBA kann zustandsbehaftet arbeiten und eignet sich daher für die Übertragung von Massendaten.

Comarch ERP Enterprise als CORBA-Server

Comarch ERP Enterprise enthält einen CORBA-Server. Das Datenformat der Schnittstelle, an das sich die Clients halten müssen, ist in einer IDL-Datei definiert.

Über die CORBA-Schnittstelle können beliebige Hintergrund-Anwendungen aufgerufen werden, die in Comarch ERP Enterprise ablaufen. Daneben steht die Funktionalität des BIS (Datenaustausch) zur Verfügung.

Bei der Anmeldung der Clients an den CORBA-Server findet eine Authentifizierung statt, und die Berechtigungen in Comarch ERP Enterprise werden geprüft.

Comarch ERP Enterprise als CORBA-Client

In einer Adaptierung kann auch von innerhalb Comarch ERP Enterprise auf einen entfernten CORBA-Server zugegriffen werden. Comarch ERP Enterprise enthält hierzu als Unterstützung im Standard nur den ORB, die zugehörigen Bibliotheken und die Dokumentation der CORBA-Beispiel-Clients für Comarch ERP Enterprise selbst, da die Art und Weise der Zugriff vollständig durch den jeweiligen CORBA-Server vorgegeben wird.

Web-Services

Web-Services verwenden das Protokoll SOAP für entfernte Aufrufe, der platt-formübergreifend verwendet werden können beziehungsweise die REST-Prinzipien werden umgesetzt bei der Realisierung eines Web Services. Sie sind eine Alternative zu CORBA, wenn keine Massendaten übertragen werden müssen, da Web Services keine zustandsbehafteten Aufrufe unterstützen.

Comarch ERP Enterprise als Web-Services-Server

Comarch ERP Enterprise enthält einen Web-Services-Server. Der Web-Services-Server erfordert die Verwendung von HTTPS. Er gibt durch eine WSDL-Datei das Datenformat der Schnittstelle (ggf. SOAP) vor, die die Clients verwenden müssen.

Über die Web-Services-Schnittstelle steht die Funktionalität analog zum CORBA-Server zur Verfügung.

Bei der Anmeldung der Clients an den Web-Services-Server findet eine Authentifizierung mittels Kennwort oder Benutzer-Zertifikat statt, und die Berechtigungen in Comarch ERP Enterprise werden geprüft.

Comarch ERP Enterprise als Web-Services-Client

Adaptierungen in Comarch ERP Enterprise können auch auf einen entfernten Web-Services-Server zugreifen. Comarch ERP Enterprise enthält hierzu als Unterstützung im Standard nur die zugehörigen Bibliotheken und die Dokumentation der Web-Services-Beispiel-Clients für Comarch ERP Enterprise selbst, da die Art und Weise der Zugriff vollständig durch den jeweiligen Web-Services-Server vorgegeben wird.

Native Protokolle

Andere Protokolle, wie TCP/IP, FTP oder Java RMI können ebenfalls verwendet werden. Sie sind insbesondere interessant, um von Comarch ERP Enterprise aus externe Server über dessen Schnittstellen anzusprechen. Comarch ERP Enterprise bietet hier jedoch keine Unterstützung im Standard.

Soll eine Adaptierung in Comarch ERP Enterprise einen Server für ein natives Protokoll realisieren, wird stattdessen empfohlen, diesen Server außerhalb von Comarch ERP Enterprise zu entwickeln und ihn über CORBA auf Comarch ERP Enterprise zugreifen zu lassen.

Kombinationen verschiedener Technologien

Beispiel
Bei Exporten oder Importen über CORBA oder Web-Services werden die Nutz-daten als Parameter des entfernten Aufrufs transportiert. Dies ist von Vorteil, wenn die Nutzdaten auf diesem Weg übermittelt werden können. Alternativ hierzu ist es auch möglich, den Export bzw. Import über einen entfernten Aufruf zu synchron zu starten, als Quell- bzw. Ziel-Datei jedoch eine für Comarch ERP Enterprise zugreifbare Datei zu verwenden. Dies kann durch das entfernte Aufrufen der Hintergrund-Anwendungen „com.cisag.pgm.bi.Export“ bzw. „com.cisag.pgm.bi.Import“ erreicht werden.
Beispiel
Wenn ein bestehendes System eine Datenbank-Schnittstelle besitzt, d.h. Daten direkte aus Tabellen mit Hilfe von SQL auslesen kann, so kann außerhalb des Comarch ERP Enterprise-Datenbank-Schemas eine entsprechende Tabelle erzeugt werden. Auf diese Datenbank-Tabelle kann Comarch ERP Enterprise via JDBC schreibend zugreifen. Ein Dienst, oder eine entfernt aufgerufene Hintergrund-Anwendung, kann nun beispielsweise die Daten mit Hilfe des Comarch ERP Enterprise-Persistenzdienstes beschaffen, aufbereiten und via JDBC in diese Tabelle schreiben. Dies hat den Vorteil, dass alle Leistungssteigernden Eigenschaften von Comarch ERP Enterprise, z.B. das Comarch ERP Enterprise-Caching und Perpared-Statement, bei der Datenbeschaffung ausgenutzt werden können.

Performanceaspekte

Schutz gegen Ressourcenengpässe

Server-Systeme wie Comarch ERP Enterprise können nicht mit optimaler Performance arbeiten, wenn zu viele entfernte Aufrufe gleichzeitig von einem Application-Server bearbeitet werden müssen. Dies kann durch geeignete Maßnahmen vermieden werden.

Jede Session, die ein Client über entfernte Aufrufe auf einem Comarch ERP Enterprise-System öffnet, verbraucht Ressourcen wie Speicher, Rechenzeit und Datenbankverbindungen auf dem Application-Server, zu dem sich der Client verbindet. Falls für ein Szenario sehr viele Clients erforderlich sind, die alle ständig mit dem CORBA-Server verbunden sind, kann es zu Engpässen an Ressourcen kommen. Kritische Ressourcen sind in diesem Fall vor allem die Sessions (und die Datenbankverbindungen). Jede Session belegt ab dem Zeitpunkt ihrer Erzeugung einen Comarch ERP Enterprise-Thread, d. h. Heap-Speicher für den Threadstack und native Ressourcen je nach Betriebssystem. Während der Abarbeitung einer Anfrage wird ein Thread belegt. Wenn für die Bearbeitung der CORBA-Anfrage Daten von der Datenbank gelesen werden müssen, werden zusätzlich zeitweise Datenbankverbindungen belegt.

Speicher, Threads und Datenbankverbindungen sind auf dem Application-Server begrenzte Ressourcen. Ein Ressourcenengpass führt zu längeren Bearbeitungszeiten eines entfernten Aufrufes. Im schlimmsten Fall kann die Stabilität des Application-Servers insgesamt gefährdet sein.

Um Ressourcenengpässe zu vermeiden, gibt es mehrere Möglichkeiten. Die Grundidee dabei ist, den Zugriff auf kritische Ressourcen zu koordinieren, um zu viele gleichzeitige Zugriffe zu vermeiden.

In der ersten Lösungsmöglichkeit (Abb.1) werden mehrere Comarch ERP Enterprise Application Server verwendet, auf die die Zugriffe der Clients verteilt werden. Im Beispiel werden CORBA-Clients verwendet, die beschriebene Idee gilt jedoch allgemein.

Durch das Verteilen auf mehrere Comarch ERP Enterprise Application Server wird der Speicherverbrauch pro Application-Server verringert. Allerdings kann es bei dieser Lösung zu einer hohen Beanspruchung der Datenbank kommen, falls viele An-fragen zur selben Zeit an die Application Server gelangen.

Mehrere CORBA-Server

In der 2. Lösungsmöglichkeit (Abbildung 2) wird ein eigenständiger, von Comarch ERP Enterprise unabhängiger Prozess („CORBA Proxy Queue“) verwendet. Die Anfragen der Clients gehen zunächst an diesen Prozess, der sie in eine Warteschlange einreiht und dann eine begrenzte Anzahl von ihnen gleichzeitig an Comarch ERP Enterprise weitergibt. Damit sind die Zahl von CORBA-Sessions und die Zahl der Datenbankverbindungen in Comarch ERP Enterprise begrenzt. Die „CORBA Proxy Queue“ agiert als Server für die entfernten Aufrufe und als CORBA–Client. Die Implementierung einer solchen Queue kann daher in einer beliebigen Programmiersprache erfolgen, die auf den Anwendungsfall abgestimmt ist.

ORBA Proxy Queue

Bei beiden vorgestellten Lösungen wird davon ausgegangen, dass jeder Prozess auf einem eigenen Rechner läuft und dessen begrenzte Ressourcen damit exklusiv zur Verfügung hat. Auch eine „CORBA Proxy Queue“ sollte immer auf einem eigenen Rechner laufen. Schon bei der Entwicklung einer Anbindung an Comarch ERP Enterprise über entfernte Aufrufe sollten Tests unter Berücksichtigung der zu erwartenden Anzahl an Clients durchgeführt werden. Dabei können Sie feststellen, ob Maßnahmen zum Ressourcenschutz im konkreten Fall notwendig sind.

Czy ten artykuł był pomocny?

Wyślij opnie