1                     Themenübersicht

Eine Comarch-ERP-Enterprise-System- und Transportlandschaft setzt sich aus mehreren installierten Comarch-ERP-Enterprise-Systemen zusammen, die unterschiedliche Verwendungszwecke haben. Die verschiedenen Comarch-ERP-Enterprise-Systeme können Abhängigkeiten untereinander aufbauen. Es können Systeme für Qualitätssicherung, zur Entwicklung oder zum Testen der entwickelten Anpassungen und produktiv eingesetzte Systeme  in einer Systemlandschaft etabliert werden.

Diese Systeme bilden über definierte Transportwege eng zusammenhängende Systemfamilien oder sie können auch lose miteinander kommunizieren und gegenseitig Dienste zur Verfügung stellen.

Innerhalb eines Systems gilt es, in der Systemlandschaft für dieses eine konkrete Comarch-ERP-Enterprise-System, die bereitgestellten Dienste wie Ausgabe-Management, Lagerverwaltung, ODBC-Zugriff und Business Integration Service so aufzuteilen, dass ein reibungsloser Betrieb realisiert wird.

Der Begriff Systemlandschaft wird also zum einen zur Beschreibung von mehreren Comarch-ERP-Enterprise-Systemen und deren Beziehungen untereinander verwendet, zum anderen wird der Begriff bei der Beschreibung der Komponenten eines einzelnen Comarch-ERP-Enterprise-Systems und deren Beziehungen untereinander verwendet.

In diesem Dokument werden mögliche Systemlandschaften und die beteiligten Komponenten vorgestellt.  Der Schwerpunkt liegt dabei auf der Gestaltung der Systemlandschaft eines einzelnen Comarch-ERP-Enterprise-Systems. Die Besonderheiten einer Systemlandschaft bestehend aus mehreren Comarch-ERP-Enterprise-Systemen werden in der Dokumentation Systemlandschaften vorgestellt.

2                     Zielgruppe

• System-Administratoren
• Technische Berater

3                     Voraussetzungen

• Sie haben ein Comarch-ERP-Enterprise-System erfolgreich installiert.
• Die Anforderungen an die Systemlandschaft sind bekannt.

4                     Comarch-ERP-Enterprise-Systemlandschaft

In den folgenden Abschnitten wird die Comarch-ERP-Enterprise-Systemlandschaft für jeweils ein Comarch-ERP-Enterprise-System und dessen Bestandteile beschrieben. Zunächst werden typische in einer Comarch-ERP-Enterprise-Systemlandschaft installierten Systeme dargestellt. Dann werden die möglichen, logisch zu einem einzelnen Comarch-ERP-Enterprise-System gehörenden Komponenten genannt. Danach werden Möglichkeiten gezeigt, wie die von einem Comarch-ERP-Enterprise-System angebotenen Bestandteile und Dienste zu kombinieren sind und die benötigten Komponenten auf Rechner verteilt werden können.

4.1               Comarch-ERP-Enterprise-Systeme

In diesem Abschnitt werden die typischen in einer Comarch-ERP-Enterprise-Systemlandschaft auftretenden Comarch-ERP-Enterprise-Systeme und ihre Beziehungen untereinander vorgestellt.

4.1.1          Quality Assurance System

Bevor Softwareaktualisierungen an einen Kunden ausgeliefert werden oder bevor von einem vorgelagerten Entwicklungspartner Softwareaktualisierungen in eigene Systeme eingespielt werden, sollten sie in ein Quality Assurance System (QAS) eingespielt werden.

Ein Grund ist u. a., dass über das QAS nachfolgende Systeme zentral über die Funktion „Zielsystem aktualisieren“ versorgt werden können. Darüber hinaus kann man  in einem nicht produktiv genutzten System testen, ob die einzuspielenden Softwareaktualisierungen unerwünschte Auswirkungen haben und zentral entscheiden, ob sie in weitere Systeme eingespielt werden sollen.

Zum anderen werden die (zusammengefassten) Softwareaktualisierungen in einer anderen Reihenfolge, zeitlich evtl. über Wochen verteilt, in das vorgelagerte System eingespielt worden sein. Um die Konsistenz und Installationsfähigkeit der auszuliefernden Softwareaktualisierungen zu testen, bietet sich die Installation in einem QAS an, bevor man die Softwareaktualisierungen an ein Produktivsystem weiter gibt.

Die über die Funktion „Zielsystem aktualisieren“ angesprochenen Systeme müssen in der gleichen Konfigurations-Datenbank erfasst sein und dem QAS als „Sofwareaktualisierungs-Zielsysteme“ bekannt gemacht werden.

Zwischen den Zielsystemen und dem QAS besteht lediglich ein loser Zusammenhang, da das QAS System nicht unbedingt für den Einsatz der weiteren Systeme benötigt wird.

4.1.2          Demosysteme

Demosysteme werden vornehmlich für Präsentations-, Schulungs- und Weiterbildungszwecke installiert.

Sie können von anderen Systemen mit Softwareaktualisierungen versorgt werden, werden aber von keinen anderen Systemen benötigt.

Innerhalb einer Systemlandschaft sind Demosysteme eigenständige Systeme ohne weitere Beziehungen zu anderen Systemen in der Systemlandschaft.

4.1.3          Entwicklungs-Systeme

Basierend auf dem Semiramis Standard entwickeln Partner ihre branchenspezifischen Erweiterungen in einem Branchenentwicklungssystem.

Für jeden Kunden, für den individuelle Adaptierungen durchzuführen sind, wird ein Entwicklungs-System eingerichtet. Entwicklungs-Systeme sind dadurch gekennzeichnet, dass die Entwickler auf ihren lokalen Rechnern jeweils einen eigenen SAS und die Entwicklungsumgebung betreiben.

Ein Adaptierungssystem kann direkt auf dem Semiramis Standard beruhen oder aber auf dem Branchensystem eines Partners.

Die in einem Entwicklungs-System erstellten Softwareaktualisierungen werden in andere Comarch-ERP-Enterprise-Systeme eingespielt. Sobald eine aus einem Entwicklungs-System exportierte Softwareaktualisierung in ein Nachfolge-System eingespielt wurde, wird das Nachfolge-System abhängig von dem Entwicklungs-System.

4.1.4          Entwicklungs-Testsysteme

