Serverprozesstypen

Die Automation Engine verwendet fünf Haupttypen von Serverprozessen: Arbeitsprozesse (WP) und Java-Arbeitsprozesse (JWP), Java-Kommunikationsprozesse (JCP), Kommunikationsprozesse (CP) und den REST-Prozess, der spezielle Dienste wie die REST-API hostet. Der Dialogprozess (DWP) ist ein spezieller Arbeitsprozess, der für Automic Web Interface-Meldungen verwendet wird.

Bis Version 12.3 wurde der Java-Kommunikationsprozess (JCP) teilweise verwendet, um einen REST-Endpunkt für die Automation Engine zur Verfügung zu stellen. Der neue REST-Prozess deckt jetzt diese Funktionen ab, während der neue Java-Kommunikationsprozess (JCP) als Kommunikationsprozess (CP) für Komponenten funktioniert, die TLS/SSL und WebSockets verwenden.

Diese Seite beinhaltet Folgendes:

Automation EngineSeite "Verwaltung"

Die Seite Prozesse und Auslastung in der Administration-Perspektive listet alle Serverprozesstypen des AE-Systems auf. Weitere Informationen finden Sie unter Prozesse und Auslastung. Jeder Prozess ist eindeutig identifizierbar:

  • PWP: Primärer Arbeitsprozess

  • WP: Arbeitsprozess

  • CP: Kommunikationsprozess

  • DP: Dialog-Arbeitsprozess

  • JWP: Java-Arbeitsprozess

  • JCP: Java-Kommunikationsprozess

  • REST: REST-Prozess

Hinweis: Sie können auch die Script-Funktion GET_UC_SETTING verwenden, um den Typ eines Serverprozesses zu ermitteln.

Arbeitsprozesse (WP) und Primärer Arbeitsprozess (PWP)

Arbeitsprozesse (WP) übernehmen die eigentliche Serverarbeit. Sie aktivieren, generieren und führen Aufgaben aus und überwachen sie bis zum Ende. Der primäre Arbeitsprozess (PWP) wird für spezielle Aufgaben verwendet. Er führt zentrale Arbeitsprozess (WP)-Aufgaben aus, die nicht verteilt werden dürfen, wie z. B. die Zeitbasis oder die Prozessverwaltung.

Beim Systemstart wird der Arbeitsprozess (WP), der zuerst startet, zum primären Arbeitsprozess (PWP). Wenn der primäre Arbeitsprozess (PWP) fehlschlägt, wird einer der verbleibenden Arbeitsprozesse (WPs) zu einem primären Arbeitsprozess (PWP). Alle relevanten Informationen werden entweder regelmäßig für alle Arbeitsprozesse (WPs) aktualisiert oder in der Datenbank gespeichert.

Der primäre Arbeitsprozess (PWP) ist der einzige Arbeitsprozess (WP), dem ein Port zugewiesen ist. Dieser Port wird im Parameter pwpPort= im Abschnitt [TCP/IP] der INI-Datei der Automation Engine angegeben. Weitere Informationen finden Sie unter Automation Engine.

Die restlichen Arbeitsprozesse (WPs) stellen eine Verbindung mit dem primären Arbeitsprozess (PWP) und den Kommunikationsprozessen (CPs) her. Aus diesem Grund muss ihnen kein Port zugewiesen werden, und sie richten die Verbindung über den Port ein, der dem Prozess (PWP oder CP) zugewiesen ist, zu dem sie eine Verbindung herstellen.

Arbeitsprozessen wird auch eine Prozessnummer zugewiesen, die die Reihenfolge angibt, in der sie gestartet werden.

Beispiel

In einem System mit vier Arbeitsprozessen (WPs) werden die Prozesse wie folgt zugewiesen:

  • WP001 - PWP (primärer Arbeitsprozess)

  • WP002 - OWP (Arbeitsprozess mit Serverrolle)

  • WP003 - RWP (Arbeitsprozess mit Serverrolle)

  • WP004 - DWP (Dialogprozess)

Wenn WP001 aus irgendeinem Grund angehalten wird, übernimmt ein anderer Arbeitsprozess (WP) die Rolle des primären Arbeitsprozesses (PWP). Allerdings behält dieser Arbeitsprozess die beim Start zugewiesene Prozessnummer bei. Das System hat nur drei Arbeitsprozesse (WP002, WP003, WP004); WP001 ist nach einem Neustart wieder verfügbar.

