INUBIT in der Datei ibis.xml konfigurieren

Konfigurationsdatei

<SUITE-INSTALL-DIR>/inubit/server/ibis_root/conf/ibis.xml

<Properties version="4.1">
  <Property name="LocalMaintenanceMode" type="Boolean">false</Property>
  <Property name="Database" type="Map">
    <Property name="driverClass">org.h2.Driver</Property>
    <Property name="jdbcUrl">jdbc:h2:${ibis.root.directory}/ibis_data/database/ibis;MVCC=TRUE</Property>
    <!-- Encrypted password and/or user name
      To get your encrypted password and/or user name use the CLI client.
      Example:
        cd path/to/inubit_installation/server/process_engine/bin
        ./startcli.sh -\-encryptString myPassword
      Insert the encrypted password and/or user name as values into the corresponding property tags and set the
      attribute encrypted="false" to encrypted="true".
      Example:
        <Property name="user" type="EncryptedString" encrypted="true">AES-ZKEFCtfXeLAmGUdQ2zomyA==</Property>
        <Property name="password" type="Password" encrypted="true">AES-ZKEFCtfXeLAmGUdQ2zomyA==</Property>
    -->
    <Property name="user" type="EncryptedString" encrypted="false">sa</Property>
    <Property name="password" type="Password" encrypted="false">secret</Property>
    <Property name="socketTimeoutInMillisecs" type="Long">180000</Property>
    <Property name="checkoutTimeoutInMillisecs" type="Long">120000</Property>
    <Property name="driverProperties" type="Map"/>
    <Property name="minPoolSize" type="Integer">5</Property>
    <Property name="maxPoolSize" type="Integer">30</Property>
  </Property>
  <Property name="DataSourceLocation">java:/comp/env/jdbc/IBISDB</Property>
  <Property name="RuntimeDataBackupStore">FILE</Property>
  <Property name="RuntimeDataCacheXMXPercentage" type="Integer">25</Property>
  <!-- Retry happens based on number of retries configured below -->
  <Property name="noOfRetries" type="Integer">3</Property>
  <!-- Retry interval value should be given in milliseconds-->
  <Property name="retryInterval" type="Long">2000</Property>
  <Property name="MaxEntriesInMemoryLimit" type="Map">
    <Property name="Workflow_Data_Version" type="Integer">-1</Property>
    <Property name="Module_Data_Version" type="Integer">-1</Property>
  </Property>
  <Property name="indexEnabled" type="Boolean">false</Property>
</Properties>

Datenbank in der Datei ibis.xml konfigurieren

Verwendung

Setzen der Parameter für den Datenbankzugriff.

Properties

Datenbanktreiber
- Syntax: driverClass=<database-driver-class>
- Name der Datenbanktreiberklasse
JDBC-URL
- Syntax: jdbcUrl=jdbc:<database>@<port>:<schema>
- Datenbanktreiber-URL
  
  Für MySQL vor der Version 5.7 ist es nur möglich, über TLS 1.2 zu kommunizieren, wenn Sie die Property enabledTLSProtocols=TLSv1.2 der Datenbank-URL hinzufügen.
Benutzername
- Syntax: user=<Benutzername> encrypted="{true|false}"
- Mögliche Werte:
  - true: Der angegebene Benutzername ist verschlüsselt.
  - false: Der angegebene Benutzername ist nicht verschlüsselt und wird beim ersten Serverstart durch den verschlüsselten Benutzernamen ersetzt. Das Attribut encrypted="true" wird automatisch gesetzt.
    
    Siehe Benutzernamen und Passwörter über das CLI verschlüsseln
Passwort
- Syntax: password=<Passwort> encrypted="{true|false}"
- Mögliche Werte:
  - true: Das angegebene Passwort ist verschlüsselt.
  - false: Das angegebene Passwort ist nicht verschlüsselt und wird beim ersten Serverstart durch das verschlüsselte Passwort ersetzt. Das Attribut encrypted="true" wird automatisch gesetzt.
    
    Siehe Benutzernamen und Passwörter über das CLI verschlüsseln
