Konfiguration des Automic Web Interface

Sie haben das Automic Web Interface installiert. Jetzt können Sie es konfigurieren. Viele Konfigurationsparameter sind optional.

Hinweis: Einige Konfigurationsdateien werden mit der zusätzlichen Erweiterung "sample" geliefert, um sicherzustellen, dass Ihre bestehenden Konfigurationsdateien nicht überschrieben werden, wenn Sie die AWI-Installation aktualisieren. Sie können ".sample" entfernen und die Parameter in diesen Dateien anpassen, oder Sie können die alten, bereits konfigurierten Dateien verwenden.

Konfigurationsschritte:

Optimierung der Serverkonfigurationsgrößen

Dies ist unsere Empfehlung für die Optimierung Ihrer Serverkonfiguration.

Hinweise:

Der Servlet-Container/Anwendungsserver kann nur den Arbeitsspeicher nutzen, für den er konfiguriert ist. Wählen Sie die Heapgröße entsprechend Ihrer Hardwarekonfiguration aus.
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 empfohlenen 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 Latenz und hält die Datenübertragung kurz, was wiederum den CP-Verbrauch reduziert.

Empfohlene Serverkonfigurationsgrößen

Kleine Single-Server-Konfiguration

Eine kleine VM kann bis zu 50 Sessions gleichzeitig ausführen:
- CPU: 4 virtuelle Kerne
- Arbeitsspeicher: 16 GB
Basis-Single-Server-Konfiguration

Eine mittelgroße VM kann bis zu 200 Sessions gleichzeitig ausführen:
- CPU: 8 virtuelle Kerne
- Arbeitsspeicher: 32GB
Schnelle Single-Server-Konfiguration

Eine mittelgroße VM kann bis zu 500 Sessions gleichzeitig ausführen:
- CPU: 16 virtuelle Kerne
- Arbeitsspeicher: 64GB

Sicherung des Zugriffs auf AWI über TLS/SSL

In diesem Abschnitt wird erklärt, wie eine sichere Kommunikation zwischen AWI und dem Anwendungsserver konfiguriert wird.

Wichtig! Obwohl das Aktivieren von TLS/SSL für die Kommunikation zwischen AWI und einem Anwendungsserver optional ist, empfehlen wir dies dringend.

Weitere Informationen zur Sicherung der Kommunikation zwischen AWI und der Automation Engine finden Sie unter uc4config.xml - Konfigurieren der Verbindung zwischen AWI und AE.

Wichtig! AWI unterstützt einen KeyStore nur im Format PKCS12 (.p12).

Aktivieren von TLS/SSL für Installationen mit dem Bundled Jetty Launcher

Befolgen Sie diese Anweisungen:

Erstellen Sie ein neues Zertifikat für den Jetty-Anwendungsserver und fügen Sie es dem Schlüsselspeicher hinzu.

Informationen dazu finden Sie in den Themen zum Konfigurieren von TLS/SSL in der offiziellen EclipseJetty-Dokumentation.
Fügen Sie der Datei configuration.properties die folgenden Parameter hinzu:

https.enabled=true

https.port=7443

https.keystore.filename=keystore.selfsigned

https.keystore.password=secret

https.manager.password=secret

https.cert.alias = certificate_alias
Starten Sie den Jetty-Anwendungsserver neu, damit die Änderungen wirksam werden.

Wichtig!

Um zu garantieren, dass AWI im sicheren Modus ausgeführt wird, müssen Sie HTTPS undHTTP deaktivieren. Das bedeutet, dass Sie die AWI-Eigenschaften wie folgt konfigurieren müssen:

http.enabled=false

https.enabled=true

Aktivieren von TLS/SSL für Installationen mit Tomcat

Befolgen Sie diese Anweisungen:

Erstellen einer KeyStore-Datei für Ihre Tomcat-Installation.
1. Öffnen Sie eine Eingabeaufforderung mit Administratorrechten und ändern Sie den Pfad zum Tomcat-Konfigurationsverzeichnis (TOMCAT_HOME/conf/).
2. 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 Passwort myTomcatKeystorePassword, 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.
1. 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>
2. Importieren Sie nun das Zertifikat mit diesem Befehl:
  
  "%JAVA_HOME%\bin\keytool" -import -alias tomcat -keystore tomcat-keystore.jks -file <Ihr_Zertifikat-Dateiname>
3. 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
Konfigurieren der Tomcat-Verbindung
1. Öffnen Sie die server.xml-Datei im Konfigurationsverzeichnis Ihrer Tomcat-Instanz.
2. 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" />
3. Starten Sie Ihre Tomcat-Instanz neu, um die Änderungen zu übernehmen.
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. In diesem Fall müssen Sie ausdrücklich bestätigen, dass Sie sie verwenden möchten, indem Sie eine Sicherheitsausnahme hinzufügen.
  
  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.

Schützen des Zugriffs auf AWI für Installationen mit 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.

Anpassen des Konfigurationspfads in Installationen mit dem Jetty-Launcher

Der Jetty-Launcher unterstützt mehrere AWI-Installationen in derselben Jetty-Instanz. Sie sollten dies zu Lastenausgleichszwecken oder für ein Back-up Ihrer AWI-Konfigurationen tun.

Angenommen, Sie haben zwei AWI-Instanzen, eine für Ihre TEST-Umgebung und eine für PROD. Sie konfigurieren die jeweiligen Pfade wie folgt:

In Ihrer TEST-Umgebung

java -Dcom.uc4.ecc.config.dir=C:\AWI\Config-TEST\ -jar C:\AWI\<version>\aa-webui-launcher.jar
In Ihrer PROD-Umgebung

java -Dcom.uc4.ecc.config.dir=C:\AWI\Config-PROD\ -jar C:\AWI\<version>\aa-webui-launcher.jar

Hinweise:

Stellen Sie sicher, dass alle relevanten Konfigurationsdateien (logback.xml, configuration.properties, uc4config.xml) im angegebenen Ordner vorhanden sind.
Um verschiedene Jetty-Instanzen parallel auszuführen, geben Sie verschiedene Ports für jede Instanz in configuration.properties an.
Geben Sie den Parameter -D vor dem Parameter -jar in der Kommandozeile an.

Nach dem Setzen dieses Arguments müssen Sie den Anwendungsserver neu starten.

Anpassen des Konfigurationspfads in Installationen mit Tomcat, WebSphere oder WebLogic

Setzen Sie die folgenden JVM-Argumente, indem Sie sie entweder in der Java-Umgebung angeben oder die Management-Dienstprogramme Ihres WebServers verwenden:

Für Installationen mit Tomcat
- -Dcom.uc4.ecc.config.dir=
  
  Pfad bei manueller Installation ändern
  
  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.
  
  Fügen Sie dem Umgebungsparameter CATALINA_OPTS das folgende Attribut hinzu:
  
  CATALINA_OPTS="-Dcom.uc4.ecc.config.dir=C:\AWI_config\config\".
- -Dcom.uc4.ecc.autoinstall.dir=
  
  Ändert den Pfad 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\config speichern.
  
  Fügen Sie dem Umgebungsparameter CATALINA_OPTS das folgende Attribut hinzu:
  
  CATALINA_OPTS="-Dcom.uc4.ecc.autoinstall.dir=C:\AWI_config\plugins"

Nach dem Setzen dieses Arguments 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. Folgende Optionen stehen zur Verfügung:

Standardmäßiges AWI-Login
Single Sign-On
- Kerberos
- SAML
Parametrisierte Anmeldung

Standardmäßiges AWI-Login

Dies ist die Standardeinstellung. Wenn sich Benutzer am AWI anmelden, wird 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.

Standardmäßig müssen die 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 – Lokales Setup konfigurieren.
Mandant

Nummer des Benutzer-Mandanten
Name

Benutzername in der Benutzerdefinition
Abteilung (optional)

Die Abteilung, wie im Benutzerobjekt definiert
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.