Die gleiche Argumentation gilt für alle anderen Prozesse. Wenn WP002 aus irgendeinem Grund endet, hat das System nur WP001, WP003 und WP004. WP002 ist nach einem Neustart wieder verfügbar.

WP-Serverrollen

Einige Aufgaben erfordern mehr Aufmerksamkeit als andere, wenn sie verarbeitet werden. Aus diesem Grund und um negative Auswirkungen auf die Leistung Ihres Systems zu vermeiden, erhalten sie eine Serverrolle. Jede Serverrolle hat ihre eigene Queue, in der die entsprechenden Aufgaben gespeichert sind.

Die folgenden Serverrollen sind verfügbar:

  • O für Outputs (Ausgaben)
    • Speichert Logmeldungen von Serverprozessen und Agenten in der AE-Datenbank
    • Speichert Aktivierungslogs von ERP- und Java-Agenten der Automation Engine
    • Ist verantwortlich für das Deaktivieren von Aufgaben.
  • R für Ressourcenberechnungen
    • Überprüft Sync-Objekte
    • Errechnet Kalenderobjekte
    • Maximale Anzahl gleichzeitiger Objektausführungen
    • Konsolenartige Ereignisse
    • Automatische FILE-Ereignisse
    • Vermeidung von Deadlocks

In der Spalte Rolle der Seite Prozesse und Auslastung in der Administration-Perspektive wird angezeigt, ob dem Arbeitsprozess (WP) eine Serverrolle zugewiesen wurde, und welche diese ist. Weitere Informationen finden Sie unter Prozesse und Auslastung.

Jede Rolle wird nur ein Mal vergeben. Wenn die Automation Engine startet, erhält der primäre Arbeitsprozess (PWP) beide Serverrollen. Wenn ein zweiter Arbeitsprozess (WP) startet, weist der primäre Arbeitsprozess (PWP) diesem Arbeitsprozess (WP) die erste Serverrolle zu. Der Arbeitsprozess (WP), der als Dritter startet, erhält die zweite Serverrolle. Wenn ein Arbeitsprozess (WP) endet, übernimmt der primäre Arbeitsprozess (PWP) diese Serverrolle wieder und weist sie einem anderen Arbeitsprozess (WP) zu, dem noch keine Serverrolle zugewiesen wurde. Wenn kein solcher Arbeitsprozess (WP) vorhanden ist, behält der primäre Arbeitsprozess (PWP) die Serverrolle.

Ein Arbeitsprozess (WP) verarbeitet immer zuerst die Aufgaben seiner eigenen Serverrolle. Wenn es für diese Rolle keine Aufgaben gibt, verarbeitet er Aufgaben der allgemeinen Queue des Arbeitsprozesses (WP).

Das Starten eines Arbeitsprozesses (WP) im Kaltstart-Modus führt dazu, dass alle Aufträge, die noch verfügbar sind, gelöscht werden.

Hinweis: Ignorieren Sie die folgenden Fehlermeldungen, die in die Logdatei geschrieben werden, wenn der erste Arbeitsprozess (PWP) im Kaltstartmodus startet:

U0029108 SQL_ERROR Database-Handles  DB-HENV: 6d92d0  DB-HDBC: 6d93a0

U0003591 DB error info: Opc: 'SQLExecDirect' Return code: 'ERROR'

U0003594 UCUDB Ret: '3590' OpCode: 'EXEC' SQL-Stmnt: '{call UC_Truncate_Table('MQCP006')}'

U0003590 DB error: 'SQLExecDirect', 'ERROR  ', '42S02', 'Objekt "MQCP006" nicht gefunden, weil es nicht existiert, oder Sie keine Berechtigungen besitzen.'

Dialogprozesse

Dialog Prozesse (DWPs) sind eine spezielle Form von Arbeitsprozessen (WP). Sie funktionieren genau wie Arbeitsprozesse (WPs), werden aber ausschließlich für Automic Web Interface-Meldungen verwendet. Es wird empfohlen, eine bestimmte Anzahl von Arbeitsprozessen (WPs) zu Dialogprozesse (DWPs) zu machen, um die Leistung zu verbessern, falls der primäre Arbeitsprozess (PWP) komplexe Abfragen oder große Datenmengen verarbeiten muss.

Wichtig! Weder der primäre Arbeitsprozess (PWP) noch Arbeitsprozesse (WPs), denen eine Serverrolle zugewiesen ist, können zu einem Dialogprozess (DWP) gemacht werden. Das bedeutet auch, dass zusätzlich zum primären Arbeitsprozess (PWP) noch zwei Arbeitsprozesse (WPs) laufen müssen, bevor Sie einen Dialogprozess (DWP) einsetzen können.