In einem Entwicklungs-Testsystem werden die in einem Entwicklungs-System erstellten Adaptierungen eingespielt und getestet.

Darüber hinaus können die eingespielten Softwareaktualisierungen zu größeren Einheiten zusammengefasst werden, bevor sie dann in weitere nachgelagerte Systeme eingespielt werden.

Werden in einem Entwicklungs-Testsystem Softwareaktualisierungen zusammengefasst und eine der zusammengefassten Softwareaktualisierungen in ein Nachfolge-System eingespielt, wird das Nachfolge-System abhängig von dem Entwicklungs-Testsystem. Das Entwicklungs-Testsystem ist abhängig von dem Entwicklungs-System, aus dem es Softwareaktualisierungen bezieht.

4.1.5          Internes System – Entwicklungsauftragsdienst

Der Entwicklungsauftragsdienst kann System- und Release übergreifend zur Unterstützung des Entwicklungsprozesses genutzt werden.

Der als Hintergrundauftrag realisierte Entwicklungsauftragsdienst muss ständig den Dienst nutzenden Entwicklungs-Systemen zur Verfügung stehen.

Es besteht also eine starke Beziehung zwischen den an der Entwicklung beteiligten Systemen und dem internen System, da über den Entwicklungsauftragsdienst jeweils Daten zwischen den Entwicklungs-Systemen und dem internen System ausgetauscht werden. Werden auf einem Entwicklungs-Testsystem Softwareaktualisierungen zu Supportauslieferungen zusammengefasst, findet die Verwaltung der Supportauslieferungen auf dem internen System statt und das interne System und die Entwicklungs-Testsysteme tauschen Daten aus.

4.1.6          Produktiv-Testsystem

Ein oder mehrere Produktiv-Testsysteme werden eingesetzt, um geplante Prozesseinstellungen und Software-Erweiterungen zu testen bevor sie in das Produktivsystem übernommen werden.

Insbesondere zeitkritische Massenverarbeitungen werden in einem Produktiv-Testsystem auf einer Kopie der Echt-Daten aus dem Produktivsystem getestet.

Darüber hinaus dient das Produktiv-Testsystem typischerweise als Schulungssystem.

Das Produktiv-Testsystem ist abhängig von dem Entwicklungs-System oder Entwicklungs-Testsystem, von dem es die einzuspielenden Softwareaktualisierungen bezieht.

4.1.7          Produktiv-System

Ein Produktiv-System verwaltet alle betriebswirtschaftlich relevanten Daten der täglichen Geschäftsfälle.

Das Produktiv-System ist abhängig von dem Entwicklungs-System, Entwicklungs-Testsystem oder Produktiv-Testsystem, von dem es die einzuspielenden Softwareaktualisierungen direkt bezieht.

4.1.8          Abhängigkeiten der Systeme untereinander

Die aufgeführten Comarch-ERP-Enterprise-Systeme sind meist über etablierte Transportwege (siehe Dokumentation Systemlandschaften) miteinander gekoppelt oder anders gesprochen „abhängig“ voneinander.

Wird ein internes System installiert, werden die Systeme darüber hinaus mit dem internen System über die Verwendung des Entwicklungsauftragsdienstes miteinander gekoppelt.

4.2               Logische Aufteilung eines Comarch-ERP-Enterprise-Systems

Ein einzelnes Comarch-ERP-Enterprise-System besteht aus mehreren Komponenten wie OLTP-Datenbanken, ERP-System-Output-Manager (SOM) und ERP-System-Application-Server (SAS). Diese Komponenten stellen unterschiedliche Dienste zur Verfügung, die teilweise auch systemübergreifend bereitgestellt werden können.

In diesem Abschnitt werden die einzelnen Dienste und Komponenten vorgestellt.

4.2.1          Datenbanken

Zu einem Comarch-ERP-Enterprise-System gehören mehrere Datenbanken wie eine Repository-Datenbank, eine Systemkonfigurations-Datenbank, eine oder  mehrere OLTP-Mandanten und keine, eine oder mehrere OLAP-Datenbanken.

Die Systemkonfigurations-Datenbank ist systemübergreifend, die anderen Datenbanken gehören jeweils zu einem bestimmten System.

4.2.2          Klassenstand

Jedes Comarch-ERP-Enterprise-System verfügt zu einem Zeitpunkt über einen definierten Klassenstand, der im Dateisystem abgelegt wird und zur Laufzeit die Klassen für die Ausführung durch die Java Virtual Machine (JVM) bereitstellt.

Die Versionen der Klassen im Dateisystem müssen mit den Versionen der korrespondierenden Entwicklungsobjekte im Repository des Systems übereinstimmen. Darüber hinaus müssen die im Dateisystem abgelegten DBU-Mapper-Klassen mit ihrer Version zu dem physikalischen Datenbank-Schema in den Datenbanken des Comarch-ERP-Enterprise-Systems passen.

Nur die durchgängige Übereinstimmung der Versionen ermöglicht einen reibungslosen Betrieb eines Comarch-ERP-Enterprise-Systems.

Die Datenbanken bilden daher mit dem Dateisystem eine logische Einheit. Sie müssen auf dem gleichen Stand sein.

4.2.3          ERP-System-Application-Server

Jeder ERP-System-Application-Server (SAS) eines Systems greift auf die Datenbanken des Systems zu. Zur Laufzeit wird auf den zu dem System gehörenden Klassenstand zugegriffen.

Ein Comarch-ERP-Enterprise-System kann über einen oder mehrere SAS verfügen. Die SAS können für unterschiedliche Verwendungen eingesetzt werden. Diese Verwendungsmöglichkeiten werden nun vorgestellt.

4.2.3.1      Message-Server

Jedes Comarch-ERP-Enterprise-System besitzt genau einen ausgezeichneten SAS, der als Message Server fungiert und die Kommunikation zwischen mehreren SAS des gleichen Systems realisiert.

Der Message-Server ist u. a. SAS-übergreifend für die Sperrverwaltung und die Ausführung der Workflow-Engine eines Systems zuständig. Siehe dazu auch die Dokumentationen Sperrverwaltung und Workflow-Engine.