Socket-Timeout
- Syntax: socketTimeoutInMillisecs=<value>
- Zum Konfigurieren der Timeouts für die Socket-Verbindung zwischen JDBC-Treiber und Datenbank. Der Wert bestimmt sowohl Connect-Timeout als auch Read-Timeout. Standardwert ist 180'000 ms (3 Minuten).
Verbindungs-Timeout für das Connection-Pooling
- Syntax: checkoutTimeoutInMillisecs=<value>
- Zum Konfigurieren des Timeouts für das Warten auf die Bereitstellung einer Datenbankverbindung für den Datenbank-Connection-Pool. Standardwert ist 120'000 ms (2 Minuten).
Anzahl der Datenbankverbindungen
```
minPoolSize=5
maxPoolSize=30
```
- Diese beiden Parameter legen fest, wie viele Datenbankverbindungen mindestens und höchstens gleichzeitig verwendet werden dürfen. Vorgabewerte sind 5 bzw. 30.
Unbenutzte Datenbankverbindungen entfernen
- Syntax: removeAbandoned="{true|false}"
- Mögliche Werte:
  - true
    
    Eine Datenbankverbindung wird entfernt, wenn die in der Property removeAbandonedTimeout gesetzte Zeitspanne überschritten ist.
  - false (Standard)
    
    Datenbankverbindungen werden nicht entfernt, auch wenn sie längere Zeit nicht benutzt wurden.
Zeitspanne, nach der unbenutzte Datenbankverbindungen entfernt werden
- Syntax: removeAbandonedTimeout=<value>
- Wenn die Property removeAbandoned auf true gesetzt ist, wird eine Datenbankverbindung entfernt, sobald die in der Property removeAbandonedTimeout gesetzte Zeitpanne in Sekunden überschritten ist. Standardmäßig ist die Property removeAbandonedTimeout auf 21'600 Sekunden (6 Stunden) gesetzt.
  
  Der Wert sollte auf die Zeitspanne gesetzt werden, die die am längsten dauernde Anfrage benötigt.
Prüfung auf gültige Verbindung
- Syntax: CheckValidConnection={true|false}
- Mögliche Werte:
  - true: Wenn eine Verbindung ungültig ist, wird automatisch die nächste Verbindung aus dem Pool ausgewählt.
    
    Diese Property ist standardmäßig auf true gesetzt.
  - false: um die Property zu deaktivieren
    
    Wenn die Property aktiviert ist, kann die Performance dadurch leicht beeinflusst werden.
Wiederholung und Wiederholungsverzögerung für Datenbankabfragen
```
noOfRetries=3
retryInterval=2000
```
- Im Falle von Datenbankfehlern kann die Datenbankabfrage mehrmals wiederholt werden, wie in noOfRetries definiert. Jeder Wiederholungsversuch erfolgt nach einer in retryInterval (in Millisekunden) angegebenen Verzögerung.
  
  Für MSSQL-Deadlocks gilt Folgendes:
  
  Im Falle häufiger Deadlocks in der MSSQL-Datenbank können Sie versuchen, die Anzahl der Wiederholungen und die Wiederholungsverzögerung von Datenbankabfragen zu erhöhen.
  
  Die Standardwerte für diese Properties für MSSQL sind 3 Wiederholungen und 2000 Millisekunden Wiederholungsintervall.
Mehr als ein Schema zulassen (nur für MySQL 8, nicht empfohlen)
- Syntax: nullCatalogMeansCurrent={true|false}
- Wenn ein Datenbankbenutzer Zugriff auf mehrere Schemas hat: Fügen Sie den zusätzlichen Parameter nullCatalogMeansCurrent=true der Datenbank-URL hinzu.

Größe des Laufzeitdaten-Cache begrenzen

Verwendung

Definiert den maximalen Anteil des JVM-Heap (-Xmx), der für das Caching von Laufzeitdaten (Nachrichteninhalte und Workflow-Variablen) im Arbeitsspeicher verwendet werden darf. Wenn die Gesamtgröße aller gecachten Einträge dieses Limit überschreitet oder ein einzelner Eintrag größer als 1 MB ist, werden die Daten automatisch auf die Festplatte geschrieben statt im Arbeitsspeicher gehalten. Die Process Engine arbeitet in diesem Fall normal weiter. Es kommt weder zu einem Fehler noch zu Datenverlust, allerdings steigt die Festplatten-E/A.

Properties

Syntax: RuntimeDataCacheXMXPercentage=25
Standardwert: 25 (25 % des JVM-Heap)
Beispiel:

Wird die JVM mit -Xmx4g (4 GB Heap) gestartet, stehen bei 25 % etwa 1 GB für den Laufzeitdaten-Cache zur Verfügung.
Bei -Xmx16g ergeben 25 % etwa 4 GB.
Empfehlung:

Für Systeme mit deutlich mehr Heap als den standardmäßigen 4 GB kann eine Erhöhung des Werts die Festplatten-E/A reduzieren und den Durchsatz verbessern. Erhöhen Sie den Wert schrittweise und überwachen Sie dabei die Cache-Auslastung sowie das Verhalten der Garbage Collection, da der verbleibende Heap weiterhin für alle weiteren Operationen der Process Engine ausreichen muss. Die Cache-Auslastung kann per JMX überwacht werden (MBean DataStore.Binary, Attribute RuntimeDataCacheMaxSize und RuntimeDataCacheUtilization).