Wenn der letzte Dialogprozess (DWP) beendet ist, übernimmt der Arbeitsprozess (WP) die Automic Web Interface-Meldungen. Dies bedeutet, dass ein Automation Engine-System ohne Dialogprozesse (DWPs) funktionieren kann.

Arbeitsprozesse ändern

Sie können den Servermodus eines Arbeitsprozesses (WP) in einen Dialogprozess (DWP) ändern. Sie können auch den Servermodus eines Dialogprozesses (DWP) in einen Arbeitsprozess (WP) oder einen primären Arbeitsprozess (PWP) ändern.

Klicken Sie auf der Seite Prozesse und Auslastung der Administration-Perspektive mit der rechten Maustaste auf den entsprechenden Prozess, und wählen Sie Servermodus > Servermodus ändern in <xxx> aus. Weitere Informationen finden Sie unter Prozesse und Auslastung.

Alternativ können Sie auch die Script-Anweisung: :SET_UC_SETTING verwenden, um den Servermodus von Arbeitsprozessen (WPs) zu ändern.

Systemeinstellungen

Sie können einen Standardwert definieren, um die Anzahl der Arbeitsprozesse (WPs) zu steuern. Verwenden Sie den Schlüssel WP_MIN_NUMBER in der Variablen UC_SYSTEM_SETTINGS, um einen Knotennamen und die Mindestanzahl der Arbeitsprozesse (WPs) zu definieren. Die Arbeitsprozesse (WPs), die diese Zahl überschreiten, werden zu Dialogprozessen (DWPs). Weitere Informationen finden Sie unter WP_MIN_NUMBER.

Hinweis: Dies hat keinen Einfluss auf den PWP.

Der Name, den Sie als Knotennamen angeben, muss auch im entsprechenden Abschnitt der INI-Datei der Automation Engine definiert werden (siehe Automation Engine). Wenn Sie die Serverprozesse auf mehrere Computer verteilt haben, können Sie pro Computer einen Knotennamen festlegen. Wenn Sie den gleichen Knotennamen in mehreren INI-Dateien verwenden, gilt dieser Name systemweit.

Beispiele

Die Serverprozesse eines AE-Systems sind auf zwei Computer verteilt. Jeder Computer verfügt über drei Arbeitsprozesse (WPs). In den INI-Dateien beider Automation Engine-Instanzen wird der Knotenname auf AUTOMIC gesetzt, damit beide Computer dieselbe Einstellung haben. Um mindestens zwei WPs zur Verfügung zu haben, fügen Sie in der Systemvariablen UC_SYSTEM_SETTINGS folgenden Eintrag hinzu:

WP_MIN_NUMBER AUTOMIC=2

Sind alle drei Arbeitsprozesse (WPs) aktiv, wird einer von ihnen zu einem Dialogprozess (DWP) umgewandelt.

Soll jedoch für jeden der beiden Computer eine unterschiedliche Mindestanzahl an Arbeitsprozessen (WPs) gelten, muss der Inhalt der Systemvariablen wie folgt angepasst werden:

WP_MIN_NUMBER AE_1=2;AE_2=1

Hinweis: Sie müssen auch die Bezeichnungen AE_1 und AE_2 im Knotennamenabschnitt der INI-Datei der Automation Engine angeben.

Kommunikationsprozesse (CP)

Die Kommunikationsprozesse warten darauf, von den Arbeitsprozessen (WPs), anderen Kommunikationsprozessen (CPs) und Nicht-TLS/SSL-Agenten kontaktiert zu werden. Sie erhalten auch eine Prozessnummer, die die Reihenfolge angibt, in der sie gestartet werden. Nach dem Start stellt der primäre Arbeitsprozess eine Verbindung zu einem Kommunikationsprozess(CP) her. 

Die Ports, die den Kommunikationsprozessen (CPs) zugewiesen sind, werden im Parameter CP.PORTS= im Abschnitt [PORTS] der INI-Datei der Automation Engine zugewiesen. Sie können auf unterschiedliche Weise definiert werden:

  • als einzelne Ports, durch Semikolon getrennt

    [PORTS]

    CP.PORTS=2217;2218;2219;2220

  • als Port-Bereich

    [PORTS]

    CP.PORTS=2220-2237

  • als Kombination aus einzelnen Ports und einem Port-Bereich

    [PORTS]

    CP.PORTS=2217;2218;2219;2220-2237