Darüber hinaus wird über den Message-Server eines Systems die Kommunikation mit anderen Comarch-ERP-Enterprise-Systemen geleitet. Wenn ein SAS 1 des Systems a mit einem SAS 2 des Systems b kommunizieren möchte, dann wird die Kommunikation nicht direkt zwischen den beiden SAS a.1 und b.2 realisiert, sondern die Kommunikation wird über die Message-Server a.MS und b.MS der Systeme abgewickelt.

Der SAS a.1 kommuniziert mit dem Message-Server des Systems a, dieser kommuniziert mit dem Message-Server des Systems b und der Message-Server des Systems b kommuniziert mit dem SAS b.2. In umgekehrter Reihenfolge wird eine Nachricht dann von b.2 an den SAS a.1 gesendet.

4.2.3.2      SAS für interaktiven Zugriff

Eine der Hauptaufgaben eines ERP-System-Application-Servers ist, die interaktiven Anfragen von Benutzern entgegenzunehmen, abzuarbeiten und eine Antwort an den Benutzer zu senden. Um diese Aufgabe möglichst optimal zu erfüllen, sollten SAS für interaktiven Zugriff ausschließlich für diese Aufgabe verwendet werden.

Auf diese SAS erfolgen keine ODBC-Zugriffe und es sollten keine Verarbeitungswarteschlangen für diese SAS konfiguriert werden.

Die JVM-Einstellungen werden für eine möglichst geringe Garbage-Collection-Zykluszeit optimiert.

Diese SAS können auch Aufgaben zur Hintergrundverarbeitung übernehmen.  Diese Aufgaben sollten dann aber außerhalb der Zeiten eingeplant werden, zu denen interaktive Zugriffe stattfinden.

4.2.3.3      SAS für Hintergrundaufträge

Neben den interaktiven Anfragen gibt es auch Hintergrundaufträge wie den Datentransfer zum Rechnungswesen oder die Übertragung von Daten in die OLAP-Statistiken, die lange Laufzeiten haben. Da diese Aufgaben eine andere Lastcharakteristik aufweisen als interaktive Anfragen, ist es sinnvoll, eigene SAS für diverse Hintergrundaufträge vorzusehen, die in den Verarbeitungswarteschlangen abgearbeitet werden.

Die JVM-Einstellungen werden für einen möglichst hohen Durchsatz optimiert.

4.2.3.4      Hintergrund-Dienste

Comarch ERP Enterprise stellt mehrere Dienste zur Verfügung, die durch spezielle Hintergrundaufträge realisiert werden. In den folgenden Abschnitten werden einige dieser Dienste und Ihre Besonderheiten für eine Systemlandschaft aufgeführt.

Planungsumgebung

Die Planungsumgebung erledigt ihre Aufgaben komplett im Hauptspeicher und beansprucht daher je nach zu bearbeitender Last sehr viel des zur Verfügung stehenden Heaps.

Die Planungsumgebung arbeitet auf genau einer OLTP-Datenbank. Es kann pro SAS nur genau ein Planungsumgebung-Hintergrundauftrag gestartet werden.

Für eine Planungsumgebung sollte ein eigener SAS eingesetzt werden. Pro OLTP-Datenbank ist der Start einer eigenen Planungsumgebung und daher ein eigener SAS notwendig.

Lagerlogistik-Server

Ein Lagerlogistik-Server wird als Verarbeitungsauftrag für Lagerplätze gestartet.

Pro OLTP-Datenbank können mehrere Lagerlogistik-Server gestartet werden. Es können mehrere Lagerlogistik-Server pro SAS gestartet werden.

Ein Lagerlogistik-Server bildet die Lagerorte komplett im Hauptspeicher ab und beansprucht daher je nach Anzahl der zu verwaltenden Lagerorte sehr viel des zur Verfügung stehenden Speichers der JVM.

Entwicklungsauftragsdienst

Der Entwicklungsauftragsdienst stellt systemübergreifend die Verwaltung des Entwicklungsprozess von der Anforderung bis zur Erstellung einer Supportauslieferung zur Verfügung.

Business Integration Service

Zum Datenaustausch mit anderen Systemen wird der Business Integration Service (BIS) verwendet. Von der Datenextraktion bis zur Datenkonvertierung und Kommunikation mit anderen Systemen kommt diese Komponente zum Einsatz.

Über diese Schnittstelle können Daten auch mit anderen Comarch-ERP-Enterprise-Systemen ausgetauscht werden.

4.2.3.5      SAS für ODBC-Zugriff

Der ODBC-Zugriff erfolgt durch externe Programme wie Crystal Reports, Cognos, Excel und durch den ERP-System-Output-Manager zur Aufbereitung der Daten für den auszugebenden Beleg oder Bericht.

Um die dadurch entstehenden Anfragen zu bearbeiten, können ein oder mehrere SAS speziell für den ODBC-Zugriff vorgesehen werden.

Der Administrator kann den Benutzern DSN-Einträge auf den Client hinterlegen, so dass Anfragen an den gewünschten SAS gestellt werden und nicht etwa an die zur Bearbeitung der interaktiven Anfragen definierten SAS.

Für den SOM ist jeweils hinterlegt, auf welchen SAS er für die Durchführung einer ODBC-Anfrage zugreifen soll.

4.2.3.6      SAS für Zugriff von Geschäftspartnern

Der Zugriff von Geschäftspartnern auf das eigene System, erfolgt meist über die öffentliche Infrastruktur des Internets. Um den Zugriff auf das Comarch-ERP-Enterprise-System zu ermöglichen, aber auch gleichzeitig die Benutzer nicht in das eigene Netzwerk zu lassen, bietet sich der Betrieb eines SAS in der De-Militarized Zone (DMZ) an.

4.2.3.7      SAS eines Entwicklungs-Systems

In einem Entwicklungs-System wird jeder Entwickler einen eigenen SAS lokal starten, um die vorgenommenen Erweiterungen lokal zu testen und zu debuggen. Darüber hinaus bietet es sich an, einen zentralen SAS zu starten, der für das zentrale Check-in genutzt werden kann und der Nicht-Entwicklern die Möglichkeit bietet, sich über den aktuellen Stand der Entwicklung einen Eindruck zu verschaffen.

4.2.4          ERP-System-Output-Manager

Der ERP-System-Output-Manager (SOM) stellt seine Ausgabedienste systemübergreifend zur Verfügung. Er greift nicht direkt auf die Datenbanken eines Systems zu und greift auch nicht auf den Klassenstand eines Systems zu.