Siehe Verzeichnisstruktur für Details zu den Swap-Verzeichnissen, die bei Überschreitung des Cache-Limits verwendet werden.

Speichermodus für Laufzeitdaten

Verwendung

Legt fest, ob und wo die Process Engine Sicherungskopien der Laufzeitdaten asynchroner Workflow-Ausführungen ablegt, damit Workflows nach einem Neustart oder Absturz wiederhergestellt werden können.

Synchrone Ausführungsdaten sind von dieser Einstellung nicht betroffen. Synchrone Daten verwenden eigene lokale Stores ohne Backup; sie können bei Speicherdruck zwar ebenfalls auf die Festplatte ausgelagert werden, werden aber nicht zur Wiederherstellung persistiert (siehe Verzeichnisstruktur).

Properties

Syntax: RuntimeDataBackupStore={FILE|DB}
Mögliche Werte:
- FILE (Standard)
  
  Laufzeitdaten werden im lokalen Dateisystem persistiert.
  
  Verwenden Sie diese Einstellung für die beste Performance. Dateibasierte Persistierung hat weniger Overhead als Datenbank-Persistierung.
- DB
  
  Laufzeitdaten werden in der Datenbank persistiert (Tabellen IBIS_RT_EXEC_DATA und IBIS_RT_OTHER_DATA).
  
  Verwenden Sie diese Einstellung, wenn Datensicherheit wichtiger als Performance ist.

Wiederholung und Wiederholungsverzögerung für die Cache-Datenbank konfigurieren

Verwendung

Setzen der Parameter für den Cache-Datenbankzugriff.

Properties

noOfRetries=3
retryInterval=2000

Im Falle von Cache-Datenbankfehlern kann die Datenbankabfrage für die in noOfRetries festgelegte Anzahl an Wiederholungen erneut versucht werden. Jeder erneute Versuch erfolgt nach der in retryInterval festgelegten Verzögerungszeit (in Millisekunden).

Die Standardwerte sind 3 Wiederholungen und 2000 Millisekunden Verzögerung.

Lokalen Wartungsmodus konfigurieren

Verwendung

Lokalen Wartungsmodus konfigurieren

Properties

Syntax: LocalMaintenanceMode={true|false}
Mögliche Werte:
- true
  
  Der lokale Wartungsmodus wird aktiviert.
- false
  
  Der lokale Wartungsmodus wird deaktiviert.

Speicher für Versionsdaten konfigurieren

Verwendung

Diese Konfiguration begrenzt die Anzahl der Modul- und Workflow-Versionsdefinitionen (XML-Daten), die die Process Engine in ihrem In-Memory-Cache vorhält. Das Limit bezieht sich auf die Gesamtanzahl der Versionseinträge über alle Module bzw. Workflows hinweg, nicht auf die Anzahl der Module/Workflows selbst.

Beispiel: Ein Limit von 100 für Module_Data_Version bedeutet, dass maximal 100 Modul-Versions-Kombinationen gleichzeitig im Arbeitsspeicher gehalten werden. Bei 20 Modulen mit je 5 Versionen passen alle 100 Einträge in den Cache. Die Versionen eines 21. Moduls würden dazu führen, dass einige der bestehenden Einträge aus dem Arbeitsspeicher verdrängt werden.

Properties

<Property name="MaxEntriesInMemoryLimit" type="Map">
    <Property name="Workflow_Data_Version" type="Integer">-1</Property>
    <Property name="Module_Data_Version" type="Integer">-1</Property>
</Property>

Module_Data_Version: Maximale Anzahl der Modulversions-Einträge im Cache
Workflow_Data_Version: Maximale Anzahl der Workflowversions-Einträge im Cache

Verdrängungsverhalten

Wenn der Cache sein konfiguriertes Limit erreicht, verdrängt die zugrundeliegende Infinispan-Cache-Implementierung Einträge, um Platz für neue zu schaffen. Verdrängte Einträge gehen nicht verloren: alle Versionsdaten werden zusätzlich in der Datenbank gehalten, sodass ein verdrängter Eintrag beim nächsten Zugriff automatisch aus der Datenbank nachgeladen wird. Ein gesetztes Limit beeinflusst also nicht die Verfügbarkeit der Versionsdaten, sondern nur die Zugriffsgeschwindigkeit für Einträge, die gerade nicht im Arbeitsspeicher liegen.

Mögliche Werte

-1 (Standard): Cache-Kapazität ist unbegrenzt. Alle aufgerufenen Versionen verbleiben dauerhaft im Arbeitsspeicher.