Single Sign-On

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 folgenden Protokolle:

Kerberos Key Distribution Center (KDC)
Security Assertion Markup Language 2.0 (SAML 2.0)

So aktivieren Sie Single Sign-On (SSO)

Setzen Sie die Eigenschaft sso.kdc.enabled oder sso.saml.enabled in der Datei configuration.properties auf true. Weitere Informationen finden Sie unter configuration.properties – Lokales Setup konfigurieren.

(Optional) So aktivieren Sie die automatische Anmeldung (vollständig oder teilweise automatisch)

Setzen Sie den Parameter autologin in parameter_login.enabled auf true.

Das Aktivieren dieser Option 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.

Parametrisierte Anmeldung

Verwenden Sie die parametrisierte Anmeldung, wenn Sie und Ihre Benutzer zu mehr als einer Automation Engine und/oder Mandanten eine Verbindung herstellen möchten. Mit der parametrisierten Anmeldung können Benutzer die verschiedenen Anmeldekombinationen mit einem Lesezeichen versehen. Wenn sie die Lesezeichen-URL öffnen, müssen sie nur ihre Passwörter eingeben.

So aktivieren Sie eine parametrisierte Anmeldung

Setzen Sie die Eigenschaft parameter_login.enabled auf true in der Datei configuration.properties, siehe configuration.properties – Lokales Setup konfigurieren.
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 TLS/SSL-Protokoll auf die AWI zugreift, beginnt Ihre URL mit http://.

Tipp: Als Administrator möchten Sie möglicherweise individualisierte URLs an Ihre neuen Benutzer senden.

Logging-Konfiguration

Wenn Fehler auftreten, werden die Logging-Informationen Ihnen helfen, den Grund zu finden. Die Protokollierung ist standardmäßig in der Konfigurationsdatei logback.xml aktiviert. Wenn mehr oder weniger Ereignisse in die Logdatei geschrieben werden sollen, können Sie die StandardLog-Ebene entweder in logback.xml oder über die Automic Web Interface ändern.

Informationen über die Logging- und Tracing-Optionen in AWI, und wie Log-Daten erfasst werden, um einen Fehler zu melden, finden Sie unter Vorbereiten von Log-Dateien für die Meldung von Fehlern.

Informationen zur Datei logback.xmls finden Sie unter logback.xml - Log-Ebenen konfigurieren.

Informationen zum Ändern der Log-Ebene auf der Benutzeroberfläche finden Sie unter AWI Verwaltung: Loging.

Weitere Informationen zum Konfigurieren der AWI Log-Datei in Automic Automation Kubernetes Edition finden Sie unter Container-basierte Systeme konfigurieren.

Speicherort der Logdatei

Sie finden die Datei logback.xml im Ordner ...\<AWI>\config Ihres Anwendungsservers.

Sie finden die AWI-Logdateien am folgenden Speicherort:

Installationen mit Tomcat, WebSphere und WebLogic

Im Log-Ordner Ihres Anwendungsordners
Installationen mit dem Bundled Jetty Launcher

AWI speichert die Logdateien im Ordner /osgi-tmp. Jede laufende Instanz erstellt einen Unterordner mit einer aufsteigenden Nummer, beginnend mit 0. Die Ordner enthalten sowohl die osgi-bezogenen Daten als auch die AWI-Logdateien.

Ausnahme: Wenn Sie das AWI über die Kommandozeile starten und dem Befehl den Parameter -console hinzufügen, wird das Protokoll stattdessen auf die Konsole geschrieben.

Weitere Informationen zum Starten des AWI über die Kommandozeile finden Sie unter

AWI-Logdateien

Die AWI Log-Dateien erhalten die Bezeichnung <Hostname>_ECC_Log.##.TXT, wobei gilt

<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.

Log-Ebenen

Die Log-Ebene definiert den niedrigsten Schweregrad und bestimmt den Typ und die Menge von Informationen, die in die Logdateien geschrieben werden.

Hinweis: Ein umfangreiches Logging kann sich 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 eine höhere Log-Ebene festlegen.