Zu jedem Comarch-ERP-Enterprise-System gehören systemeigene Einträge zu ERP-System-Output-Manager und Ausgabegeräten. Die Einträge in unterschiedlichen Comarch-ERP-Enterprise-Systemen können auf die gleiche Installation des SOM und auf die gleichen Ausgabegeräte verweisen.

4.3               Komponenten von Drittherstellern

Ein Comarch-ERP-Enterprise-System baut auf vielfältigen Hard- und Softwareprodukten von Drittherstellern auf, die alle somit Bestandteil der Comarch-ERP-Enterprise-Systemlandschaft sind und in alle Betrachtungen bzgl. Planung der Systemlandschaft oder auch Performanceoptimierung mit einbezogen werden müssen.

Eine unvollständige Aufzählung der möglichen Komponenten von Drittherstellern besteht aus z.B.

• Datenbank-Management-Systeme (DBMS)
• Betriebssysteme (OS)
• E-Mailserver
• Fax-Soft- und Hardware
• Drucker und Druckertreiber
• „Load Balancer“-Lösung
• Switches und weitere Netzwerkkomponenten wie Client-Netzwerkkarten
• Firewalls
• Virenscanner
• Backup-Lösung
• Virtual Private Network (VPN)-Lösung
• Terminalserver (Citrix)
• „Storage Area Network“-Lösung
• Client-Rechner
• Server-Hardware

Diese Komponenten können ihrerseits wieder in unterschiedlicher Art und Weise kombiniert werden, so dass z.B. auf einem Rechner mehrere der aufgezählten Software-Lösungen kombiniert sein können. Auch können einige der Punkte sowohl als Software-Lösung als auch als Hardware-Lösung existieren.

4.4               Aufteilung der Dienste

In einer Systemlandschaft können mehrere der genannten Bestandteile und Dienste zur Laufzeit auf einem oder mehreren Rechnern zusammengefasst werden.

Für die Aufteilung der Komponenten sind von dem Extremfall, dass alle Komponenten auf einem Rechner installiert werden bis hin zu dem Extremfall, dass für jede Komponente eigene Hardware verwendet wird sehr viele Möglichkeiten denkbar.

Für eine konkrete Systemlandschaft wird typischerweise eine Mischform gewählt werden, deren Ausstattung u.a. von folgenden Anforderungen abhängig ist:

• Verwendungszweck (Entwicklungs- oder Produktiv-Systeme)
• Lastprofil (Benutzeranzahl, zu bewältigendes Datenvolumen)
• Ansprüche an Hochverfügbarkeit
• Geografische Verteilung von Niederlassungen
• Beteiligte externe Komponenten (Mailserver, Fax-Server, Legacy-Anwendungen)

In den folgenden Abschnitten werden Beispiele für diese Kombinationsmöglichkeiten aufgeführt.

4.4.1          Datenbankserver

Die Datenbank kann mit einer Cluster-Lösung realisiert sein und die Datendateien in einem SAN ablegen oder sie kann auf einem eigenständigen Server laufen.

Datenbankserver profitieren insbesondere vom so genannten Scale-Up-Prinzip, bei dem die Leistungsfähigkeit eines Rechners durch das Hinzufügen von mehr CPUs und mehr Hauptspeicher gesteigert wird.

Mit Comarch ERP Enterprise ist es durch die unterschiedlichen Datenbanktypen sehr einfach möglich diese auf unterschiedlichen Datenbankinstanzen zu installieren.

So kann z.B. die Produktiv-OLTP-Datenbank auf einem Rechner mit einer DBMS-Intanz laufen, während die eher leseintensiven OLAP- und Repository-Datenbank auf einem zweiten Rechner in einer eigenen DBMS-Instanz laufen.

Durch zwei DBMS-Instanzen auf einem Rechner können Sie z.B. das Produktivtest-System vom Produktiv-System trennen. Auf diese Weise können erste Test-Berichte z.B. nicht wichtige Produktiv-Daten aus dem Buffer-Cache verdrängen, da diese ja von einer anderen DBMS-Instanz verwaltet werden.

Beachten Sie bei der Planung, dass Sie für die Ausstattung der DBMS-Server möglichst viel Hauptspeicher vorsehen. Insbesondere falls Sie eine 64Bit Implementierung wählen, sollten Sie nicht weniger als 8GB Hauptspeicher vorsehen.

Auf dem Datenbankserver sollten möglichst wenig andere Dienste laufen. Es bietet sich an den Message-Server auf einem der Datenbankserver laufen zu lassen, da diese typischerweise mit einer besser vor Ausfall geschützten Hardware bzw. redundanter Hardware ausgestattet werden, wovon der Message-Server profitiert.

4.4.2          Dateiserver

Alle SAS eines Systems sollten auf eine zentrale Verzeichnisstruktur des Comarch-ERP-Enterprise-Systems (Semiramis-Home-Verzeichnis) auf einem zentralen Dateiserver zugreifen. Die SAS können aber auch jeweils auf einen lokalen Klassenstand zugreifen. Die Verzeichnisse müssen dann aber synchron gehalten werden und speziell nach dem Einspielen von Softwareaktualisierungen abgeglichen werden.

Es wird empfohlen die Klassen zentral für alle SAS eines Systems vorzuhalten.
Jedes Comarch-ERP-Enterprise-System benötigt einen eigenen Klassenstand und ein eigenes Semiramis-Home-Verzeichnis. Dabei können auf einem Dateiserver für mehrere Comarch-ERP-Enterprise-Systeme die Semiramis_Home Verzeichnisse mit den notwendigen Klassenständen abgelegt werden. Das Dateisystem muss und sollte normalerweise nicht auf dem  Datenbankserver vorgehalten werden, da sonst weitere überwiegend Lesezugriffe durch das I/O Subsystem zu bewältigen sind.

Durch den Einsatz von NFS mit Unix bzw. DFS mit Windows können auch die Ressourcen von mehreren Quellen unter einem einzigen Pfad zur Verfügung gestellt werden. So können unterhalb von /opt/cisag/V4R1M0 jeweils unterschiedliche Comarch-ERP-Enterprise-System Verzeichnisse von mehreren Quellen „gemounted“ werden und so eine einheitliche Behandlung ermöglichen.