Bei einer großen Anzahl von Modul- und Workflow-Versionen kann unbegrenztes Caching zu hohem Speicherverbrauch und Out-of-Memory-Situationen führen.
1..n: Cache-Kapazität ist auf diese Anzahl von Einträgen begrenzt. Passen Sie den Wert basierend auf dem verfügbaren Speicher des Systems und der Anzahl der typischerweise während des Betriebs genutzten Versionen an.

Zeitstempel-Indexierung auf Infinispan

Verwendung

Kontrolliert das Indizierungsverhalten für die Zeitstempelspalten in den Infinispan-Tabellen.

Properties

Syntax: indexEnabled={true|false}
Mögliche Werte:
- true: Aktiviert die Indexierung von Infinispan-Tabellen.
- false: Deaktiviert die Indexierung von Infinispan-Tabellen.

Standardmäßig ist diese Eigenschaft auf false gesetzt. Damit ist ein bestehendes INUBIT-System abwärtskompatibel. Die Indexierung muss so explizit eingeschaltet und das System kann dabei überwacht werden.

Wenn der Parameter nach der Indexierung auf false gesetzt wird, wird dies keine Deindexierung auslösen, da die Indexierung bereits aktiviert wurde.

Wenn Sie den Index aus bestehenden Infinispan-Tabellen löschen möchten, gehen Sie folgendermaßen vor:

Setzen Sie die Eigenschaft auf false in ibis.xml nach Abschalten des Process Engine:
<Property name="indexEnabled" type="Boolean">false</Property>
Führen Sie die entsprechenden SQL-Queries aus, um den Zeitstempel-Index basierend auf Ihrem Datenbanktyp aus allen ISPN-Tabellen zu löschen:
- MariaDB/MySQL
  ALTER TABLE <Database Name>
  DROP INDEX <Database Name>_timestamp_index;
- PostgreSQL
  DROP INDEX <Database Name>_timestamp_index;
- Microsoft SQL
  DROP INDEX <Database Name>_timestamp_index ON <Database Name>;
- Oracle
  DROP INDEX IDX_<Database Name>;
  
  Beispiel: Für eine Tabelle namens ISPN_EDI_RULES in MySQL/MariaDB:
  ALTER TABLE ISPN_EDI_RULES
  DROP INDEX ISPN_EDI_RULES_timestamp_index;
  
  Diese Queries müssen auf allen Tabellen mit der Präfix ISPN_ ausgeführt werden.

ClusterDebug konfigurieren

Syntax: ClusterDebug={true|false}
Mögliche Werte:
- true
  
  Die Änderung des Loglevels ist nach dem Hochfahren in der Workbench über Administration → Logging → Trace möglich.
  
  Wenn der Server neu gestartet wird, protokolliert er erneut auf dem DEBUG-Loglevel, da ClusterDebug auf true gesetzt ist.
- false
  
  Die Änderung des Loglevels ist nach dem Hochfahren in der Workbench über Administration → Logging → Trace möglich.
  
  Wenn der Server neu gestartet wird, protokolliert er erneut auf dem ERROR-Loglevel, da ClusterDebug auf false gesetzt ist.

iterationCount konfigurieren

Der PBKDF2 (Password Based Key Derivation Function 2) Algorithmus zur Verschlüsselung von Benutzerkontopasswörtern verwendet ein iterationCount, um die Anzahl der Anwendungen des Hash-Algorithmus während des Schlüsselableitungsprozesses zu bestimmen. Die Anzahl der Iterationen im PBKDF2 gibt an, wie oft eine Pseudozufallsfunktion (wie HMAC-SHA256) auf ein Passwort angewendet wird, um einen sicheren Schlüssel abzuleiten. Der Standardwert für das iterationCount in ibis.xml beträgt 20000.

Höheres iterationCount: Die Hash-Funktion (z. B. HMAC-SHA256) wird während der Schlüsselableitung häufiger verwendet, wenn das iterationCount höher ist.

Vorteile:
- Erhöhtes Security: Erschwert Brute-Force- und Passwortknackversuche für Angreifer.
- Key Verstärkung: Der abgeleitete Schlüssel ist gegen vorberechnete Angriffe (wie Regenbogentabellen) geschützt, da jede Ableitung mit dem eindeutigen Salt und der Anzahl der Iterationen verknüpft ist.
Nachteile:
- Verzögert die Reaktionszeiten
- Verringert den Durchsatz
- Verursacht einen kurzfristigen Anstieg der CPU- und Festplattennutzung
Niedriges iterationCount: Die Hash-Funktion wird weniger häufig verwendet, wenn das iterationCount niedriger ist.

Vorteile: Nützlich für Geräte mit geringer Leistungsstärke oder Systeme mit hohem Datenverkehr, bei denen Geschwindigkeit entscheidend ist.

Nachteile:

Verringertes Security: Verbessert das Knacken von Passwörtern und Brute-Force-Angriffe für Angreifer.