Es gibt fünf Log-Ebenen. Die verfügbaren Log-Ebenen der von höchsten zu niedrigsten Ebene sind:

ERROR

Fehlgeschlagene Aktion einer AWI -Komponente, von der sich das AWI nicht erholen konnte, wie z. B. nullPointExceptions oder closedStreamExceptions.

Nachverfolgung von Daten in der Nachricht

Keine benutzeridentifizierenden 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

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.

Nachverfolgung von Daten in der Nachricht

Wie ERROR-Ebene
INFO (Standard)

Konfigurationswerte beim Anmelden oder Hochfahren von Komponenten oder globale Konfigurationsänderungen.

Nachverfolgung von Daten in der Nachricht

wie ERROR-Ebene, jedoch ohne vollständigen Stack-Trace.
DEBUG

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

Nachverfolgung von Daten in der Nachricht

Benutzerinformationen (z. B. Benutzer-ID und HTTP-Session-ID) und ereignisbezogene Angaben.
TRACE

Benutzerspezifische Aktionen auf niedriger Ebene wie Navigation, Objekt öffnen, Tastenklicks, die Nutzlast von Backend-Aufrufen, interne Anwendungsereignisse und alle Aufrufe an das Backend.

Nachverfolgung von Daten in der Nachricht

wie bei DEBUG

Log-Ebene wechseln

Das Logging ist standardmäßig aktiviert und auf INFO gesetzt. Sie können es jedoch entweder in der Konfigurationsdatei logback.xml oder auf der Benutzeroberfläche ändern.

Wichtig! Wenn Sie die Log-Ebene über die Benutzeroberfläche ändern, geht diese Änderung verloren, sobald Sie den Anwendungsserver neu starten.

Informationen zum Ändern der Log-Ebene finden Sie unter:

Anpassen der Benutzeroberfläche

