1                     Themenübersicht

In der Anwendung „Systemcockpit“ können Sie Comarch-ERP-Enterprise-Systeme und Entwicklungsgruppen konfigurieren und den Betrieb von Comarch-ERP-Enterprise-Systemen überwachen (Monitoring). Für die Konfiguration können Sie folgende Bestandteile ansehen, neu erfassen, bearbeiten oder löschen:

• Arbeitsbereiche
• Application-Server
• Benutzer
• Benutzergruppen
• Datenbanken
• Datenbank-Kennungen
• Entwicklungsgruppen
• Lizenzen
• Module
• ERP-System-Output-Manager-Verbindungen
• Systeme
• Systemgruppen
• Verarbeitungs-Warteschlangen
• Zertifizierungsstellen

Folgende dieser Objekte sind nicht direkt an ein Comarch-ERP-Enterprise-System gebunden:

• Benutzer
• Benutzergruppen
• Datenbanken vom Inhaltstyp „Systemkonfigurations-Daten“
• Datenbank-Kennungen
• Lizenzen
• Zertifizierungsstellen

Diese Objekte werden ohne die Angabe eines Systems erfasst und stehen systemübergreifend zur Verfügung. Wurde nach dem Importieren einer Lizenz ein System erzeugt, kann dies folgende Komponenten umfassen:

• Datenbanken
• Application-Server
• Verarbeitungs-Warteschlangen
• ERP-System-Output-Manager-Verbindungen
• Arbeitsbereiche

Um diese Komponenten zu erfassen oder zu öffnen, muss immer der Name des Systems, gefolgt von einem Punkt und dem eigentlichen Namen des Objekts, angegeben werden.

Daneben gibt es weitere Objekte, die an ein Comarch-ERP-Enterprise-System nicht gebunden sind:

• Entwicklungsgruppen
• Module
• Systemgruppen

Eine Entwicklungsgruppe wird ohne Angabe des Systemnamens angelegt. Falls eine Entwicklungsgruppe angelegt ist, können

• Module und
• Systemgruppen

erfasst werden. Um diese Komponenten zu erfassen oder zu öffnen, muss immer der Name der Entwicklungsgruppe, gefolgt von einem Punkt und dem eigentlichen Namen des Objekts, angegeben werden.

Für das Monitoring der aktiven Komponenten wie z. B. Systeme, Application Server und ERP-System-Output-Manager-Verbindungen bietet das Systemcockpit umfangreiche Funktionen und Abfragemöglichkeiten. Hierbei ist zu beachten, dass nicht immer alle Daten angezeigt werden können, wenn sie mit einem neueren Comarch-ERP-Enterprise-System auf ein älteres Comarch-ERP-Enterprise-System zugreifen, da in diesem Fall das alte Comarch-ERP-Enterprise-System nicht alle Daten übermittelt.

Dieses Dokument enthält einführende allgemeine Informationen zur Anwendung „Systemcockpit“. Die Bedeutung der einzelnen Felder der oben genannten Objekte sowie die typspezifische Bedienung der Anwendung finden Sie in den folgenden Dokumenten:

Typ „Application-Server“

Typ „Arbeitsbereich”

Typ „Benutzer”

Typ „Benutzergruppe”

Typ „Datenbank“

Typ „Datenbank-Kennung“

Typ „Entwicklungsgruppe“

Typ „Lizenz“

Typ „Modul“

Typ „ERP-System-Output-Manager-Verbindung“

Typ „System“

Typ „Systemgruppe“

Typ „Verarbeitungs-Warteschlange“

Typ „Zertifizierungsstelle“

Dialogfenster zu Zertifikaten

Die Vorgehensweisen vor, während und nach dem Einrichten eines Comarch-ERP-Enterprise-Systems sind in separaten Dokumentationen beschrieben:

• In den Dokumentationen im Ordner „System erstellen und einrichten“.
• In der Dokumentation Systemlandschaft einrichten.

1.1               Änderungen an Konfigurationsobjekten

Die Konfigurationsdatenbank ist die einzige Datenbank innerhalb einer Comarch-ERP-Enterprise-Systemfamilie, die von mehreren Comarch-ERP-Enterprise-Systemen gleichzeitig verwendet wird. Dies ermöglichst es zum einen, dass systemübergreifende Daten, wie beispielsweise Benutzer, nur einmal erfasst werden müssen und dass zum anderen die Topologie und die zentralen Einstellungen eines Comarch-ERP-Enterprise-Systems von einem anderen Comarch-ERP-Enterprise-System aus administriert werden können. Dies ist unter anderem hilfreich, wenn ein neues System erfasst werden soll oder ein bestehendes System auf Grund von Konfigurations- oder Hardwareprobleme nicht mehr starten kann und umkonfiguriert werden muss.

Caching von Konfigurationsobjekten