Für den Mischbetrieb mehrerer Betriebssysteme beachten Sie bitte u.a. folgende Punkte:

• Im Mischbetrieb mit einer i5 und Linux oder Windows und einem SAS der auf der i5 läuft ist es wesentlich leistungsfähiger, das Dateisystem auf der i5 abzulegen, als den SAS von einer i5 auf ein anderes Dateisystem zugreifen zu lassen.
• Im Mischbetrieb mit Windows DFS und Linux beachten Sie, dass es durch die unterschiedliche Behandlung von z. B. „Filehandles“ zu „Locking“-Problemen kommen kann

Konsultieren Sie auch die jeweilige Dokumentation des Betriebssystems oder der Dienste, über die die Dateisysteme eingebunden werden (z. B. Samba).

4.4.3          ERP-System-Application-Server

Der Systemlandschaft und dem Einsatz von ERP-System-Application-Servern (SAS) werden durch die vorhandene Hardware und die Limitierungen der Java Virtual Machine Beschränkungen auferlegt.

So kann ein SAS auf einem 32-Bit Betriebssystem nicht beliebig viel RAM ansprechen. Durch die Garbage Collection der JVM und das Zusammenspiel mit dem Betriebssystem sind Skalierungsbeschränkungen hinsichtlich der Anzahl gleichzeitig aktiver JVM-Instanzen gegeben.

So können auf einem 8-Wege-System nicht unbedingt auch 8 SAS gleichzeitig leistungsfähig laufen, da sie sich u. a. durch eine hohe Anzahl Context Switches den Verwaltungsaufwand des Betriebssystems so hoch treiben können, dass die CPUs ihre Leistung nicht optimal einbringen können.

ERP-System-Application-Server profitieren daher  vom so genannten Scale-Out, bei dem durch den Einsatz von mehreren Rechnern (z.B. Blade Center) eine höhere Leistung erzielt wird, indem die SAS auf diese Rechner verteilt werden.

4.4.3.1      Message-Server

Der Message-Server stellt den zentralen Vermittlungspunkt zwischen den SAS dar. Wenn der Message-Server ausgelastet ist und nicht auf eine Anfrage eines SAS reagieren kann, dann startet der SAS durch und versucht sich erneut mit dem Message-Server zu verbinden. Somit wird u. a. vermieden, dass ein SAS mit veralteten Sperrinformationen arbeitet und die Datenkonsistenz gefährdet.

Es muss vermieden werden, dass der Message-Server, z. B. durch zu hohe CPU-Auslastung des Servers, auf dem er läuft, oder durch lange dauernde GC-Phasen, nicht erreichbar ist.

Der Message-Server sollte auf einem der Datenbankserver mitlaufen. Er benötigt für die Aufgaben als Message-Server nur wenig CPU und lediglich eine moderate Heap-Größe.

Auf dem Message-Server läuft normalerweise auch die Workflow-Engine, die zu einer Grundlast auf dem Message-Server führt. Diese wird durch eine hohe Anzahl an komplexen Aktivitätsdefinitionen erhöht, die regelmäßig zu der Erzeugung einer großen Anzahl von Aktivitäten und damit u. U. zur Erzeugung von vielen E-Mails führen.

4.4.3.2      SAS für den interaktiven Betrieb

Jeder Benutzer erzeugt durch seine Interaktionen mit dem SAS neue Java-Objekte, die Hauptspeicher benötigen. Diese Objekte können, falls Sie nicht mehr benötigt werden, nach einiger Zeit  entweder durch die Garbage Collection der JVM entfernt werden, oder aber sie werden in der Session des Benutzers noch referenziert und können daher nicht entfernt werden.

Durch die Beschränkungen in der Heap-Größe unter 32-Bit-Systemen, den Implementierungen der GC-Algorithmen  und der Anforderung, dass auch bei großen Heaps unter 64-Bit-Systemen die GC-Zeiten den interaktiven Betrieb nicht beeinträchtigen dürfen, ergibt sich, dass nur eine begrenzte Anzahl Benutzer auf einem SAS gleichzeitig arbeiten kann.

Diese Anzahl ist sehr von dem durch die Benutzer erzeugten Lastprofil abhängig und muss für jede Systemlandschaft individuell geplant, gemessen und angepasst werden.

Abhängig vom Verwendungszweck der Systeme können auf einem Rechner unterschiedlich viele SAS laufen.

• Für ein Produktivsystem darf der Speicherbedarf der gestarteten SAS den physikalisch vorhandenen Speicher nicht überschreiten. Sonst kommt es unter Last zu Swapping-Effekten und die Leistung bricht ein.
• In einer Produktivumgebung sollte die Anzahl der interaktiven SAS nicht die Anzahl der CPU auf einem Rechner überschreiten.
• In einer Entwicklungs-Systemlandschaft können mehrere SAS auf einem Rechner laufen und auch der Speicherbedarf kann den physikalisch vorhandenen Hauptspeicher überschreiten. Typischweise sind die Heap-Größen im Entwicklungsbetrieb kleiner gewählt, da weniger Benutzer ständig auf den SAS arbeiten. Darüber hinaus können durch z.B. Swapping verursachte längere Antwortzeiten im Entwicklungsbetrieb akzeptabel sein.
• Auf einem interaktiven SAS können Sie z.B. Hintergrundaufträge einplanen, die zu Zeiten (in der Nacht) abgearbeitet werden, zu denen typischerweise keine oder nur wenige Benutzer angemeldet sind.

Der Zugriff auf die für den interaktiven Betrieb vorgesehenen SAS sollte über Load Balancing Mechanismen für die Benutzer transparent gemacht werden, falls mehrere interaktive SAS zum Einsatz kommen. Auch können über Load-Balancing-Mechanismen Gruppen von Anwendern immer auf die gleichen SAS geleitet werden.

4.4.3.3      SAS für Zugriff von Geschäftspartnern

Eigene SAS für den Zugriff von Geschäftspartnern sind überall dort sinnvoll, wo Geschäftspartner zum Einsatz kommen.

Aufgrund der limitierten Zugriffsmöglichkeiten für Geschäftspartner können Sie mit einem interaktiven SAS typischerweise mehr Geschäftspartner bedienen als Benutzer, die umfassend Zugriff auf das System haben.

4.4.3.4      SAS für Hintergrundaufträge