Standardmäßig hat das AWI 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. Stellen Sie sicher, dass die Bildgröße nicht größer als die folgenden Werte ist:
- 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. Diese Datei finden Sie hier:
- Für Installationen mit Tomcat im Ordner ...\webapps\AWI\config\theme
- Für Installationen mit dem Bundled Jetty Launcher im Ordner /config im Delivery Artifact
Geben Sie im Parameter maincolor den RGB-Farbcode, dem ein Pfundzeichen (#) vorausgeht und ein Semikolon (;) folgt.

Beispiel: maincolor = #fac800; für Standardgold

Hinweis: (Tomcat) Wenn Sie die Änderungen bei der nächsten Anmeldung an AWI nicht sehen, starten Sie den Webserver neu.

Weitere Informationen finden Sie unter colors.properties - Konfigurieren des Farbschemas.

Anpassen der Konfigurationsdateien

AWI hat obligatorische und optionale Konfigurationsdateien, die Sie ändern müssen/können. Die folgende Liste enthält Links zu den Themen, die diese Dateien beschreiben:

uc4config.xml - Konfigurieren der Verbindung zwischen AWI und AE: Zwingend erforderlich.

Zur Definition der Verbindung zwischen der AWI-Installation und den AE-Systemen, die als Backend verwendet werden können.

In Automic Automation Kubernetes Edition müssen alle Änderungen an der Konfigurationsdatei uc4config.xml im Bereich awi-properties der ConfigMap vorgenommen werden. Weitere Informationen finden Sie unter Container-basierte Systeme konfigurieren.
logback.xml - Log-Ebenen konfigurieren: 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 – Lokales Setup konfigurieren: Zwingend erforderlich.

Zur Definition von Aspekten der Kommunikation zwischen dem AWI und der AE, z. B. der Sicherheitsoptionen und Timeout-Intervalle.
colors.properties - Konfigurieren des Farbschemas: Optional.

Zur Definition einer benutzerdefinierten Themenfarbe für die AWI-Benutzeroberfläche.

Wichtig! Die Konfigurationsdateien, die nicht in dieser Dokumentation beschrieben sind, sollten nicht geändert werden.

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.

Umgebungsvariablen

Ab dieser Version können Sie auch Umgebungsvariablen verwenden, um die Parameter der AWI-Konfigurationsdateien zu definieren.

Alle AWI-Einstellungen verwenden das Syntaxmuster ${PREFIX_KEYNAME:DEFINITION}:

PREFIX: AUTOMIC

Konstantes Präfix für alle AWI-Einstellungen.
KEYNAME:

Entspricht dem in den Dateien configuration.properties.xml und corlors.properties.xml definierten Eigenschaftsnamen. Der KEYNAME wird in Großbuchstaben geschrieben, und Punkte werden durch Unterstriche ersetzt. Beispiel: Die Eigenschaft session.colors wird zu AUTOMIC_SESSION_COLORS.
DEFINITION:

Der Wert, den Sie für den Schlüssel definieren möchten

Beispiel:

Umgebungsvariablenschlüssel: AUTOMIC_SSO_SAML_ENABLED

Wert: Gibt an, ob Single Sign-on (SSO) für das AWI-Login verwendet werden kann

Beispiel: true

Umgebungsvariablen in Container-basierten Systemen

In der Automic Automation Kubernetes Edition müssen Sie Umgebungsvariablen verwenden, um die Parameter der AWI-Konfigurationsdateien zu definieren.

Sie können die Umgebungsvariablen unter Verwendung der Datei values.yamlvor und nach der Installation festlegen. Nachdem Ihre Instanz bereitgestellt wurde, können Sie auch den Abschnitt ae-properties und awi-properties der configmap verwenden, um Änderungen vorzunehmen.

Mehr Informationen:

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/SSL-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 und http://backend2/awi befinden, und Ihr Host Balancer auf dem Host publicawihost, konfigurieren Sie Ihren Load Balancer so, dass er AWI auf http(s)://publicawihost/awi unterstützt.

Statusprüfung

Verwenden Sie die Integritätsprüfung von AWI, um zu überprüfen, ob der Anwendungsserver AWI richtig bereitgestellt hat, und das es ausgeführt wird.

Fügen Sie der URL das Wort status hinzu:

http://hostName:<port>/AWI/status
Der Standard-Statusantwortcode OK von HTTP 200 wird zurückgegeben und eine Seite mit dem Wort OK wird angezeigt, was darauf hinweist, dass AWI ausgeführt wird. Andernfalls wird die entsprechende standardmäßige HTTP-Meldung angezeigt.

Sie können dieses Endpunkt für den Systemstatus in Ihren internen URL-Überwachungssystemen verwenden, um sicherzustellen, AWI richtig funktioniert.

Sie können diesen Endpunkt auch in Shell-Scripts verwenden, um den Status des Automic Web Interface abzurufen.

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

AWI verwendet WebSockets als effiziente Methode, Informationen an den Mandanten zu senden. Wenn der Anwendungsserver WebSockets nicht unterstützt, greift das AWI auf langes Polling zurück.

Hinweise:

Setzen Sie den Parameter allowWebsockets=false in der Datei configuration.properties. Weitere Informationen finden Sie unter
Die Ausführung von AWI ohne WebSockets erhöht die CPU-Last auf dem Servlet-Container leicht. Fügen Sie weitere Ressourcen hinzu, 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 die Navigation für einen menschlichen Benutzer herausfordernd ist, hat es einen Nebeneffekt auf die Leistung. Der Root-Ordner wird standardmäßig in Process Assembly angezeigt, und eine lange Liste von Objekten (Tausende) erhöht den Speicher pro Session sowie die CPU, die beim Abrufen der Ordnerliste verwendet wird, 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.

Was Sie tun können:
- Erhöhen Sie den Arbeitsspeicher und den Java-Heapspeicherplatz
- Erhöhen Sie die Anzahl der CPU-Kerne
Die Ladezeiten sind zu lang

Wahrscheinlich ist die Automation Engine der Engpass. Sie können die Anzahl der DWPs und JWPs erhöhen.