Hinweis: Agenten verwenden Portnummern als Schlüssel.

Wie Prozessnummern müssen die von Kommunikationsprozessen (CPs) verwendeten Portnummern im gesamten System eindeutig sein. Kommunikationsprozesse (CPs) verbinden sich in der Reihenfolge ihrer Deklaration mit Ports.

Beispiel

Wenn der Port-Bereich für Kommunikationsprozesse (CPs) 2217-2221 ist, erhält der erste zu startende Kommunikationsprozess (CP) die Prozessnummer 001 und verwendet Port 2217 (CP001:2217).

In einem System mit mehreren Hosts müssen alle Kommunikationsprozesse (CPs) einen anderen Port verwenden, unabhängig von dem Host, auf dem sie ausgeführt werden. In einem System mit zwei Hosts mit zwei getrennten INI-Dateien können Sie unterschiedliche Port-Sätze verwenden. Auf diese Weise wird sichergestellt, dass die Kommunikationsprozesse (CPs) nach dem Neustart dieselben Ports verwenden.

Beispiel

  • INI-Datei-Definition für Host A

    [PORTS]

    CP.PORTS=2220;2033;2040-2250;2061

  • INI-Datei-Definition für Host B

    [PORTS]

    CP.PORTS=3030;3031;3040-3050:3061

Abhängig von der Anzahl der Mandanten (Nicht-TLS/SSL-Agenten, CallAPIs) wird die Verwendung einer entsprechenden Anzahl von CPs pro Knoten empfohlen.

Mehr Informationen:

Java-Arbeitsprozess

Der Java-Arbeitsprozess (JWP) ist eine spezielle Art von Arbeitsprozess (WP). Er führt die Aufgaben in den relevanten JWP-Queues aus (MQnJWP, MQnAUT, MQnUTL). Er wird auch von anderen Arbeitsprozessen (WPs) kontaktiert, um Synchronisierungsaufrufe durchführen zu können.

Die Prozessnummern, die Java-Arbeitsprozessen zugewiesen sind, geben auch die Reihenfolge an, in der sie gestartet werden, und haben das gleiche Format wie andere Arbeitsprozesse (WPs). Arbeitsprozesse (WPs) suchen die Adresse eines Java-Arbeitsprozesses (JWP) in der Serververwaltungstabelle (MQSRV), wenn sie einen Sync-Aufruf durchführen müssen. Aus diesem Grund kann der Java-Arbeitsprozess (JWP) eine Verbindung zu jedem verfügbaren Port herstellen. Sie können jedoch bestimmte Ports für die Java-Arbeitsprozesse mithilfe des Parameters JWP.SYNC.PORTS= im Abschnitt [PORTS] der INI-Datei der Automation Engine definieren (siehe Automation Engine). Diese Ports können auf unterschiedliche Weise definiert werden:

  • als einzelne Ports, durch Semikolon getrennt

    [PORTS]

    JWP.SYNC.PORTS=2220;2033;2040

  • als Port-Bereich

    [PORTS]

    JWP.SYNC.PORTS=2040-2050

  • als Kombination aus einzelnen Ports und einem Port-Bereich

    [PORTS]

    JWP.SYNC.PORTS=2220;2033;2040-2050;2061

Hinweise:

  • Die Installation von Java-Arbeitsprozessen (JWP) ist obligatorisch. Weitere Informationen finden Sie unter Installation des JWP

  • Sie müssen mehr als einen Java-Arbeitsprozess (JWP) für Automic Web Interface-Dienste starten. Derzeit gibt es keine Arbeitslastverteilung der aufgeführten Dienste zwischen den aktiven Java-Arbeitsprozessen (JWPs) eines Automation Engine-Systems. Im Gegensatz zu anderen Arten von Arbeitsprozessen (WPs).

  • Wenn kein JWP bei der Anmeldung verfügbar ist, schlägt die Anmeldung fehl und es wird eine Fehlermeldung angezeigt. Das System benachrichtigt Sie auch, wenn aus einem bestimmten Grund die Mindestzahl von Prozessen während einer Session nicht erfüllt wird. Die Benachrichtigung wird nicht mehr angezeigt, sobald der Prozess wieder ausgeführt wird.

JWP-Serverrollen