Für die Hintergrundaufträge wie Transfer der Finanzdaten und Lagerlogistik-Server können abhängig vom Lastprofil mehrere SAS pro System zum Einsatz kommen. Diese SAS können auf den gleichen Rechnern wie interaktive SAS platziert werden.

Z.B. können auf einem typischen Dual-CPU Rechner mit 4GB RAM Hauptspeicher zwei interaktive SAS und ein SAS für Hintergrundaufträge untergebracht werden.  Auch drei SAS, die für unterschiedliche Hintergrundaufträge zuständig sind, lassen sich auf einem solchen Rechner kombinieren.

Grundsätzlich können Hintergrundaufträge beliebig miteinander kombiniert werden, so dass z.B. alle Hintergrundaufträge in einem Demosystem in einem einzigen SAS laufen.

Auf die wichtigsten als Hintergrundaufträge realisierten Dienste wird in den folgenden Abschnitten separat eingegangen. Die in diesem Abschnitt gemachten allgemeinen Aussagen treffen aber auch auf sie zu.

Beachten Sie folgendes bei der Planung der SAS für Hintergrundaufträge: Jeder zu einem Zeitpunkt aktive Hintergrundauftrag benötigt zum einen mindestens einen eigenen Thread. Jeder aktive Hintergrundauftrag benötigt darüber hinaus weitere Systemressourcen wie CPU und erzeugt durch Anfragen an das DBMS-Backend Last auf dem Datenbankserver.

Nutzen Sie daher die Möglichkeiten über die Beschränkung der Anzahl an Threads auch die erzeugte Last zu beschränken. Nutzen Sie darüber hinaus die Möglichkeit die Hintergrundaufträge z.B. über die Einstellungen in Belegdokumentvorlagen und Benutzereinstellungen mit unterschiedlichen Ausführungs-Prioritäten zu versehen.  Teilen Sie Ihre Hintergrundaufträge nach lange laufenden und kurz laufenden Aufträgen auf. In Kombination mit Prioritäten und unterschiedlichen Verarbeitungswarteschlangen die unterschiedlich viele Threads zur Bearbeitung anbieten können Sie dann z.B. die lange laufenden und potentiell ressourcenhungrigen Hintergrundaufträge in einer Verarbeitungswarteschlange mit zwei Threads abarbeiten lassen, währen Sie für kurz laufende Aufträge wie Generierungen von Belegen eine Verarbeitungswarteschlange mit fünf Threads vorsehen. Durch die Aufteilung auf unterschiedliche Verarbeitungswarteschlangen sorgen Sie dafür, dass die lange laufenden Aufträge nicht alle Threads belegen und so kein anderer Auftrag abgearbeitet werden könnte. Ein einmal aktiver Hintergrundauftrag wird in der Ausführung auch nicht durch einen Auftrag mit einer höheren Priorität verdrängt. Durch die unterschiedlichen Prioritäten sorgen Sie dafür, dass in einer Verarbeitungswarteschlage auf einen frei werdenden Thread wartende Aufträge mit einer niedrigen Priorität durch Aufträge mit einer hohen Priorität überholt werden können und in der Warteschlange vor den Aufträgen mit niedriger Priorität eingereiht werden. Durch die Beschränkung der Anzahl der Threads sorgen Sie dafür, dass die durch Hintergrundaufträge erzeugte Last insbesondere für das DBMS-Backend beschränkt bleibt.

Die oftmals beobachtete Einstellung von bis zu 100 möglichen Threads wirkt sich sehr oft kontraproduktiv aus, da die durch die 100 gleichzeitig laufenden Hintergrundaufträge erzeugte Last nicht durch das DBMS-Backend bewältigt werden konnte. Als Ergebnis sinkt der Durchsatz statt durch die vermeintliche Parallelisierung den Durchsatz zu steigern.

Die Hintergrundaufträge können in Entwicklungsumgebungen oder auch in einem Demosystem z. B. auch auf dem Message Server laufen, da hier nur wenige Benutzer gleichzeitig zugreifen.

4.4.3.5      SAS für Business Integration Service

Wenn intensiv Daten mit anderen Systemen und in hohem Volumen ausgetauscht werden, dann kann der Einsatz mehrerer speziell auf diese Dienste ausgerichteten SAS erforderlich werden.

Legen Sie fest, wie viele Datenaustauschszenarien das System in welcher Zeiteinheit zu bewältigen hat. Falls Sie z.B. innerhalb einer Stunde mehrere umfangreiche lange laufende Datenaustauschszenarien zu bewältigen haben, prüfen Sie den Einsatz mehrerer SAS für diese Aufgaben.

Vergrößern Sie für diese SAS insbesondere die Stammdaten-Cache-Partition um dadurch höhere Trefferraten zu erzielen.

4.4.3.6      SAS für Planungsumgebung

Die Planung wird vollständig im Hauptspeicher durchgeführt. Daher sollten neben der Planungsumgebung möglichst keine weiteren Aufgaben durch den SAS, auf dem die Planungsumgebung läuft, zu bearbeiten sein.

Die Aufteilung ist von der zu bewältigenden Last und der Anzahl der gleichzeitig vorzuhaltenden Planungsszenarien abhängig.

4.4.3.7      SAS für Lagerlogistik-Server

Die Abbildung der Läger wird vollständig im Hauptspeicher durchgeführt. Daher sollten neben dem Lagerlogistik-Server möglichst keine Aufgaben durch den SAS auf dem der Lagerlogistik-Server läuft zu bearbeiten sein.

Planen Sie pro Hochregal-Lager einen Lagerlogistik-Server und damit einen SAS ein. Andere Lagerarten können normalerweise durch einen einzigen Lagerlogistik-Server bearbeitet werden.

4.4.3.8      SAS für ODBC-Zugriff

Spezielle SAS für den ODBC-Zugriff sind in einer Produktivumgebung sinnvoll und in Umgebungen, in denen über Drittprodukte sehr viel über ODBC auf die Daten zugegriffen wird.

Falls Sie mehrere SOM einsetzen, können Sie pro SOM genau einen ODBC-SAS definieren auf den für die ODBC-Abfrage zugegriffen wird.

Über die Anwendung „ODBC-Datenquellen“ wird als SAS für den ODBC Zugriff als Vorschlagswert der SAS angezeigt, auf dem der Benutzer gerade angemeldet ist. Dieser interaktive SAS wird normalerweise keinen ODBC-Zugriff erlauben.