Um wie bei allen anderen Business Objects die Anzahl der Datenbank-Zugriffe auf die Konfigurationsobjekte zu minimieren, werden auch ihre Daten im Shared-Cache der Application-Server zwischengespeichert. Wenn Sie dabei auf einem System A angemeldet sind und die Daten eines Application-Servers X des System A verändern, so werden über den Mechanismus des Cache-Abgleichs[1] diese Änderungen an alle Application-Server des Systems A kommuniziert. Wenn Sie jedoch an einem System B angemeldet sind und die Daten eines Application-Servers A.X verändern, so werden nur die Application-Server des Systems B über diese Änderungen informiert. Da dem System B nicht bekannt ist, welche anderen Systeme gestartet sind und die Abfrage jedes potenziell gestarteten Systems sehr lange dauern würde, werden somit zunächst nur die Shared-Caches des Systems B aktualisiert. Auf den Application-Servern des Systems A, die diese Daten bereits im Shared-Cache halten, werden Sie in der Anwendung „Systemcockpit“ in diesem Fall zunächst veraltete Daten sehen.

In den meisten Fällen ist dies unkritisch und nicht von Bedeutung. Um die Änderungen auf den anderen Systemen sichtbar zu machen, gibt es mehrere Möglichkeiten, wenn dies notwendig ist:

• Das betroffene Objekt auf System A öffnen und speichern:
  Melden Sie sich auf einem beliebigen Application Server des Systems A an, Öffnen Sie die Anwendung „Systemcockpit“. Öffnen Sie das Objekt, bei dem veraltete Daten angezeigt werden und drücken Sie den Button „Speichern“ in der Standard-Symbolleiste. Sie erhalten die Meldung, dass die Daten (auf der Datenbank) bereits verändert wurden und Sie das Objekt erneut öffnen müssen. Wenn Sie nun das Objekt erneut öffnen, werden die richtigen Daten angezeigt. Dies gilt automatisch für alle Application-Server des Systems A, d. h. Sie müssen diese Aktionen nur ein Mal durchführen.
• Einen oder alle Application-Server des Systems A durchstarten:
  Beim Durchstarten werden die Shared-Caches geleert und neu mit den dann aktuellen Inhalten der Konfigurationsdatenbank gefüllt. Dies ist vor allem für wenig genutzte Systeme und Demosysteme die effektivste Vorgehensweise. Bei einigen Änderungen ist diese Vorgehensweise auch notwendig. Dies ist nachfolgend beschrieben.

Erfassen von neuen Konfigurationsobjekten

Beim Erfassen neuer Konfigurationsobjekte, z. B. eines Benutzers, und in den meisten Fällen auch beim Hinzufügen von Zuordnungen, z. B. die Zuordnung eines Benutzers zu einer Benutzergruppe oder einem System, sind meist keine weiteren Aktionen notwendig, um diese neuen Daten auf allen Systemen zu verwenden. Dies liegt darin begründet, dass die Daten von Konfigurationsobjekten auf Grund ihrer Cache-Einstellungen nur im Shared-Cache zwischengespeichert werden, wenn sie existieren. Erst wenn das Objekt einmal gefunden wurde, stehen seine Daten im Shared-Cache und es gelten die Regeln aus dem vorherigen Abschnitt. Ausnahmen zum Verhalten beim Erfassen von neuen Konfigurationsobjekten sind im folgenden Abschnitt „Erfassen und Ändern von aktiven Komponenten“ beschrieben.

Erfassen und Ändern von aktiven Komponenten

Bei den meisten Änderungen an den Einstellungen für die aktiven Komponenten eines Semriamis-Systems (z. B. Application-Server, Datenbank, SOM), z. B. dem Ändern der Datenbankverbindungen eines Application-Servers, ist das Durchstarten der Application-Server bzw. des System prinzipiell notwendig. Dies liegt darin begründet, dass viele dieser Einstellungen beim Start eines Application-Servers einmalig gelesen werden und dafür entsprechende Laufzeitobjekte (z. B. JDBC-Verbindungen, Threads) erzeugt werden, die nicht ohne weiteres verändert werden können. Prinzipiell gelten folgende Regeln:

• Bei Änderungen an einem Application-Server und den dem Application-Server zugeordneten Objekten (z. B. der Verarbeitungs-Warteschlange) muss der Application-Server durchgestartet werden.
• Bei Änderungen an einem System und dem System zugeordneten Objekten (z. B. der ERP-System-Output-Manager-Verbindung) muss das System durchgestartet werden.

Abweichungen oder Ergänzungen zu diesen Regeln sind nachfolgend an der jeweiligen Stelle beschrieben.

Löschen von bestehenden Konfigurationsobjekten

