Konfiguration des Automic Web Interface
Sie haben das Automic Web Interfacebereits installiert. Nun können Sie mit den Konfigurationsaktivitäten fortfahren. Viele von ihnen sind optional.
Diese Seite beinhaltet Folgendes:
Konfigurationsschritte
Optimierung der Serverkonfigurationsgrößen
Hinweise:
-
Der Servlet-Container/Anwendungsserver kann nur den Speicher verwenden, für den er konfiguriert ist. Daher müssen Sie die Heap-Größe entsprechend Ihrer Hardwarekonfiguration auswählen.
-
Verwenden Sie den G1 Garbage Collector, der die Pausen der Garbage Collection für große Heaps deutlich reduziert.
-
Die Anzahl der unten aufgeführten Benutzer sind "gleichzeitige Benutzer", d. h. gleichzeitig angemeldete Benutzer, die mehr oder weniger aktiv sind.
-
Die vorgeschlagenen Hardwarekonfigurationen beinhalten bereits einen gewissen Headroom und ergeben sehr gute Antwortzeiten für die unten angegebene Anzahl von Benutzern.
-
Verwenden Sie nach Möglichkeit eine schnelle Netzwerkverbindung (10Gbit/s Ethernet) für die Verbindung zur Automation Engine.
-
In der Regel wird nicht einmal ein Hundertstel davon unter sehr hoher Last genutzt, aber eine schnelle Verbindung hilft bei der Verzögerung und hält die Datenübertragung kurz, was wiederum den CP-Verbrauch reduziert.
Serverkonfigurationsgrößen
-
Konfiguration für kleine Einzelserver: Eine kleine VM führt bis zu 50 gleichzeitige Sessions aus:
CPU: 4 virtuelle Kerne
Arbeitsspeicher: 16 GB
-
Grundlegende Konfiguration für Einzelserver: Eine VM mit mittlerer Größe kann bis zu 200 gleichzeitige Sessions ausführen:
CPU: 8 virtuelle Kerne
Arbeitsspeicher: 32GB
-
Schnelle Konfiguration für Einzelserver: Eine VM mit mittlerer Größe kann bis zu 500 gleichzeitige Sessions ausführen:
CPU: 16 virtuelle Kerne
Arbeitsspeicher: 64GB
den Zugriffs auf das AWI via SSL sichern
Tomcat
-
Erstellen einer KeyStore-Datei für Ihre Tomcat-Installation.
-
Öffnen Sie eine Eingabeaufforderung mit Administratorrechten und ändern Sie den Pfad zum Tomcat-Konfigurationsverzeichnis (TOMCAT_HOME/conf/).
-
Erstellen Sie mit dem folgenden Befehl eine KeyStore-Datei mit einem selbstsignierten Zertifikat. Dies führt zur Ausgabe wie unten gezeigt (Status nach vollständiger Bearbeitung).
Der Cursor springt in die erste Zeile, in der Sie Ihre Werte eingeben können. Bestätigen Sie nach jeder Eingabe mit der Return-Taste, um zur nächsten Zeile zu springen.
"%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA -keystore tomcat-keystore.jks -storepass myTomcatKeystorePassword
Wie lauen Ihr Vor- und Nachname?
[Unknown]: localhost
Wie lautet der Name Ihrer Unternehmenseinheit?
[Unknown]: YOUR_UNIT
Wie lautet der Name Ihres Unternehmens?
[Unknown]: YOUR_ORGANIZATION
Wie lautet der Name Ihrer Stadt oder ihres Gebiets?
[Unknown]: YOUR_CITY
Wie lautet der Name Ihres Bundeslands oder Kantons?
[Unknown]: YOUR_STATE
Was ist der aus zwei Buchstaben bestehende Ländercode für diese Einheit?
[Unknown]: AT
Ist CN=localhost, OU=YOUR_UNIT, O=YOUR_ORGANIZATION, L=YOUR_CITY, ST=YOUR_STATE, C=AT korrekt?
[no]: YES
Geben Sie das Schlüsselkennwort für <tomcat> ein
(EINGABETASTE, wenn dies dasselbe wie das Keystore-Kennwort ist):Hinweise:
-
Verwenden Sie den Hostnamen/die Domäne Ihrer AWI-Instanz als Vor- und Nachnamen (in diesem Beispiel
localhost
). -
Dieser Befehl erstellt eine neue KeyStore-Datei mit dem Namen
tomcat-keystore.jks
, geschützt mit dem PasswortmyTomcatKeystorePassword
, im Konfigurationsverzeichnis. Der KeyStore enthält ein selbstsigniertes Zertifikat für Ihre AWI-Instanz.
-
-
-
Importieren Sie ein signiertes Zertifikat in den KeyStore (optional).
Überspringen Sie diesen Schritt, wenn Sie das im vorherigen Schritt erstellte selbstsignierte Zertifikat verwenden.
-
Verwenden Sie den folgenden Befehl, um zuerst ein Chain- oder Root-Zertifikat (falls vorhanden) in Ihren KeyStore zu importieren:
"%JAVA_HOME%\bin\keytool" -import -alias root -keystore tomcat-keystore.jks -trustcacerts -file <Dateiname_des_Kettenzertifikats>
-
Importieren Sie nun das Zertifikat mit diesem Befehl:
"%JAVA_HOME%\bin\keytool" -import -alias tomcat -keystore tomcat-keystore.jks -file <Ihr_Zertifikat-Dateiname>
-
Um ein vorhandenes, von Ihrer eigenen Zertifizierungsstelle (Certification Authority, CA) signiertes Zertifikat in einen
PKCS12
-KeyStore mit OpenSSL zu importieren, führen Sie einen Befehl wie diesen aus:openssl pkcs12 -export -in mycert.crt -inkey mykey.key
-out mycert.p12 -name tomcat -CAfile myCA.crt
-caname root -chain
Wichtig! Die Tomcat unterstützt nur Schlüssel und Zertifikate in den Formaten
JKS
,PKCS11
oderPKCS12
. -
-
Konfigurieren der Tomcat-Verbindung
-
Öffnen Sie die
server.xml
-Datei im Konfigurationsverzeichnis Ihrer Tomcat-Instanz. -
Fügen Sie die folgende Connector-Konfiguration in Ihrer Konfigurationsdatei hinzu und speichern Sie sie:
<Connector port="8443"
protocol="Enter the current apache protocol here"
keyAlias="tomcat" keystoreFile="conf\tomcat-keystore.jks" keystorePass="myTomcatKeystorePassword"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" /> -
Starten Sie Ihre Tomcat-Instanz neu, um die Änderungen zu übernehmen.
Geben Sie für den Parameter
keystorePass
das Passwort destomcat-keystore.jks
ein.Wichtig! Das vorherige Beispiel veranschaulicht, wie der Connector so konfiguriert wird, wie zum Zeitpunkt dieser Beschreibung vorgesehen. Prüfen Sie die Tomcat-Dokumentation auf potenzielle Änderungen und auf die neuesten Informationen bei Apache Tomcat.
-
-
Testen Sie den Zugriff auf Ihre AWI-Instanz.
Sie können nun über eine sichere Verbindung auf das Automic Web Interface zugreifen.
-
Als URL verwenden Sie
https://IHRE_DOMAIN:8443/awi/
(Beispiel:https://localhost:8443/awi/
) -
Wenn Sie ein selbstsigniertes Zertifikat verwenden, erhalten Sie möglicherweise eine Warnung, dass die Verbindung nicht vertrauenswürdig ist, da es nicht möglich ist, die Identität zu überprüfen.
Sie können diese Warnung nur vermeiden, wenn Sie signierte Zertifikate von einer vertrauenswürdigen Zertifizierungsstelle verwenden. Die Verschlüsselung der Verbindung ist dieselbe wie bei einem selbstsignierten Zertifikat.
Hinweis: Sie müssen bestätigen (eine Sicherheitsausnahme hinzufügen), dass Sie das selbstsignierte Zertifikat verwenden möchten.
-
WebSphere
Das Verfahren zur Sicherung des Zugriffs auf das AWI hängt von dem in Ihrem Unternehmen verwendeten WebSphere-Profil ab. Weitere Informationen entnehmen Sie bitte der offiziellen IBM WebSphere-Dokumentation.
Anpassen des Konfigurationspfades
Standardmäßig befinden sich die AWI-Konfigurationsdateien im Ordner Webanwendungen auf dem WebServer. In einigen Fällen kann es sinnvoll sein, diesen Pfad zu ändern, z. B. wenn die Benutzer, die das AWI konfigurieren, keine Zugriffsrechte auf den Ordner WebServer haben sollen.
Unabhängig davon, ob Sie die Installation über das ONE Installer oder manuell durchführen, können Sie den Pfad, in dem die Konfigurationsdateien gespeichert werden sollen, anpassen. Zu diesem Zweck setzen Sie die folgenden JVM-Argumente, indem Sie sie entweder in der Java-Umgebung angeben oder die Management-Dienstprogramme Ihres WebServers verwenden:
-
-Dcom.uc4.ecc.config.dir= Zum Ändern des Pfades bei manueller Installation.
Beispiel:
In einer Tomcat-Installation ist der Standardpfad der Konfigurationsdateien <Webserver>/webapps/awi/config.
Angenommen, Sie möchten die Konfigurationsdateien im Ordner C:\AWI_config\config speichern. In einer Installation mit Tomcat müssen Sie das folgende Attribut zum Umgebungsparameter CATALINA_OPTS hinzufügen
CATALINA_OPTS="-Dcom.uc4.ecc.config.dir=C:\AWI_config\config\"
. -
-Dcom.uc4.ecc.autoinstall.dir= Zum Ändern des Pfades bei Verwendung des ONE Installer.
Beispiel:
In einer Tomcat-Installation ist der Standardpfad der Konfigurationsdateien <Webserver>/webapps/awi/WEB-INF/autoinstall.
Angenommen, Sie möchten die Konfigurationsdateien im Ordner C:\AWI_config\plugins speichern. In einer Installation mit Tomcat müssen Sie das folgende Attribut zum Umgebungsparameter CATALINA_OPTS hinzufügen
CATALINA_OPTS="-Dcom.uc4.ecc.autoinstall.dir=C:\AWI_config\plugins"
.
Hinweis: Nachdem Sie dieses Argument gesetzt haben, müssen Sie den Anwendungsserver neu starten.
Login- und Benutzerauthentifizierung konfigurieren
Das Automic Web Interface bietet verschiedene Konfigurationen der Benutzerauthentifizierung, die zu unterschiedlichen Login-Optionen führen. Als Systemadministrator können Sie das AWI so konfigurieren, dass es den gewünschten Authentifizierungs- und Login-Ansatz unterstützt.
Wenn sich Benutzer am AWI anmelden, wird standardmäßig der gesamte Authentifizierungsprozess von der Automation Engine abgewickelt, mit der die Instanz verbunden ist. Die AE bestätigt, ob die Benutzeranmeldeinformationen mit den Werten im zugehörigen Benutzerobjekt (USER) übereinstimmen.
Sie können auch ein Single Sign-on mit dem Kerberos- oder SAML-Protokoll aktivieren oder die parametrisierte Anmeldung aktivieren.
Das standardmäßige AWI-Login verwenden
Standardmäßig müssen die AWI-Benutzer beim Öffnen des AWI die folgenden Login-Informationen angeben:
- Sprache
English (Standard), Deutsch, Français
- Verbindung
Je nachdem, wie der Parameter automationEngine.index in configuration.properties definiert ist, werden entweder eine oder alle definierten Verbindungen zur Backend-Automation Engine aufgelistet. Weitere Informationen finden Sie unter configuration.properties.
- Mandant
Nummer des Benutzer-Mandanten.
- Name
Benutzername in der Benutzerdefinition.
- Abteilung (optional)
Die Abteilung des Benutzers in der Benutzerdefinition.
- Passwort
Wenn in der Benutzerdefinition die Option LDAP ausgewählt ist, handelt es sich um das Domänenpasswort des Benutzers, das beim Anmelden am Computer beim Start verwendet wird. Ohne LDAP ist dies das Passwort, das in der Benutzerdefinition eingetragen ist.
- Session-Farbe (optional)
Eine Akzentfarbe für den Fortschrittsbalken am oberen Rand der AWI-Browserseite sowie für markierte Bereiche. Wenn Benutzer mehr als eine Session öffnen, kann man durch unterschiedliche Session-Farben schneller erkennen, in welcher Session man sich gerade befindet.
Im Browser bleiben (außer dem Passwort) alle Anmeldedaten für Ihre nächste Anmeldung gespeichert.
Hinweis: Sie können die Session-Farbe jederzeit im Session-Menü in der Hauptmenüleiste ändern.
Single Sign-On verwenden
Wenn Sie Single Sign-On für das Automation Engine-System einrichten, müssen Benutzer sich nur einmal anmelden und müssen die Anmeldeinformationen nicht immer wieder erneut eingeben. Die Automation Engine unterstützt die Protokolle Kerberos Key Distribution Center (KDC) und die Security Assertion Markup Language 2.0 (SAML 2.0).
Sie aktivieren das Single Sign-On (SSO) in den configuration.properties Ihrer Automic Web Interface-Instanz, indem Sie die Eigenschaft sso.kdc.enabled oder sso.saml.enabled auf true setzen, abhängig davon, welches Protokoll Sie verwenden möchten. Weitere Informationen finden Sie unter configuration.properties.
Sie können auch festlegen, ob Sie die automatische Anmeldung für die Verwendung einer vollständigen oder teilweise automatischen Anmeldung aktivieren möchten:
-
Das Aktivieren der automatischen Anmeldung führt zu einer vollautomatischen Anmeldung und ermöglicht es Ihnen, die Eingabe von Anmeldeinformationen in der Zukunft zu umgehen. Stellen Sie sicher, dass Sie Ihre Session-Optionen (Sprache, Verbindung, Mandant, Session-Farbe) auswählen, bevor Sie sie aktivieren.
-
Das Deaktivieren der automatischen Anmeldung führt zu einer teilweise automatischen Anmeldung und ermöglicht es Ihnen, ihre Session-Optionen (Sprache, Verbindung, Mandant, Session-Farbe) zu ändern, ohne Ihre Benutzerinformationen oder Ihr Passwort eingeben zu müssen.
Weitere Informationen zur SSO-, Kerberos-und SAML-Konfiguration finden Sie unter Einrichten von Single Sign-On.
Parametrisiertes Login am AWI aktivieren
Eine weitere praktische Funktion ist die Aktivierung des parametrisierten Logins durch das Einfügen der Login-Parameter in die URL, die Sie zum Starten des AWI verwenden. Dies ist hilfreich, wenn Sie oder Benutzer mehrere Verbindungen und/oder Mandanten verwenden. Sie können die verschiedenen Login-Kombinationen einfach mit einem Lesezeichen versehen. Wenn Sie die mit einem Lesezeichen versehene URL öffnen, müssen Sie nur Ihr Passwort eingeben.
-
Setzen Sie in Ihrer AWI-Instanz die Eigenschaft parameter_login.enabled auf true in der Datei configuration.properties, siehe configuration.properties.
-
Fügen Sie in Ihrer AWI-Start-URL die Login-Informationen hinzu, die Sie bereits im Anmeldefenster eingegeben haben möchten.
Beispiel
https://<AWI >/?system=ConnectionName&client=9999&name=MyUserName&department=Dept&logintype=AE(default)|KERBEROS|SAML&language=MyLanguage&autologin=true
Hinweis: Wenn Ihr Browser nicht über ein SSL-Protokoll auf das AWI zugreift, beginnt Ihre URL mit http://.
Als Administrator möchten Sie möglicherweise individualisierte URLs an Ihre neuen Benutzer senden.
Informationen über die Art der Logdaten, die für ein CA Automic-Support-Ticket gesammelt werden müssen, finden Sie unter Vorbereiten von Logdateien für die Fehlerberichterstattung.
Wenn Fehler auftreten, können Ihnen die Logging-Informationen bei der Suche nach der Fehlerquelle helfen. Das Logging ist standardmäßig aktiviert. Sie können die Standard-Log-Ebene ändern, wenn Sie möchten, dass mehr oder weniger Ereignisse in die Logdatei geschrieben werden.
Das Logging am AWI wird vom Tomcat Logback Framework übernommen. Sie können die Log-Ebene in der logback.xml
-Datei definieren. Die angegebene Log-Ebene definiert den niedrigsten Schweregrad. Sein Auftreten und das Auftreten von Ereignissen höherer Schweregrade werden protokolliert. Ein umfangreiches Logging kann sich jedoch auf die Leistung des AWI auswirken. Wenn Probleme bei der Leistung auftreten, überprüfen Sie Ihre Log-Ebene und reduzieren Sie die geschriebenen Meldungen, indem Sie bei Bedarf eine höhere Log-Ebene angeben.
Das Logging umfasst die folgenden Dateien:
- Konfigurationsdatei
logback.xml
im Ordner...\<AWI>\config
Ihres Anwendungsservers. - Logdateien im Ordner
logs
Ihres Anwendungsservers.
Die verfügbaren Werte der Log-Ebenen (von oben nach unten) sind:
-
ERROR
Zweck: Fehlgeschlagene Aktion einer AWI-Komponente, von der sich das AWI nicht erholen konnte, wie z. B.
nullPointExceptions
oderclosedStreamExceptions
.Tracing-Daten in der Meldung: keine den Benutzer identifizierenden Daten. Hostnamen, andere standortspezifische Daten, Klassennamen, Objektnamen und dergleichen sind jedoch in den ereignisbezogenen Angaben enthalten. Die Nachricht enthält den vollständigen Stack-Trace.
-
WARNING
Zweck: Unerwartetes Verhalten einer AWI-Komponente, wie z. B. instabile Netzwerkverbindungen, die eine automatische Wiederherstellung der Verbindung des AWI, einen Wiederholungsversuch nach einem Timeout oder das Auslösen eines Workarounds für einen Bug eines Drittanbieters erfordern.
Tracing-Daten in Meldung: Wie ERROR-Ebene
-
INFO
Zweck: Konfigurationswerte beim Anmelden oder Hochfahren von Komponenten oder globale Konfigurationsänderungen.
Tracing-Daten in der Meldung: wie ERROR-Ebene, jedoch ohne vollständigen Stack-Trace.
-
DEBUG
Zweck: Benutzerspezifische Aktionen auf hoher Ebene, wie z. B. An- und Abmeldeereignisse, Benutzeränderungen (z. B. Objektbearbeitung), autorisierungsbezogene Ereignisse (z. B. erfolgreiche und fehlgeschlagene Setup-Aktionen) und wichtige Leistungskennzahlen
Tracing-Daten in der Meldung: Benutzerinformationen (z. B. Benutzer-ID und HTTP-Session-ID) und ereignisbezogene Angaben.
-
TRACE
Zweck: Benutzerspezifische Aktionen auf niedriger Ebene wie Navigation, Objekt öffnen, Tastenklicks, die Nutzlast von Backend-Aufrufen, interne Anwendungsereignisse und alle Aufrufe des Backends.
Tracing-Daten in der Meldung: wie DEBUG.
Log-Ebene wechseln
Das Logging ist standardmäßig auf DEBUG eingestellt, aber bei Bedarf können Sie die Log-Ebene in der Konfigurationsdatei logback.xml
ändern, die Sie im Ordner ...\<AWI>\config
Ihres Anwendungsservers finden.
Wichtig! Ändern Sie keine weiteren Parameter in dieser Datei. Das Ändern anderer Parameter kann verhindern, dass CA Automic Situationen untersucht, die Fehler verursachen.
Die Log-Ebene ist im <root>
-Element durch das Element level="[log_level]">
definiert. Das <root>-Element enthält das Element <appender-ref>
, das spezifiziert, dass dieses <root>
-Element den LOGGER-Appender definiert. Der LOGGER-Appender ist die Komponente, die die Logging-Ereignisse in die Logdatei schreibt.
Log-Ebene wechseln
- Wechseln Sie zum Ordner
webapps\<AWI>\config
und öffnen Sie die Dateilogback.xml
. - Suchen Sie nach dem
<root>
-Element.Hinweis: Sie können das
<root>
-Element am leichtesten finden, indem Sie nachref="LOGGER"
suchen. Das<root>
Element steht eine Zeile darüber. - Ändern Sie die Log-Ebene für den Root-Appender, indem Sie das Attribut
level="[log_level]"
auf die unterste Log-Ebene setzen, für die Meldungen in die Logdatei geschrieben werden sollen. Weitere Informationen finden Sie unter Log-Ebenen. - Damit die Änderungen wirksam werden, müssen Sie den Anwendungsserver stoppen und neu starten.
Beispiel
Im folgenden Beispiel wird die Log-Ebene auf "DEBUG" (Standardwert) gesetzt. Wenn Sie sie auf "INFO" ändern, werden weniger Meldungen in die Datei geschrieben, da unkritische Logmeldungen ignoriert werden.
<!-- Hier wird die Log-Ebene festgelegt. Mögliche Werte: TRACE, DEBUG, INFO, WARN, ERROR
DEBUG wird für Test- und Entwicklungsinstanzen empfohlen.
INFO wird für Produktionsinstanzen empfohlen.
-->
<root level="DEBUG">
<appender-ref ref="LOGGER" />
</root>
AWI-Logdateien
Die Logdateien befinden sich im Ordner logs
Ihres Anwendungsservers und heißen <host name>_ECC_Log.##.TXT:
<Hostname>
ist der Name des Computers, auf dem der Anwendungsserver läuft.###
ist eine aufsteigende Zahl, wobei 00 die aktuelle Logdatei ist.
Die aktuelle Logdatei ist eine .txt
-Datei, ältere Logdateien werden in .zip
-Archive komprimiert.
Hinweis: Als Administrator können Sie auch das Schreiben von Trace-Dateien (ähnlich benannt wie die Logdateien (<Host name>_ECC_TRACE.##
)) in diesen Ordner aktivieren, um die Ursache eines Fehlers zu finden.
Anpassen der Benutzeroberfläche
Standardmäßig hat die AWI-Oberfläche das CA Automic-Logo im Anmeldedialog und in der Kopfzeile. Alle Seiten verwenden die Standardfarbe Gold sowie Schwarz- und Grautöne. Sie können die Farbe und das Logo anpassen, um die Marke Ihres Unternehmens widerzuspiegeln.
Ändern des Logos
-
Bereiten Sie Ihre Logo-Datei vor. Achten Sie darauf, dass die Bildgröße nicht größer ist als:
-
Breite: 96 px
-
Höhe: 70 px
-
-
Kopieren Sie logo.png in den Ordner …\<AWI>\config\theme.
-
Fügen Sie den Konfigurationsparameter logo.filename = logo.png zur Datei "color.properties" hinzu, um das neue Logo anzugeben.
-
Je nachdem, wie Ihr Logo aussieht, können Sie eine weiße Box hinzufügen, um es vom dunklen Hintergrund zu unterscheiden. Fügen Sie dazu den Parameter white.background = true in die Datei "color.properties" ein.
Hinweis: Wenn Sie die Änderungen bei der nächsten Anmeldung am AWI nicht sehen, starten Sie den Tomcat-Webserver neu.
Ändern des Farbschemas
-
Öffnen Sie die Datei colors.properties, die sich im Ordner …\webapps\<AWI>\config\theme befindet. Weitere Informationen finden Sie unter colors.properties.
-
Geben Sie im Hauptfarbenparameter den RGB-Farbcode an. Stellen Sie sicher, dass davor ein Rautezeichen (#) und danach ein Semikolon (;) steht.
Geben Sie beispielsweise "maincolor = #fac800;" für das Standardgold ein.
Hinweis: Wenn Sie die Änderungen bei der nächsten Anmeldung am AWI nicht sehen, starten Sie den Tomcat-Webserver neu.
Anpassen der Konfigurationsdateien
Es gibt eine Reihe von obligatorischen und optionalen Konfigurationsdateien, die Sie anpassen müssen.
Wichtig! Die Konfigurationsdateien, die hier nicht angeführt werden, sollten nicht verändert werden.
-
uc4config.xml: Obligatorisch.
Zur Definition der Verbindung zwischen der AWI-Installation und den AE-Systemen, die als Backend verwendet werden können.
-
logback.xml: Optional. Standardeinstellungen sind vorhanden.
Steuert das Logging-Verhalten. Sie können den niedrigsten Schweregrad der Nachrichten, die Sie nachverfolgen lassen möchten, anpassen. Der gelieferte Wert ist "NFO".
-
configuration.properties: Obligatorisch.
Zur Definition von Aspekten der Kommunikation zwischen dem AWI und der AE, z. B. der Sicherheitsoptionen und Timeout-Intervalle.
-
colors.properties: Optional.
Zur Definition einer benutzerdefinierten Themenfarbe für die AWI-Benutzeroberfläche.
Nach der Installation und Konfiguration des AWI können Sie mit der Einrichtung Ihres Systems beginnen oder mit der Installation anderer Plug-ins und Komponenten fortfahren.
Weitere Informationen finden Sie unter Voraussetzungen und Installationstypen.
Den Load Balancer einrichten und Proxys konfigurieren
Sie können das Automic Web Interface über jede Art von Proxy im allgemeinen Sinne nutzen, sei es für TLS-Terminierung, Lastausgleich, Redundanz oder all dies gleichzeitig.
Ein einzelner, leistungsstarker Server kann den in AWI erwarteten Verkehr in einer Automation Engine-Hochleistungsinstallation verarbeiten. Aus diesem Grund müssen Sie keine Load Balancer einrichten, um die Leistung des Automic Web Interface zu verbessern.
Wenn Sie jedoch Hochverfügbarkeit wünschen, müssen verschiedene AWI-Instanzen auf unterschiedlichen Hosts ausgeführt werden.
In diesem Fall benötigen Sie einen Load Balancer, um den Datenverkehr umzuleiten, falls eine der AWI-Instanzen fehlschlägt.
Tipp: Es wird empfohlen, eine Hot/Hot-Konfiguration mit zwei Instanzen zu verwenden, die beide den Datenverkehr gemeinsam bedienen. Eine Umschaltung sollte nur erfolgen, wenn der eine Server ausfällt. Außerdem muss jede Instanz in der Lage sein, den gesamten Datenverkehr zu verarbeiten. Wenn die andere Instanz fehlschlägt, würde diejenige, die ihre Aufgaben übernimmt, überlastet. Wenn ein einzelner Server aus irgendeinem Grund den Ladevorgang nicht verarbeiten kann, können Sie weitere Instanzen hinzufügen, um Fehler zu beheben. Zum Beispiel vier oder fünf Instanzen statt der erforderlichen drei.
Anforderungen an Load Balancer
-
Um mit dem AWI zu arbeiten, muss Ihr Load Balancer "Sticky Sessions" unterstützen. Wie viele Java-Webanwendungen verwendet das AWI das Session-Cookie JSESSIONID. Sie können Ihren Load Balancer so konfigurieren, dass er dieses Cookie verwendet oder ein eigenes hinzufügt, um Eingabeaufforderungen derselben Session an denselben Server weiterzuleiten.
-
Wenn Sie das AWI mit aktivierten WebSockets betreiben, muss Ihr Load Balancer diese unterstützen.
-
Bitte verwenden Sie den gleichen Pfad auf Ihrem Load Balancer und den Servlet-Containern.
Beispiel
Wenn sich Ihre Server auf
http://backend1/awi
undhttp://backend2/awi
befinden, und Ihr Host Balancer auf dem Hostpublicawihost
, konfigurieren Sie Ihren Load Balancer so, dass er AWI aufhttp(s)://publicawihost/awi
unterstützt.
Statusprüfung
Wenn Ihr Load Balancer Statusprüfungen über zusätzliche http-Eingabeaufforderungen durchführt, stellen Sie sicher, dass der entsprechende Pfad verwendet wird. Wenn Ihr AWI beispielsweise über https://myawiserver/awi
erreichbar ist, sollte die Statusprüfung https://myawiserver/awi/check
aufrufen.
Diese URL gibt eine Antwort mit dem Statuscode 200 zurück, wenn das AWI
Upgrades
Ein Load Balancer oder Proxy kann sehr nützlich sein, um beim Abschluss eines Zero Downtime Upgrade transparent zwischen zwei Versionen des AWI zu wechseln. Weitere Informationen finden Sie unter Zero Downtime Upgrade.
WebSockets
Bei Tomcat verwendet das AWI WebSockets als effiziente Möglichkeit, um Informationen an den Mandanten zu senden. Wenn Sie Weblogic oder Websphere verwenden, greift das AWI auf langes Polling zurück.
Hinweise:
- Setzen Sie den Parameter
allowWebsockets=false
in der Datei configuration.properties des AWI. Weitere Informationen finden Sie unter Netzwerkeinstellungen - Das Ausführen des AWI ohne WebSocket erhöht jedoch leicht die CPU-Last auf dem Servlet-Container, also stellen Sie sicher, dass Sie weitere Ressourcen hinzufügen, um dies zu kompensieren.
Tipps:
- Erhöhen Sie nicht die System- oder Mandanten-Einstellungen, die sich auf die Anzeige der Datenmenge für den Benutzer auswirken, es sei denn, dies ist absolut notwendig.
- Legen Sie nicht zu viele Objekte in den Root-Ordner. Abgesehen davon, dass es für einen menschlichen Benutzer unüberschaubar wird, sich darin zu bewegen, wirkt sich dies auch auf die Leistung aus: Der Root-Ordner wird standardmäßig in der Process Assemblyangezeigt, und eine lange Liste von Objekten (Tausende) erhöht den Speicher pro Session und den CPU-Verbrauch beim Abruf der Ordnerliste erheblich.
Engpässe lokalisieren
AWI zeigt Ladeindikatoren an, während auf Antworten auf Backend-Eingabeaufforderungen gewartet wird. Mögliche Engpasssymptome sind:
-
Das Web Interface wird geschlossen:
Der AWI-Server ist wahrscheinlich der Engpass.
Sie können:
-
versuchen, den Speicher und den Java-Heap-Speicher zu vergrößern
-
versuchen, die Anzahl der CPU-Kerne zu erhöhen
-
-
Die Ladezeiten sind zu lang:
Die Automation Engine ist wahrscheinlich der Engpass.
Sie können die Anzahl der DWPs und JWPs erhöhen