Verwenden Sie z.B. zwei ODBC-SAS für einmal Zugriffe des SOM und einen für Zugriffe die mit Cognos und Excel durch die Benutzer erfolgen.

Erzeugen Sie für die Benutzer die notwendigen DSN Einträge und geben Sie den Benutzern so den zu verwendenden ODBC-SAS vor.

4.4.3.9      SAS eines Entwicklungssystems

Jeder Entwickler benötigt einen eigenen SAS, der dann auf seinem lokalen Client innerhalb der Java-IDE gestartet wird. Zentral muss ein Message-Server gestartet sein, um den Cache-Abgleich z. B. zum Sperren von Entwicklungsobjekten zwischen den einzelnen SAS abzuwickeln.

Die Hintergrundaufträge können in einer Entwicklungsumgebung dann bei Bedarf durch die Entwickler auf den eigenen SAS gestartet werden.

4.4.4          ERP-System-Output-Manager

Der ERP-System-Output-Manager (SOM) sollte auf einem eigenen Rechner laufen. ODBC-SAS können sinnvoll auf dem gleichen Rechner gestartet werden.

Die Installation mehrerer SOM wird nur in Produktivumgebungen sinnvoll sein, wenn das zu bearbeitende Volumen für einen Rechner zu groß ist. Hier ist vor allem die CPU-Leistungsfähigkeit der limitierende Faktor für die Skalierungsfähigkeit des SOM auf einem Rechner.

Für die Ausgabe von Aufträgen in z. B. via Standleitung angeschlossenen Filialen sollte der SOM im Rechenzentrum platziert werden. Die Latenzzeiten der Verbindung haben weniger Einfluss auf das Verschicken einer erzeugten Spooldatei an in der Filiale aufgestellte Drucker als auf die Kommunikation zwischen SOM und ODBC-SAS zur Ausführung der ODBC-Abfrage.

Je nach eingesetzter Drucklösung z.B. über einen Printserver in einer Niederlassung kann sich der Kommunikationsaufwand aber auch umkehren und es günstiger sein den SOM in der Niederlassung zu platzieren.

Da das Verhalten individuell von angepassten Belegen und Berichten sowie der Drucklösung abhängt, planen Sie Messungen der beiden Varianten ein.

Planen Sie ein Bandbreitenmanagement mit Quality of Service für Ihre Niederlassungen ein, damit z.B. umfangreiche Druckausgaben mit einer niedrigeren Priorität über das Netzwerk zu den Niederlassungen geleitet werden als der Zugriff auf interaktive SAS.

4.5               Beispiele für Systemlandschaften

Es gilt aus den aufgezeigten möglichen Kombinationen eine den Anforderungen angemessene Kombination zu wählen. Daher gilt es für die Systemlandschaft zunächst die Anforderungen zu definieren.

Die folgenden Ausführungen zeigen grobe Anforderungsprofile auf. Die Anforderungen gilt es im Projekt wesentlich genauer zu definieren und daraus die Umsetzung durchzuführen. Die Systemlandschaften müssen jeweils an Ihre Gegebenheiten und Anforderungen angepasst werden.

4.5.1          Demosysteme

Auf z. B. einem Notebook können mehrere Systeme mit unterschiedlichen Codeständen installiert sein, die z. B. das DBMS und die SOM-Installation gemeinsam nutzen. Typischerweise läuft zu einem Zeitpunkt genau ein einziger SAS eines einzigen Comarch-ERP-Enterprise-Systems. Die installierten Systeme verfügen über eigene Systemdatenbanken und Klassenstände, damit sie eigenständig betrieben werden können.

Wenn ein Demosystem in einer zentralen unternehmensweit genutzten Konfigurations-Datenbank mit der URL (nicht localhost) erfasst ist und wenn der Message-Server des QAS mit dem Message-Server des Demosystems kommunizieren kann, dann kann das Demosystem auch direkt aus dem QAS-System mit Softwareaktualisierungen über die Funktion „Zielsystem aktualisieren“ versorgt werden.

4.5.2          Entwicklungs-Systeme

In einer Entwicklungslandschaft werden viele der Dienste nur sehr selten genutzt bzw. nur mit einem geringen Datenaufkommen:

• Datenbankserver für die unterstützten DBMS.
• Zentraler Dateiserver oder SAN.
• Demosysteme auf Notebooks.
• QAS System, der Message-Server wird bei Bedarf gestartet.
• Partnerentwicklung oder –Korrektursystem mit ständig verfügbarem zentralem Message-Server.
• Partnerentwicklungs-Testsystem mit ständig verfügbarem zentralem Message-Server.
• Internes System mit ständig verfügbarem Message-Server.
• Adaptierungssysteme und Adaptierungs-Testsysteme für gerade aktuelle Projekte.
• Installation des SOM.

Die Message-Server werden z. B. zusammen mit dem SOM auf einem Server laufen können bzw. mehrere Message-Server unterschiedlicher Comarch-ERP-Enterprise-Systeme auf einem Server.

Es wird typischerweise nur an einer kleinen Anzahl Adaptierungssystemen gleichzeitig gearbeitet. Deren Message-Server müssen für die Entwickler verfügbar sein. Die anderen Systeme dagegen werden erst wieder im Bedarfsfall gestartet.

Ganze Systeme wie z. B. Adaptierungssystem und Adaptierungs-Testsystem können sogar als z. B. vmware-Image gesichert werden und nur im Bedarfsfall wie z. B. einer notwendigen Korrektur wieder hergestellt werden.

4.5.3          Internes System – Entwicklungsauftragsdienst

Für das interne System muss nur der Message-Server gestartet werden, auf dem auch der Entwicklungsauftragsdienst als Hintergrundauftrag eingerichtet ist.

Dieser Message-Server sollte ständig in einer Entwicklungsumgebung zur Verfügung stehen, damit jederzeit neue Entwicklungsaufgaben in den Entwicklungssystemen erstellt werden können, die den Entwicklungsauftragsdienst verwenden.

4.5.4          Quality Assurance System

Für das Quality Assurance System (QAS) muss nur ein Message-Server gestartet werden. Und dieser nur bei Bedarf.

4.5.5          Produktivlandschaften