Während der JWP die entsprechenden Queues verarbeitet und ACL-Prüfungen, Sync-Aufrufe, Prognoseaufgaben, ERT usw. verarbeitet, können Sie einem JWP eine Serverrolle zuweisen, damit er eine bestimmte Queue oder Zuweisung verarbeitet. Dadurch können Sie die Last auf JWPs verteilen und Engpässe vermeiden, die sich negativ auf die Leistung Ihres Systems auswirken können.

Die folgenden JWP-Serverrollen sind verfügbar:

  • AUT für Authentifizierung

    • TLS/SSL-Agenten-Authentifizierung
    • LDAP-Benutzerauthentifizierung
    • SAML-Benutzerauthentifizierung
    • Kerberos-Benutzerauthentifizierung

  • PER für Periodisch

    • SLA
    • Telemetrie
    • Leistungsverwaltung

  • UTL für Dienstprogramme

    • Löschen von Mandanten

  • IDX zum Indizieren

    • Objektindizierung (Lucene-Suche)

Die Seite JWP-Rollen im Automation Engine Management-Abschnitt der Administration-Perspektive ermöglicht es Ihnen, die Anzahl der Prozesse zu definieren, die Sie einer Rolle zuweisen möchten, und sie zu ordnen. Weitere Informationen finden Sie unter JWP-Rollen.

In der Spalte Rolle der Seite Prozesse und Auslastung in der Administration-Perspektive wird angezeigt, ob dem Java-Arbeitsprozess (JWP) eine Serverrolle zugewiesen wurde, und welche diese ist. Wenn einem Java-Arbeitsprozess mehr als eine Rolle zugewiesen ist, werden diese durch ein Komma getrennt aufgelistet. Weitere Informationen finden Sie unter Prozesse und Auslastung.

REST-Prozess

Der REST-Prozess stellt einen REST-Endpunkt für die Automation Engine zur Verfügung. Der für diesen Zweck zugewiesene Port wird im Parameter port= im Abschnitt [REST] der INI-Datei der Automation Engine definiert (siehe Automation Engine). Der REST-Anforderung ist nur ein Port zugewiesen. Deshalb ist es nicht möglich, mehr als einen einzelnen Port zuzuweisen.

Hinweise:

  • Mehrere wichtige Funktionen in der Automation Engine, wie das Auslösen und Überwachen von Ausführungen und die erweiterte Objektsuche, hängen davon ab, dass der REST-Prozess installiert ist und ausgeführt wird. Deshalb ist die Installation des REST-Prozesses obligatorisch.
  • Wenn bei der Anmeldung kein REST-Prozess verfügbar ist, schlägt die Anmeldung fehl und es wird eine Fehlermeldung angezeigt. Das System benachrichtigt Sie auch, wenn aus einem bestimmten Grund die Mindestzahl von Prozessen während einer Session nicht erfüllt wird. Die Benachrichtigung wird nicht mehr angezeigt, sobald der Prozess wieder ausgeführt wird.

Die REST-Installation ist sowohl für die AE-REST-API  als auch für die erweiterte Objektsuche relevant. Sie können einen einzelnen REST-Prozess (REST) installieren. In diesem Fall werden alle REST-Anfragen an diese einzelne AE REST-API-Instanz gesendet, und es steht keine REST-API zur Verfügung, wenn der REST-Prozess nicht läuft.

Sie können auch ein System mit mehreren REST-Prozessen einrichten. In diesem Fall werden zwei REST-Prozesse in einem Cluster verwendet, aber nur einer von ihnen ist jeweils verfügbar.

Es wird empfohlen, einen REST-Prozess pro Knoten zu verwenden. Sie können jedoch auch ein System mit mehreren REST-Prozessen einrichten. Dies kann sinnvoll für Lastausgleichszwecke sein, ebenso wie für die Bereitstellung von Ausfallsicherungen, da die REST-Anfragen nur an verfügbare REST-Prozesse gesendet und verteilt werden. Weitere Informationen finden Sie unter AE-REST-API - Allgemeine Informationen