Bestehende Konfigurationsobjekte können nur gelöscht werden, wenn sie innerhalb der gleichen Konfigurationsdatenbank nicht mehr verwendet werden. Beim Löschen eines Konfigurationsobjektes werden Verwendungen in anderen Datenbanken, z. B. die Verwendung eines Benutzers in den Änderungsinformationen eines Artikels auf einer OLTP-Datenbank oder die Verwendung einer Verarbeitungs-Warteschlange im Customizing eines System, nicht überprüft. Am Beispiel des Benutzers ist leicht nachzuvollziehen, dass eine Überprüfung aller Verwendungen in allen Änderungsinformationen der Datenbanken aller Systeme sowohl technisch als auch unter Performanceaspekten nicht sinnvoll ist. Aus diesem Grund sind alle Verwendungen von Konfigurationsobjekten außerhalb der Konfigurationsdatenbank immer tolerant bzgl. der Tatsache, dass ein verwendetes Konfigurationsobjekt zur Laufzeit nicht mehr gefunden werden kann. Um die potenziell so ungültig gewordenen Daten zu entfernen, existieren entsprechende Anwendungen und Toolshell-Befehle, die auf dem jeweiligen System aufgerufen werden können. Beim Versuch, ein Konfigurationsobjekt zu löschen, das innerhalb der Konfigurationsdatenbank nicht mehr verwendet wird, erhalten Sie aus diesem Grund den Hinweis: „Wenn Sie dieses Konfigurationsbjekt löschen, müssen Sie gegebenenfalls auf den Systemen, die dieses Objekt verwenden, Reorganisationen durchführen. Möchten Sie wirklich löschen?“.

1.2               Leistungsbestimmende Einstellungen

Die Objekte in der Systemkonfigurations-Datenbank definieren die Systemlandschaft und die Kommunikationswege und –einstellungen der aktiven Komponenten eines Comarch-ERP-Enterprise-Systems. Die aktiven Komponenten eines Comarch-ERP-Enterprise-Systems sind die ERP-System-Application-Server und der ERP-System-Output-Manager und die verwendeten Datenbanken. Ihre Anzahl und ihre Einstellungen haben entscheidenden Einfluss auf:

• den Ressourcenverbrauch auf den beteiligten Rechnern
• die Stabilität des Systems und
• die Leistung des Systems.

Nachfolgend sind die wesentlichen Einstellungsmöglichkeiten mit Hinweisen auf weiterführende Dokumentationen oder mit konkreten Beschreibungen aufgeführt.

1.2.1          JVM-Einstellungen

Comarch ERP Enterprise ist mit der Programmiersprache Java entwickelt worden, deshalb wird die Hauptspeicherverwaltung zur Laufzeit eines ERP-System-Application-Servers (SAS) weitgehend durch die automatische Garbage Collection (GC) der Java Virtual Machine (JVM) übernommen. Um einen performanten Betrieb eines SAS zu ermöglichen, sind Parametereinstellungen für die Java Virtual Machine notwendig, um Einfluss auf die Garbage Collection zu nehmen. Diese Einstellungen können Sie in der Ansicht für den Typ „Application-Server“ vornehmen. Die Empfehlungen für die Einstellungen finden Sie in der Dokumentation JVM-Einstellungen.

1.2.2          Application-Server-Cache-Einstellungen

Der Shared-Cache dient zur Speicherung von Instanzen von Business Objects im Hauptspeicher. Alle Sessions eines ERP-System-Application-Servers benutzen gemeinsam diesen Cache. Dadurch wird erreicht, dass Daten, die von unterschiedlichen Sessions sehr oft gelesen werden, nur einmal im Hauptspeicher vorhanden sein müssen. Es werden darüber hinaus die Datenbankzugriffe verringert, was eine Geschwindigkeitssteigerung des Systems zur Folge hat. Hierbei ist der physikalisch vorhandene Speicher und seine Aufteilung innerhalb der JVM und innerhalb von Comarch ERP Enterprise zu beachten. Sie hängen aus diesem Grund auch mit den JVM-Einstellungen zusammen. Einstellungen für den Shared-Cache für alle bzw. einzelne Application-Server können Sie in der Anwendung Application-Server-Einstellungen vornehmen.

1.2.3          Datenbankverbindungen

Für jeden Zugriff auf die Datenbank wird eine Datenbankverbindung benötigt. Je mehr Datenbankzugriffe parallel erfolgen, desto mehr Datenbankverbindungen werden benötigt. Wie viele Datenbankzugriffe parallel erfolgen, hängt von der Last des Application-Servers ab. Die Last eines Application-Servers hängt von vielen Faktoren ab. Das sind unter anderem die Anzahl der interaktiven Benutzer, die SOM-Zugriffe, sonstige entfernte Zugriffe oder aktive Verarbeitungsaufträge. Wenn die Anzahl der Datenbankverbindungen zu klein ist, so kann es zu Fehlern im Betrieb kommen. Auf der anderen Seite kostet jede Datenbankverbindung Ressourcen im Datenbankserver. Es muss also bei der Wahl der Anzahl der Datenbankverbindungen zwischen diesen beiden Anforderungen abgewogen werden. Nachfolgend sind die Einflussgrößen und Heuristiken zur Berechnung der sinnvollen Anzahl an Datenbankverbindungen aufgeführt.

Datenbankverbindungen zur OLTP-Datenbank

Auf der OLTP-Datenbank liegen alle betriebswirtschaftlich relevanten Daten und daher hat diese Datenbank die meisten Datenbankzugriffe. Die Anzahl der Datenbankverbindungen ist daher für diese Datenbank am höchsten. Der Verwendungszweck des Application-Servers bestimmt, wie sich die Anzahl der Datenbankverbindungen für die OLTP-Datenbank berechnet.

Einflussgrößen „Interaktive Benutzer“

Die Anzahl der interaktiven Benutzer, die gleichzeitig auf den Application-Server zugreifen, bestimmt, wie viele Datenbankverbindungen für diesen Zweck benötigt werden. Selbst wenn keine interaktiven Benutzer auf einen Ap-plication-Server zugreifen, sollten immer mindestens 10 Datenbankverbindun-gen zur Verfügung stehen.

Wenn der Application-Server interaktiv genutzt wird, d.h. wenn mindestens 10 interaktive Benutzer gleichzeitig auf einem Application-Server arbeiten, so bestimmt die Anzahl der gleichzeitig aktiven Threads für die Verarbeitung der Dialog-Anfragen die Anzahl der für den Application-Server benötigten Datenbankverbindungen. In der Dokumentation „ERP-Properties“ ist beschrieben, wie Sie die Anzahl der Dialog-Threads für interaktive Benutzer mithilfe der Property „com.cisag.sys.gui.jobcontrol. MaximumDialogOnlineThreads“ einstellen. Die folgende Formel für die Abschätzung der benötigten Datenbankverbindungen ist die Basis für alle folgenden Kapitel.

OLTP-Datenbankverbindungen = 10 + (#Threads-für-interaktive-Benutzer * 2)

Der Vorschlagswert für die Anzahl der Dialog-Threads ist 5. Application-Server mit mehr als 10 angemeldeten interaktiven Benutzern sollten demnach 20 Datenbankverbindungen haben.

Einflussgröße „Verarbeitungswarteschlangen“

Zusätzlich zu zuvor berechneten Datenbankverbindungen werden, sofern Verarbeitungs-Wartschlangen auf einem Application-Server eingerichtet sind, für jeden Thread in jeder Verarbeitungs-Wartschlange zwei Datenbankverbindungen benötigt.

OLTP-DB-Verbindungen += (#Verarbeitungs-Warteschlangen-Threads * 2)

Einflussgröße „ODBC-Zugriffe und SOM“

Zusätzlich zu den zuvor berechneten Datenbankverbindungen werden, sofern auf diesen Application-Server via ODBC zugegriffen wird, für jeden gleichzeitigen ODBC-Zugriff drei Datenbankverbindungen benötigt. Die Anzahl der gleichzeitigen ODBC-Zugriffe bestimmt sich aus der Konfiguration des auf den Application-Server zugreifenden ERP-System-Output-Manager (SOM) und daraus, wie viele Personen gleichzeitig mit dem interaktiven ODBC-Treiber auf diesen Application-Server zugreifen.

#ODBC-Sessions = #SOM-Berichtsprozessoren +#Interaktiver-ODBC-Benutzer

OLTP-DB-Verbindungen += (#ODBC-Sessions * 3)

Einflussgröße „CORBA-Zugriffe“

Zusätzlich zu den zuvor berechneten Datenbankverbindungen werden weitere Datenbankverbindungen benötigt, sofern auf diesem Application-Server der CORBA Server gestartet ist und CORBA-Clients auf diesen zugreifen. Für jeden gleichzeitigen CORBA-Client-Zugriff werden zwei Datenbankverbindungen benötigt.

OLTP-DB-Verbindungen += (#Corba-Sessions * 2)

Datenbankverbindungen zu anderen Datenbanken

Die Anzahl der Verbindungen zur OLTP-Datenbank wird als Maß für die Gesamtlast des Application-Servers verwendet und bestimmt damit auch die Anzahl der Datenbankverbindungen bei den anderen Datenbanken.

Die Konfigurations-Datenbank wird im regulären Betrieb nur selten verwendet.

Konfigurations-DB-Verbindungen = 5 + (OLTP-DB-Verbindungen / 10)

Die Repository-Datenbank des Systems enthält alle technischen Daten, die zum Betrieb des Systems notwendig sind, sowie alle OLTP-Datenbank-übergreifenden Daten.

Repository-DB-Verbindungen = 10 + ( OLTP-DB-Verbindungen / 3)

Die OLAP-Datenbanken enthalten Statisikdaten zu den OLTP-Datenbanken.

OLAP-DB-Verbindungen = 10 + ( OLTP-DB-Verbindungen / 5 )

1.2.4          Threads

Threads sind eine Unterteilung des Betriebssystem-Prozesses der Java Virtual Machine, die parallele Ausführungsstränge im gleichen Prozess und eine bessere Ausnutzung von CPU-Kapazitäten ermöglichen. Die Menge der Threads, die ein Application-Server und somit eine JVM verwaltet, hat Einfluss auf den Speicherbedarf und auf die CPU-Auslastung. Jeder Thread benötigt – unabhängig davon, ob er aktiv ist oder nicht – ca. 0,5 MB Speicher für seine Stack und native Verwaltungsstrukturen. Jeder aktive Thread belegt zudem CPU-Kapazität. Da eine CPU zu einem Zeitpunkt nur einen Thread bearbeiten kann und der Wechsel zwischen zwei Threads Laufzeitkosten verursacht, muss darauf geachtet werden, dass nicht zu viele Threads gleichzeitig aktiv werden können. Ist die Anzahl der aktiven Threads zu groß, so

• übersteigt die CPU-Auslastung möglicherweise 70% und der Application-Server befindet sich im Überlastbereich. Er wird instabil und die Antwortzeiten werden überproportional länger.
• wird möglicherweise zu viel eingehende Last auf die Datenbank weitergereicht und damit auch die Leistung anderer Application-Server beeinträchtigt.

Die Anzahl der Threads und die Zeitpunkte, zu denen ein ERP-System-Application-Server sie erzeugt, hängt von den Diensten ab, die er zur Verfügung stellt.

• Threads für den Web Server:
  Jeder Application-Server, der nicht mit dem Parameter „-tool“ gestartet wird, startet automatisch den Web Server. Dieser erzeugt initial 20 Threads für die Bearbeitung von „https://“ –Anfragen, z. B. für normale Dialog-Zugriffe oder auch Knowledge-Store-Zugriffe. Diese Threads werden in einem Pool verwaltet. Auf Grund der Eigenschaften des Browsers benötigt die Bearbeitung eines Roundtrips einen bis ca. 3 Threads, z. B. für das Nachladen von Icons. Wenn mehr Anfragen eingehen, als Threads zur Verfügung stehen, werden neue Threads erzeugt, die anschließend im Pool verbleiben. Wenn zu viele Anmeldungen zum Web Server hin geöffnet werden, entstehen somit zu viele Threads. In diesem Fall sollte ein weiterer ERP-System-Application-Server eingerichtet und ein Teil der Anfragen auf diesen umgeleitet werden.
• Threads für den CORBA Server:
  Wird auf einem ERP-System-Application-Server ein CORBA Server gestartet, erzeugt dieser einen Thread für das Empfangen von CORBA-Anfragen. Jede aktive Anmeldung eines CORBA-Clients an den CORBA Server erzeugt einen weiteren Thread für das Ausführen von Hintergrund-Anwendungen im Rahmen der System Engine. Dieser Thread bleibt bis zur Abmeldung des CORBA-Clients bestehen. Nähere Informationen zum CORBA Server und seiner Resourcennutzung finden Sie in der Dokumentation CORBA-Schnittstelle.
• Threads für den Rechungswesen Server:
  Wird auf einem ERP-System-Application-Server ein Rechnungswesen Server gestartet, so werden Threads für die CORBA-Kommunikation mit den Rechnungswesen-Clients, den Zugriff auf die Datenbank und asynchrone Verabe. Die Verwaltung dieser Threads übernimmt der ORB bzw. der Rechnungswesen-Server selbst. In produktiv genutzten Systemen sollte aus diesem Grund ein dedizierter ERP-System-Application-Server für diesen Verwendungszweck eingerichtet werden.
• Threads für Verarbeitungs-Warteschlangen:
  Verarbeitungs-Warteschlangen partionieren und koordinieren die Ausführung von Hintergrund-Anwendungen. Der Sinn einer Verarbeitungs-Warteschlage ist dabei, durch die Anzahl der parallel ausgeführten Hintergrund-Anwendungen so zu begrenzen, dass die CPU des Application-Servers nicht überlastet wird. Hierzu verfügt die Verarbeitungs-Warteschlange über eine Einstellung für die Anzahl der Threads, die beim Start des Application-Servers für die Hintergrund-Verarbeitung erzeugt und reserviert werden. Die Empfehlung für diese Einstellung hängt von der Nutzung des Application-Servers ab und ist nachfolgend beschrieben.

Threads für Verarbeitungs-Warteschlangen

Es gibt im Wesentlichen drei Arten von Hintergrund-Anwendungen, die unterschiedlichen Einfluss auf die Last und den CPU-Bedarf haben:

• Permanente, passive Dienste:
  Verarbeitungsaufträge für permanente passive Dienste wie den Entwicklungsauftragsdienst-Server werden mit der Startart „Beim Neustart des Application-Severs“ gestartet und verbleiben nach dem Start in einer Endlosschleife, in der sie Anfragen von Clients, z. B. den Entwicklungsauftragsdienst-Clients anderer Systeme, empfangen. Diese Dienste belegen einen Thread in der Verarbeitungs-Warteschlange und erzeugen zumeist noch selbst einen weiteren Thread für die Kommunikation mit den Clients. Bei passiven Diensten sind diese Threads fast immer im Zustand „Wartend“ und belegen zwar Speicher, aber keine CPU-Resourcen.
• Permanente, aktive Dienste:
  Auch Verarbeitungsaufträge für permanente aktive Dienste wie der Lagerlogistik-Server oder die Reorganisation des Verlaufs werden mit der Startart „Beim Neustart des Application-Severs“ gestartet und verbleiben nach dem Start in einer Endlosscheife. Innerhalb dieser Schleife führt der Dienst automatisch (periodisch oder über den Cache-Abgleich angestoßen) zu meist recht komplexen Operationen im Application-Server und auf der Datenbank aus. Der für den Dienst reservierte Thread der Verarbeitungs-Warteschlange ist häufig im Zustand „Aktiv“ und belegt dann neben dem Speicher auch CPU- und Datenbank-Resourcen. Wenn zu viele dieser Dienste dem gleichen Application-Server zugeordnet sind, kann dies bei hoher Last zur Überlastung des Application-Servers oder der Datenbank führen.
• Einmalige Verarbeitungsaufträge:
  Die von der Anzahl her größte Menge an Verarbeitungsaufträgen sind von Benutzern erzeugte, einmalige Verarbeitungsaufträge wie beispielsweise die Erzeugung und Ausgabe einer Auftragsbestätigung. Diese Verarbeitungsaufträge sind zumeist sehr ressourcenintensiv. Aus diesem Grund übernimmt die Verarbeitungs-Warteschlange die Abarbeitung in Form einer echten Warteschlange. Wenn ein Thread in der Verarbeitungs-Warteschlange frei wird, sucht dieser nach dem nächsten der Verarbeitungs-Warteschlange zugeordneten Verarbeitungsauftrag im Status „Freigegeben“ und übernimmt dessen Ausführung. Da eine CPU nur eine sehr begrenzte Anzahl an aktiven Threads effektiv bearbeiten kann, sollte auf einem Application-Server die Anzahl der für diese Art von Verarbeitungsaufträgen vorgesehenen Threads nicht größer als 2-3 je CPU sein.

Somit ergibt sich als Empfehlung für die Anzahl der Threads in einer Verarbeitungs-Warteschlange:

# Threads = # Permanente Dienste + ( 2,5 * #CPUs )

Es ist im Allgemeinen nicht sinnvoll, einem Application-Server mehrere Verarbeitungswartschlangen zuzuordnen, da dies den gleichen Effekt hat wie das Erhöhen der Anzahl der parallelen Threads.

Hinweis: Es gibt die Möglichkeit, die Verarbeitungsaufträge mithilfe von verteilten Verarbeitungs-Warteschlangen abzuarbeiten. Diese ermöglichen, die Verarbeitungsaufträge einer Verarbeitungs-Warteschlange auf mehr als einem ERP-System-Application-Server auszuführen. Hierdurch kann ein höherer Gesamtdurchsatz und eine automatische Umverteilung der Last beim Ausfall eines beteiligten ERP-System-Application-Servers erreicht werden. Deshalb wird die Verwendung von verteilten Verarbeitungs-Wartschlangen empfohlen. Die oben berechnete Anzahl Threads kann in diesem Fall für jeden Application-Server getrennt auf dem Karteireiter „Worker“ erfasst und verteilten Verarbeitungs-Wartschlangen zugeordnet werden.

Monitoring von Threads und Sessions

In der Anwendung „Systemcockpit“ stehen erweiterte Monitoring-Möglichkeiten für Threads zur Verfügung. Neben der Möglichkeit zwischen Threads und Sessions zu navigieren, können auch bestimmten Zeiten wie z.B. die von einem Thread oder einer Session bis jetzt in Anspruch genommene CPU-Zeit abgefragt werden. Abhängig von der JVM-Implementierung ist die Überwachung dieser Zeiten und anderer Informationen nicht möglich, standardmäßig nicht aktiv oder kann explizit aktiviert werden. Die Aktivierung kann, wenn die JVM-Implementierung dies prinzipiell unterstützt, mit Hilfe der beiden ERP-Properties „com.cisag.sys.kernel.ThreadManagerThreadCpuTimeMode“ bzw. „com.cisag.sys.kernel.ThreadManagerThreadContentionMonitoringMode“ erfolgen. Nähere Informationen hierzu finden Sie in der Direkthilfe der ERP-Properties bzw. in der Dokumentation ERP-Properties.

Den aktuellen Status der Überwachung sehen Sie in auf dem Karteireiter „Threads“ beim Typ „Application-Server“.

Um die Analyse zu erleichtern sind in den Listen, in denen Sessions und Threads dargestellt werden, immer auch die ganzzahligen Identifikationen des Session bzw. des Threads dargstellt. Diese identifizieren eines Session bzw. einen Thread innerhalb eines ERP-System-Application-Servers. Die ganzzahlige Identifikation des Threads wird zumeist auch von externen Monitoring-Werkzeugen, die zur Überwachung der JVM genutzt werden können verwendet.

Die Felder, in denen die ganzzahligen Identifikationen dargestellt werden, verfügen über eine integrierte Navigationsmöglichkeit in Form einer Link-Funktion, wie es sie auch bei Feldern für Business Entitys gibt. Über das Anklicken der Identifikation einer Session gelangen Sie auf den Karteireiter „Sessions“ für den Typ „Application-Server“, wobei standardmäßig die angegebene Session und ihre aktiven Threads angezeigt werden. Über das Anklicken der Identifikation eines Threads gelangen Sie auf den Karteireiter „Sessions“ für den Typ „Application-Server“, wobei standardmäßig der angegebene Thread und sein Stacktrace angezeigt werden.

Die ermöglicht beispielsweise folgende Analysen:

• Analyse, welche Programmstelle aktuell sehr viel CPU-Zeit verbraucht
• Wechseln Sie zum Typ „System“
• Wechseln Sie zum Karteireiter „Sessions“
• Sortieren sie die Anzeige nach „CPU-Zeit“.
• Identifizieren Sie die Session mit dem größten absoluten Bedarf an CPU-Zeit bzw. mit dem größten Zuwachs an CPU-Zeit pro Aktualisierung
• Klicken Sie auf die Identifikation dieser Session
• Das System wechselt zum Typ „Application-Server“ auf den Karteireiter „Sessions“ und zeigt die aktiven Threads für diese Session an
• Prüfen sie den Status der Threads und klicken Sie auf die Identifikation eines Threads.
• Das System wechselt auf den Karteireiter „Threads“ und zeigt den Stacktrace des ausgewählten Threads
• Über die Aktion „Zurück“ in der Standard-Symbolleiste können sie zurück zur Session oder zurück zum System navigieren.
• Analyse, welche Programmstelle eine Datenbankverbindung hält
• Wechsel Sie zum Typ „Application-Server“
• Wechseln Sie zum Karteireiter „Datenbankverbindungen“
• Identifizieren Sie die relevante aktive Datenbankverbindung anhand des Verbindungsstatus bzw. der Eigenschaften der Datenbankverbindung.
• Klicken Sie auf die Identifikation des Threads, der zuletzt die Datenbankverbindung angefordert hat.
• Das System wechselt auf den Karteireiter „Threads“ und zeigt den Stacktrace des ausgewählten Threads
• Über die Aktion „Zurück“ in der Standard-Symbolleiste können sie zurück zur Datenbankverbindung navigieren.

1.2.5          Leistungsinformationen

Comarch ERP Enterprise verfügt über umfangreiche Möglichkeiten Informationen zur Leistungsfähigkeit eines Comarch-ERP-Enterprise-System aufzuzeichnen, zu verdichten und auszuwerten. Die Grundlagen und Vorgehensweisen finden Sie in der Dokumentation Leistungsinformationen protokollieren und auswerten. Neben den dort beschriebenen Möglichkeiten Leistungsinformationen, z. B. in Form von Berichten, abzufragen bietet die Anwendung „Systemcockpit“ auch die Möglichkeit die persistenten und die transienten Leistungsdaten eines Comarch-ERP-Enterprise-Systems auch von anderen Comarch-ERP-Enterprise-Systemen aus abzufragen. Nähere Informationen hierzu finden Sie in der Dokumentation zum Typ „Application-Server“ und in der Dokumentation zum Typ „System“.

2                     Zielgruppe

Systemadministratoren

3                     Anwendungsbeschreibung

Die Anwendung besteht aus einem Identifi­kations- und einem Arbeitsbereich. Im Identifikationsbereich wählen Sie aus, welchen Objekttyp und welches Objekt Sie im Systemcockpit ansehen oder bearbeiten möchten. Im Arbeitsbereich stehen die jeweiligen Einstellungen für das Objekt zur Verfügung. Der Arbeitsbereich im Systemcockpit zeigt für jeden Objekttyp eine eigene Ansicht.

In der Suche im Navigationsbereich stellt das Systemcockpit einen eigenen Karteireiter unter dem Namen „Systemlandschaft“ zur Verfügung. Auf diesem Karteireiter erhalten Sie einen Überblick über alle Objekte, die im Systemcockpit zur Verfügung stehen. Durch Anklicken eines Objekts im Karteireiter „Systemlandschaft“ öffnen Sie das Objekt in der Anwendung.

Abfragemuster und Verlauf

Die Anwendung „Systemcockpit“ beinhaltet neben den Karteireitern für das Erfassen und Ändern von Konfigurationsobjekten für alle aktiven Komponenten, wie z.B. einen Application-Server, auch zusätzliche Karteireiter mit Abfragefeldern. Neben dem aktuell geöffneten Konfigurationsobjekt werden auch der aktive Karteireiter, sowie der Inhalt der Abfragefelder, die aktuelle Sortierung und der Zustand von Toggle-Buttons sowohl im Verlauf als auch in Abfragemustern mit aufgezeichnet. Dies ermöglicht zum einen die Speicherung komplexer Abfragen, z. B. bei den Leistungsinformationen und zum anderen das Navigieren innerhalb der Anwendung „Systemcockpit“ mit Hilfe der Funktionen „Vor“ und „Zurück“ in der Standard-Symbolleiste, z. B. bei Sessions und Threads.

3.1               Identifikationsbereich

Der Identifikationsbereich enthält die Felder, die das im Systemcockpit anzuzeigende Objekt eindeutig identifizieren.

Die Felder im Einzelnen:

Die Bedienung von Suchfeldern wird detailliert im Bedienungsleitfaden unter „Felder und Wertehilfen“ beschrieben.

3.2               Arbeitsbereich

Der Arbeitsbereich bietet je nach Typ des geöffneten Objekts verschiedene Ansichten. Die Ansicht wechseln Sie, indem Sie im Identifikationsbereich einen anderen Typ auswählen.

Für jeden Objekttyp steht ein Karteireiter „Editor“ zur Verfügung, in dem Sie Einstellungen vornehmen können. Für einige Objekttypen stehen weitere Karteireiter zur Verfügung. Sie dienen dem Abfragen von Werten im Rahmen des Monitorings. Das Öffnen der Karteireiter für das Monitoring kann einige Zeit in Anspruch nehmen, wenn der Message Server des Systems oder der ausgewählte Application-Server nicht gestartet ist oder sich einer der aktiven Application-Server des Systems im Debugging befindet und deshalb nicht antwortet.

Im Gegensatz zu allen anderen Anwendungen kann im Systemcockpit und mit Hilfe der zugehörigen Toolshell-Befehle bei der Anlage eines neuen Objekts explizit auch der technische Schlüssel (GUID) angegeben werden. Dies ist im Allgemeinen nicht notwendig, und kann dazu verwendet werden, z. B. im Rahmen eines Release-Wechsels exakte Kopien von Konfigurationsobjekten in einer anderen Konfigurationsdatenbank anzulegen. Beispielsweise kann eine Kopie eines Systems aus einer anderen Konfigurationsdatenbank angelegt werden, um dieses mit Hilfe des Monitorings zu überwachen.

Die einzelnen Ansichten des Arbeitsbereiches werden pro Typ in den folgenden Dokumentationen beschrieben:

Typ „Application-Server“

Typ „Arbeitsbereich”

Typ „Benutzer”

Typ „Benutzergruppe”

Typ „Datenbank“

Typ „Datenbank-Kennung“

Typ „Entwicklungsgruppe“

Typ „Lizenz“

Typ „Modul“

Typ „ERP-System-Output-Manager-Verbindung“

Typ „System“

Typ „Systemgruppe“

Typ „Verarbeitungs-Warteschlange“

Typ „Zertifizierungsstelle“

Dialogfenster zu Zertifikaten

4                     Customizing

Für die Anwendung „Systemcockpit“ sind in der Anwendung „Customizing“ keine Einstellungen festzulegen.

5                     Berechtigungen

Für Berechtigungsfestlegungen für die Anwendung „Systemcockpit“ sind folgende Business Entitys und Business-Entity-Gruppen relevant:

Für Application-Server:

Business Entity com.cisag.sys.configuration.obj.SVM
Business-Entity-Gruppe com.cisag.sys.configuration.SystemObjects

Für Arbeitsbereiche:

Business Entity com.cisag.sys.configuration.obj.WorkSpace
Business-Entity-Gruppe com.cisag.sys.configuration.SystemObjects

Für Benutzer:

Business Entity com.cisag.sys.configuration.obj.User
Business-Entity-Gruppe com.cisag.sys.configuration.UserObjects

Für Benutzergruppen:

Business Entity com.cisag.sys.configuration.obj.UserGroup
Business-Entity-Gruppe com.cisag.sys.configuration.UserObjects

Für Datenbanken:

Business Entity com.cisag.sys.configuration.obj.Database
Business-Entity-Gruppe com.cisag.sys.configuration.SystemObjects

Für Datenbank-Kennungen:

Business Entity com.cisag.sys.configuration.obj.ManagingSystem
Dieses Business Entity ist keiner Business-Entity-Gruppe zugeordnet.

Für Entwicklungsgruppen:

Business Entity com.cisag.sys.configuration.obj.DevelopmentGroup
Dieses Business Entity ist keiner Business-Entity-Gruppe zugeordnet.

Für Lizenzen:

Business Entity com.cisag.sys.configuration.obj.Licence
Dieses Business Entity ist keiner Business-Entity-Gruppe zugeordnet.

Für Module:

Business Entity com.cisag.sys.configuration.obj.Module
Dieses Business Entity ist keiner Business-Entity-Gruppe zugeordnet.

Für ERP-System-Output-Manager-Verbindungen:

Business Entity com.cisag.sys.configuration.obj.OutQueue
Business-Entity-Gruppe com.cisag.sys.configuration.SystemObjects

Für Systeme:

Business Entity com.cisag.sys.configuration.obj.System
Business-Entity-Gruppe com.cisag.sys.configuration.SystemObjects

Für Systemgruppen:

Business Entity com.cisag.sys.configuration.obj.SystemGroup
Dieses Business Entity ist keiner Business-Entity-Gruppe zugeordnet.

Für Verarbeitungs-Warteschlangen:

Business Entity com.cisag.sys.configuration.obj.JobQueue
Business-Entity-Gruppe com.cisag.sys.configuration.SystemObjects

Für Zertifizierungsstellen:

Business Entity com.cisag.sys.configuration.obj.CertificateAuthority
Business-Entity-Gruppe com.cisag.sys.configuration.UserObjects

Spezielle Berechtigungen und Fähigkeiten sind für diese Anwendung nicht erforderlich.

Das Berechtigungskonzept sowie die generellen anwendungsbezogenen und Entity-bezogenen Berechtigungen können Sie in der Dokumentation Berechtigungen nachlesen.

[1]    Nähere Information hierzu finden Sie in den Dokumentationen „Sperrverwaltung“ und „Shared-Cache-Management“.