Die Anforderungen an Produktivlandschaften sind anders als die z. B. an eine Entwicklungslandschaft gestellten Anforderungen. Während in einer Entwicklungslandschaft die SAS häufig neu gestartet werden, ist die so genannte Down-Time für ein Produktivsystem zu vermeiden. Die verarbeitenden Datenvolumen durch die Systeme und Benutzeranzahlen werden um ein vielfaches höher als in einer Entwicklungsumgebung sein.

In den folgenden Abschnitten werden exemplarisch Möglichkeiten zur Verteilung von bereitgestellten Diensten durch das System aufgezeigt.

4.5.5.1      Produktivlandschaft – Beispiel 1

Im diesem Beispiel gilt es nur eine kleine Anzahl Benutzer und ein moderates Datenvolumen zu verarbeiten.

In einer Produktivlandschaft gibt es mindestens zwei Systeme, das Produktiv-Testsystem und das Produktivsystem. Das Testsystem wird nur bei Bedarf gestartet und ist nur auf kleine Benutzerzahlen ausgelegt:

• Ein zentraler Datenbankserver.
• Das Dateisystem der Systeme liegt auch auf dem Datenbankserver.
• Produktiv-Testsystem:
• Der Message-Server wird bei Bedarf gestartet.
• Dieses System kann in der gleichen DBMS-Installation aufgesetzt werden.
• Der Message-Server wird bei Bedarf auf dem Datenbankserver gestartet.
• Produktivsystem:
• Der Message-Server läuft ständig auf dem Datenbankserver und bearbeitet die notwendigen Hintergrundaufträge.
• SOM und ein ODBC SAS laufen auf einem eigenen Server.
• Ein SAS für interaktiven Zugriff auf einem eigenen Rechner.
• Ein SAS für Hintergrundaufträge läuft zusammen mit dem interaktiven SAS auf dem gleichen Rechner.

4.5.5.2      Produktivlandschaft – Beispiel 2

Im diesem Beispiel gibt es höhere Anforderungen an die Verfügbarkeit, speziell der Datenbanken zu erfüllen. Durch intensive Nutzung von z. B. der Planungsumgebung und einer höheren Benutzeranzahl wird der Einsatz mehrerer spezialisierter SAS auf eigenen Servern nötig:

• Ein Datenbankserver mit Standby/Failover Datenbank oder Cluster.
• Server für Dateisystem und Datenbankdateien.
• Produktiv-Testsystem:
• Dieses System kann in der gleichen DBMS-Installation aufgesetzt werden.
• Der Message-Server wird bei Bedarf auf einem Test Rechner gestartet.
• Für Tests der Planungsumgebung wird bei Bedarf ein weiterer SAS zusammen mit dem Message-Server auf dem Testrechner gestartet.
• Auf dem Testrechner wird darüber hinaus ein ODBC-SAS gestartet.
• Produktiv System:
• Der Message-Server läuft ständig auf einem der Datenbankserver und bearbeitet die notwendigen Hintergrundaufträge.
• SOM und ein ODBC SAS laufen auf einem eigenen Server.
• Mehrere SAS für interaktiven Zugriff laufen auf eigenen Rechnern.
• Ein SAS für die Planung läuft auf einem Rechner gemeinsam mit interaktiven SAS.
• Ein SAS für Geschäftspartner.

4.5.5.3      Produktivlandschaft – Beispiel 3

Im diesem Beispiel gilt es Anforderungen der Hochverfügbarkeit, speziell der Datenbank zu erfüllen. Durch intensive Nutzung aller bereitgestellten Frameworks, von z. B. des Advanced Planning and Scheduling und einer hohen Anzahl gleichzeitig aktiver Benutzer, wird der Einsatz mehrerer spezialisierter SAS auf eigenen Servern nötig. Das Produktiv-Testsystem hält zur QAS als Spiegel die Daten des eigentlichen Produktivsystems vor:

• Datenbankserver mit Standby/Failover Datenbank oder Cluster.
• SAN für Dateisystem und Datenbankdateien.
• Produktiv-Testsystem wird als Kopie des Produktivsystems gehalten:
• Der Message-Server läuft ständig auf einem der Datenbankserver.
• Dieses System wird in einer eigenen DBMS-Instanz aufgesetzt.
• Mehrere SAS für ständige Tests der Planungsumgebung und Lagerlogistik-Server sowie Hintergrundverarbeitung
• Eine SOM Installation mit ODBC-SAS und einem SAS für Hintergrundbearbeitung auf einem Rechner
• Produktiv System:
• Der Message-Server läuft ständig auf einem der Datenbankserver.
• Mehrere SAS für benötigte Hintergrundaufträge
• Mehrere SAS für Lagerlogistik-Server
• Mehrere SAS für Planungsumgebung auf eigenen Rechnern.
• Mehrere SOM und mehrere ODBC-SAS laufen auf eigenen Servern.
• Ein SAS für die Anbindung anderer Systeme via Corba und Webservices.
• Mehrere SAS für interaktiven Zugriff laufen auf eigenen Rechnern, z. B. Blade Center.
• Load Balancer zur Verteilung der Zugriffe auf die SAS.
• Ein oder mehrere SAS für Geschäftspartner.

5                     Änderungen der Systemlandschaft

5.1               Änderungen innerhalb der Systemlandschaft eines Comarch-ERP-Enterprise-Systems

Eine Systemlandschaft eines Comarch-ERP-Enterprise-Systems ist über die Zeit keine konstante Einrichtung. Änderungen der Rahmenbedingungen wie Auftragsvolumen, Zukäufe und Fusionen von Firmen, Plattformwechsel der kompletten IT machen die Anpassung der Systemlandschaft notwendig.

Durch die flexible Architektur sind all diese Anpassungen schnell zu realisieren.

5.2               Änderungen der Systemlandschaft mehrerer Comarch-ERP-Enterprise-Systeme

Änderungen der Systemlandschaft bzgl. mehrerer Comarch-ERP-Enterprise-Systeme und ihrer Beziehungen untereinander benötigen ein umsichtiges Vorgehen, da eine Änderung tief greifende Einschnitte in die Transportwege zwischen einzelnen Systemen nach sich ziehen kann und daher genau geplant werden muss.

Weitere Informationen zu diesem Thema erhalten Sie in der Dokumentation Systemlandschaften.