Wichtig!

  • Wenn ein System mit mehreren REST-Prozessen eingerichtet wird, ist es zwingend erforderlich, dass jedes System eine eigene Automation Engine-Konfigurationsdatei (ucsrv.ini, siehe Automation Engineverwendet, und dass verschiedene Ports für jeden REST zugewiesen werden. Andernfalls stellt der erste erfolgreich eine Verbindung her, während die anderen beendet werden, wenn sie versuchen, sich beim gleichen REST-Port zu registrieren, wenn beide auf demselben Knoten ausgeführt werden. In die Logdatei des REST-Prozesses wird eine Fehlermeldung mit Angabe der Ursache für den Abbruch geschrieben.

  • Wenn bei der Anmeldung kein REST-Prozess verfügbar ist, schlägt die Anmeldung fehl und es wird eine Fehlermeldung angezeigt. Das System benachrichtigt Sie auch, wenn aus einem bestimmten Grund die Mindestzahl von Prozessen während einer Sitzung nicht erfüllt wird. Die Benachrichtigung wird nicht mehr angezeigt, sobald der Prozess wieder ausgeführt wird.

Java-Kommunikationsprozess

Wie jeder andere Kommunikationsprozess (CP) wird auch der Java-Kommunikationsprozess (JCP) von Arbeitsprozessen (WPs) kontaktiert. Die dem Java-Kommunikationsprozess (JCP) zugewiesenen Ports werden im Parameter JCP.PORTS= im Abschnitt [PORTS] der INI-Datei der Automation Engine definiert (siehe Automation Engine) und können genauso definiert werden wie jeder andere Kommunikationsprozess:

  • als einzelne Ports, durch Semikolon getrennt

    [PORTS]

    JCP.PORTS=2317;2319

  • als Port-Bereich

    [PORTS]

    JCP.PORTS=2320-2337

  • als Kombination aus einzelnen Ports und einem Port-Bereich

    [PORTS]

    JCP.PORTS=2317;2319;2320-2337

Die Installation des Java Communication Process (JCP) ist auch für die TLS/SSL-Verbindung zu den UNIX-, Windows- und Java-basierten Agenten, der Automic Web Interface und der Java-API relevant. Diese Verbindung wird über sichere WebSockets (WSS) hergestellt.

Der für diese Verbindungen zugewiesene Port oder Port-Bereich wird im Parameter WS.PORT= im Abschnitt [PORTS] der INI-Datei der Automation Engine definiert (siehe Automation Engine). Wenn Sie einen JCP pro Host installiert haben, können Sie in jeder Instanz dieselbe WSS-Port-Definition verwenden.

Hinweise:

  • Für die Prozesse ist ein Schlüsselspeicher (im Format PKCS12) erforderlich, damit sie mit den entsprechenden Zertifikaten arbeiten. Stellen Sie sicher, dass Sie zuvor einen Schlüsselspeicher erstellt haben. Weitere Informationen finden Sie unter Verbindungen zur AE sichern (TLS/SSL).

    Sie müssen auch die folgenden Parameter im Abschnitt [TLS] der INI-Datei der Automation Engine (ucsrv.ini) definieren:

    • keystore= Pfad und Datei, in der der Keystore für das TLS/SSL-Zertifikat gespeichert ist

      Standardwert: ./httpsKeyfile

      Dieser Parameter ist obligatorisch und muss auf das richtige Ziel zeigen; andernfalls wird der Prozess-Server beendet.

    • keystorePassword= Kennwort für die Keystore-Datei

      Standardwert: changeit

      Wenn der Wert nicht definiert ist oder leer bleibt, verwendet das System den Standardwert.

    • keyPassword=Kennwort für den Schlüssel

      Standardwert: changeit

      Wenn der Wert nicht definiert ist oder leer bleibt, verwendet das System den Standardwert.

    • keyAlias= Alias, der für den Schlüssel verwendet wird

      Standardwert: jetty

      Wenn der Wert nicht definiert ist oder leer bleibt, verwendet das System den Standardwert.

    Das keystorePassword und das keyPassword können mit dem Dienstprogramm UCYBCRYP verschleiert werden. Weitere Informationen finden Sie unter Verschleiern von Kennwörtern.

  • Wenn der JCP initiiert wird, ist er an zwei Ports gebunden:

    • Den WS.PORT, der in der INI-Datei konfigurierbar ist und von den Agenten für die Kommunikation mit dem JCP verwendet wird.

    • Den Port, den Sie im Parameter JCP.PORTS im Abschnitt [PORTS] der INI-Datei der AE definiert haben. Wenn in diesem Abschnitt keine Ports definiert sind, wird der JPC willkürlich an einen anderen Port gebunden, was für die interne Kommunikation zwischen WP und JCP/CP erforderlich ist. Wenn der JCP startet, öffnet er einen willkürlich ausgewählten Port und sendet ihn intern über die Datenbank an die WPs, damit WPs die JCPs/CPs erreichen können.

    • Weitere Informationen finden Sie unter Konfigurieren von Firewall und Ports.

Siehe auch: