1. Neue Funktionen

1.1. API-Versionierung zu 2.0 geändert

Alle bisherigen /api/1.*-Endpunkte wurde kopiert und unter /api/2.0/* zur Verfügung gestellt. Damit wurden die folgenden Endpunkte neu hinzugefügt:

  • POST /api/2.0/auth/login

  • POST /api/2.0/workbench/task/simulate-work/create

  • GET /api/2.0/workbench/task/simulate-work/{id}/result

  • POST /api/2.0/workbench/task/execute-batch-job/create

  • GET /api/2.0/workbench/task/execute-batch-job/{id}/result

  • GET /api/2.0/workbench/task/list

  • GET /api/2.0/workbench/task/{id}

  • DELETE /api/2.0/workbench/task/{id}/cancel

  • GET /api/2.0/workbench/node/instance/list

  • GET /api/2.0/workbench/node/instance/{id}

  • PATCH /api/2.0/workbench/node/instance/{id}/start

  • PATCH /api/2.0/workbench/node/instance/{id}/stop

Für die folgenden Endpunkte wurde keine Kopie für /api/2.0/* erstellt:

  • GET /api/1.1/workbench/task/list/running (Stattdessen kann GET /api/2.0/workbench/task/list mit Query-Parametern zum Filtern verwendet werden)

  • GET /api/1.1/workbench/task/list/waiting (Stattdessen kann GET /api/2.0/workbench/task/list mit Query-Parametern zum Filtern verwendet werden)

  • GET /api/1.1/workbench/node/server/list (siehe Optimierung Load Balancing)

  • GET /api/1.1/workbench/node/server/{id} (siehe Optimierung Load Balancing)

Mit Hinzufügen der neuen Endpunkte, wurden die folgenden Endpunkte zu den Legacy-Endpunkten verschoben:

  • POST /api/1.0/auth/login

  • POST /api/1.1/workbench/task/simulate-work/create

  • GET /api/1.1/workbench/task/simulate-work/{id}/result

  • POST /api/1.1/workbench/task/execute-batch-job/create

  • GET /api/1.1/workbench/task/execute-batch-job/{id}/result

  • GET /api/1.1/workbench/task/list

  • GET /api/1.1/workbench/task/list/running

  • GET /api/1.1/workbench/task/list/waiting

  • GET /api/1.1/workbench/task/{id}

  • DELETE /api/1.0/workbench/task/{id}/cancel

  • GET /api/1.1/workbench/node/instance/list

  • GET /api/1.1/workbench/node/instance/{id}

  • PATCH /api/1.0/workbench/node/instance/{id}/start

  • PATCH /api/1.0/workbench/node/instance/{id}/stop

  • GET /api/1.1/workbench/node/server/list

  • GET /api/1.1/workbench/node/server/{id}

Legacy-Endpunkte bleiben zunächst für die Abwärtskompatibilität verfügbar. Mit Version 3.0 des FVA Simulation Hub werden diese aber entfernt.

1.2. Unterstützendes UI mit ReactJS

Das unterstützende UI des FVA Simulation Hub wurde auf ReactJS umgestellt. Damit ist das Frontend "sauber" vom Bachend getrennt und es verwendet ausschließlich die bereitgestellte REST-API.

Im Zuge der Umstellung wurden die folgenden Endpunkte hinzugefügt:

  • GET /api/2.0/auth/refresh

  • GET /api/2.0/auth/logout

  • GET /api/2.0/user

  • GET /api/2.0/workbench/node/instance/{id}/log/{type}

  • GET /api/2.0/workbench/node/instance/{id}/log/download

  • GET /api/2.0/workbench/task/{id}/log

  • GET /api/2.0/monitoring/server-info

  • GET /api/2.0/admin/prepare-shutdown

  • POST /api/2.0/admin/prepare-shutdown/change

Zudem wurden die folgenden Konfigurationparameter hinzugeüfgt:

  • app.security.accessToken.expirationTimeUnit

  • app.security.refreshToken.secret

  • app.security.refreshToken.expiration

  • app.security.refreshToken.expirationTimeUnit

Der Konfigurationparameter app.security.gui.enableUnsecuredGui wurde gelöscht.

1.3. Wildcard-Zeichen bei Zuordnung der Workbench-Version

Mit dem Endpunkt zur Bearbeitung von Batch-Jobs kann die Version der FVA-Workbench angegeben werden, die zur Bearbeitung des Tasks verwendet werden soll. Bei dieser Angabe kann jetzt das Wildcard-Zeichen x angegeben werden, um mehrere FVA-Workbench-Versionen mit einzuschließen (z. B.: 9.0.x).

Die folgenden Endpunkte ermöglichen die Angabe der Versionsnummer mit Wildcard-Zeichen:

  • POST /api/2.0/workbench/task/execute-batch-job/create

  • POST /api/2.0/workbench/task/simulate-work/create

Beispiel für die Anfrage des Endpunkts /api/2.0/workbench/task/execute-batch-job/create:

{
  "inputModel":
  {
    "type": "WBPZ",
    "content": "UEsDBAoAAAAAAMNwGFUAAAAAAAAAA..."
  },
  "inputScripts": [
    {
      "content": "cnVuQ2FsY01ldGhvZCgnMDAxX1NZU1RFTV9DQUxDVUxBVElPTicsIDEpOw=="
    }
  ],
  "classifiers": [
    {
      "type": "VERSION",
      "value": "9.0.x" (1)
    }
  ]
}
1 Die Angabe 9.0.x sorgt dafür, dass alle 9.0er FVA-Workbench-Versionen zu Bearbeitung verwendet werden können.

1.4. Result-Endpunkte um Zeitstempel erweitert

Die Antworten der folgenden Result-Endpunkte wurden um die Zeitstempel requestedDatetime, startedDatetime und endedDatetime erweitert:

  • POST /api/2.0/workbench/task/simulate-work/create

  • GET /api/2.0/workbench/task/simulate-work/{id}/result

  • POST /api/2.0/workbench/task/execute-batch-job/create

  • GET /api/2.0/workbench/task/execute-batch-job/{id}/result

Beispiel für die Antwort des Endpunkts /api/2.0/workbench/task/execute-batch-job/{id}/result:

{
  "status": "FINISHED",
  "id": "b431a18d-8e92-46d9-a9a5-b456dbc898e3",
  "executingWorkbench":
  {
    "id": "foo",
    "version": "7.1.0",
    "revision": "12345"
  },
  "batchExecutionStatus": "OK",
  "requestedDatetime": "2022-03-30T13:20:48.940547", (1)
  "startedDatetime": "2022-03-30T13:25:48.4796426", (2)
  "endedDatetime": "2022-03-30T13:25:58.6424796", (3)
  "outputFiles": [
    {
      "filename": "protocol.log",
      "content": "UEsDBAoAAAAAAKlbVlIAAAAAAAAAAAAAA..."
    }
  ]
}
1 Zeitpunkt zu dem der Request eingegangen ist.
2 Zeitpunkt zu dem mit der Ausführung des Tasks begonnen wurde.
3 Zeitpunkt zu dem die Ausführung des Tasks beendet wurde.

1.5. Query-Parameter zum Filtern von List-Endpunkten

Die folgenden List-Endpunkte wurden um Query-Parameter zum Filtern erweitert:

  • GET /api/2.0/workbench/task/list

  • GET /api/2.0/workbench/node/instance/list

  • GET /api/2.0/workbench/node/agent/list

Beispiel:

GET /api/2.0/workbench/task/list?priority=NORMAL&status=WAITING HTTP/1.1 (1)
Host: example.com
1 Die Anfrage liefert eine Liste mit allen Tasks der Priorität NORMAL und dem Status WAITING.

1.6. Konfiguration der ID von Workbench-Instanzen ermöglicht

Bisher wurden beim Start des FVA Simulation Hub immer die IDs der konfigurierten FVA-Workbench-Instanzen automatisch generiert.

Die IDs der FVA-Workbench-Instanzen können jetzt mit Hilfe des Konfigurations-Parameters app.workbench.instances[0].id festgelegt werden. Der Parameter legt die vordefinierte ID für eine FVA-Workbench-Instanz fest.

Das folgende Beispiel zeigt einen Auszug aus der Konfigurationsdatei application.yml:

[...]
app:
  workbench:
    instances:
      -
        id: foobar (1)
        workbenchDirectory: C:\\FVA-Simulation-Hub\\worker\\FVA-Workbench-9.0.0
1 Mit id: foobar wird die ID der FVA-Workbench-Instanz auf foobar festgelegt.

1.7. Eigener Storage zur Übertragung großer Dateien

Um die Übertragung großer Dateien performanter zu gestalten, wurde ein eigener Storage bereitgestellt.

Damit können große Modelldateien jetzt vor der Berechnung auf den Server der Anwendung hochgeladen werden. Es entfällt damit die clientseitige Kodierung zu Base64 und die serverseitige Dekodierung von Base64. Zudem können die Modelldateien auf dem Server verbleiben und für weitere Berechnungen referenziert werden.

Zudem können große, durch Berechungen generierte Dateien im Storage abgelegt und separat heruntergeladen werden. Es entfällt damit die serverseitige Kodierung zu Base64 und die clientseitige Dekodierung von Base64.

Die Aktivierung des Storage erfolgt über die Konfigurationsparameter app.storage.input.enable bzw. app.storage.output.enable.

Die folgenden Endpunkte wurden für den Storage hinzugefügt:

  • POST /api/2.0/storage/input/upload

  • GET /api/2.0/storage/input/{name}

  • DELETE /api/2.0/storage/input/{name}/delete

  • GET /api/2.0/storage/output/{name}/download

Bei der Erstellung eines Tasks für einen Batch-Job kann eine im Storage hinterlegte Modelldatei folgendermaßen referenziert werden.

Beispiel für die Anfrage des Endpunkts /api/2.0/workbench/task/execute-batch-job/create:

{
  "inputModel": {
    "type": "WBPZ",
    "storageName": "cylindrical-gear_model.wbpz" (1)
  },
  "inputScripts": [
    {
      "content": "cnVuQ2FsY01ldGhvZCgnMDAxX1NZU1RFTV9DQUxDVUxBVElPTicsIDEpOw=="
    }
  ]
}
1 Mit dem Parameter storageName wird der eindeutige Name der Modelldatei im Storage angegeben.

1.8. Übernahme von Konfigurationsdateien für Workbench-Instanzen

Mit dem neuen Konfigurationsparameter app.workbench.instances[0].additionalConfigDirectory kann für die FVA-Workbench-Instanzen ein Verzeichnis mit zusätzlichen Konfigurationsdateien angegeben werden.

Beim Start der Workbench-Instanz werden die darin enthaltenen Dateien und Verezeichnisse in der Workbench-Verzeichnis (siehe auch Konfigurationsparameter app.workbench.instances[0].workbenchDirectory) kopiert.

Dadurch hat man die Möglichkeit, Konfigurationsdateien für die Workbench (z. B. default.epf oder Logging-Einstellungen) an nur einer zentralen Stelle zu verwalten und für mehrere auszuführende Workbench-Instanzen zu verwenden.

1.9. Zeitgesteuerter Neustart von Workbench-Instanzen

Mit den Konfigurationparametern app.workbench.defaultSchedules[0] und app.workbench.instances[0].schedules[0] können Zeitpläne konfiguriert werden, mit denen FVA-Workbench-Instanzen automatisiert neugestartet werden können.

Das folgende Beispiel zeigt einen Auszug aus der Konfigurationsdatei application.yml:

[...]
app:
  workbench:
    instances:
      -
        id: foobar
        workbenchDirectory: C:\\FVA-Simulation-Hub\\worker\\FVA-Workbench-9.0.0
        schedules: (1)
          -
            schedule: '0 0 3 * * *' (2)
            action: restart (3)
1 Mit schedules können zu jeder FVA-Workbench-Instanz mehrere Zeitpläne konfiguriert werden.
2 Durch den Parameter schedule wird der Zeitplan mittels eines CRON-Ausdrucks festgelegt (hier: Ausführung jeden Tag 3:00).
3 Der Parameter action legt die auszuführende Aktion fest (hier: Neustart).

Mit den notwendigen Anpassungen wurde zudem der Endpunkt /api/2.0/workbench/node/instance/{id}/restart hinzugefügt, um eine FVA-Workbench-Instanz über die bereitgestellte REST-API neuzustarten.

1.10. Automatisiertes Abbrechen und Löschen von Tasks

Mit den Konfigurationparametern app.task.schedules[0].* können Zeitpläne konfiguriert werden, mit denen Tasks automatisiert abgebrochen oder gelöscht werden können.

Das folgende Beispiel zeigt einen Auszug aus der Konfigurationsdatei application.yml:

[...]
app:
  task:
    schedules: (1)
      -
        schedule: '0 0 * * * *' (2)
        filters: (3)
          status:
            - WAITING
          priority:
            - LOWEST
          requestedDatetime:
            olderThan: 5
            olderThanTimeUnit: HOURS
        action: cancel (4)
1 Mit schedules können mehrere Zeitpläne für Tasks konfiguriert werden.
2 Durch den Parameter schedule wird der Zeitplan mittels eines CRON-Ausdrucks festgelegt (hier: Ausführung zu jeder vollen Stunde).
3 Durch den Patameter filters werden die Parameter festgelegt, um die Tasks einzuschränken, für die die festgelegte Aktion ausgeführt werden soll (hier: Alle wartenden Tasks mit der niedrigsten Priorität, die vor mehr als 5 Stunden angenommen wurden).
4 Der Parameter action legt die auszuführende Aktion fest (hier: Abbruch).

1.11. Löschen von Tasks ermöglicht

Mit dem neuen Endpunkt DELETE /api/2.0/workbench/task/{id}/delete können Task und alle zugehörigen Ergebnisse gelöscht werden.

Diese Aktion ist nur für Tasks in den Status FINISHED, FAILED und CANCELED möglich.

2. Verbesserungen

2.1. Migration zu Java 21

Die Anwendung wurde zur aktuellen LTS-Version von Java migriert. Als Systemvoraussetzung zur Ausführung der Anwendung gilt deshalb ab sofort Java 21.

Bei der Installation der Anwendung ist zu beachten, dass Java in der Version 21 bereitgestellt wird.

2.2. Optimierung des Load Balancing

Das Load Balancing des FVA Simulation Hub wurde komplett überarbeitet und bietet jetzt folgende neue Möglichkeiten:

  • Bessere Verteilung auf Agent-Knoten (Agents melden sich beim Gateway und holen wartende Tasks, wenn sie freie Resourcen haben)

  • Gateway-Knoten kennt Agent-Knoten nicht (Agents mit Workbench-Instanzen müssen nicht übers Internet/Netzwerk erreichbar sein)

Die veralteten Begriffe Master und Slave wurden in diesem Zusammenhang auf Gateway und Agent geändert.

Alle Konfigurationparameter mit app.loadBalancing.master.* und app.loadBalancing.slave.* wurden entfernt. Es wurden Parameter mit app.loadBalancing.gateway.* und app.loadBalancing.agent.* eingeführt.

Die Enpunkte GET /api/1.1/workbench/node/server/* wurden für Version 2.0 folgendermaßen benannt:

  • GET /api/2.0/workbench/node/agent/list

  • GET /api/2.0/workbench/node/agent/{id}

2.3. Konfigurationsparameter app.task.defaultWorkbenchVersion optional

Die Angabe des Konfigurationsparameters app.task.defaultWorkbenchVersion ist ab jetzt optional.

Der Parameter legt die Version der FVA-Workbench fest, die verwendet werden soll, falls keine in der Anfrage angegeben wurde. Besonders im Zusammenhang mit dem Load Balancing kann dieser Parameter zu Problemen führen, da bei Änderungen ein Neustart erforderlich und der Gateway in dieser Zeit nicht erreichbar ist.

2.4. Informationen zur ausführenden FVA-Workbench um id erweitert

Die Endpunkte für die Ergebnisse von Tasks enthalten bereits Hinweise zur ausführenden FVA-Workbench. Diese Hinweise wurden um die Eigenschaft id erweitert.

Die Antworten der folgenden Endpunkte wurden um die zusätzlichen Informationen erweitert:

  • POST /api/2.0/workbench/task/simulate-work/create

  • GET /api/2.0/workbench/task/simulate-work/{id}/result

  • POST /api/2.0/workbench/task/execute-batch-job/create

  • GET /api/2.0/workbench/task/execute-batch-job/{id}/result

Beispiel für die Antwort des Endpunkts /api/2.0/workbench/task/execute-batch-job/{id}/result:

{
  "status": "FINISHED",
  "id": "b431a18d-8e92-46d9-a9a5-b456dbc898e3",
  "executingWorkbench":
  {
    "id": "foo", (1)
    "version": "7.1.0",
    "revision": "12345"
  },
  "batchExecutionStatus": "OK",
  "outputFiles": [
    {
      "directory": "path/to/file/in/output/directory",
      "filename": "error.log",
      "content": "UEsDBAoAAAAAAKlbVlIAAAAAAAAAAAAAA..."
    }
  ]
}
1 id gibt den Identifier der ausführenden FVA-Workbench an.

2.5. Health-Komponente nodes entfernt

Beim Endpunkt GET /actuator/health wurde die Komponente nodes entfernt. Als Ersatz sollte der Endpunkt GET /api/2.0/workbench/node/instance/list verwendet werden.

Vorher:

HTTP/1.1 200
Date: Fri, 13 Jan 2006 15:32:43 GMT
Location: http://example.com/actuator/health
Content-Type: application/json

{
  "status": "DOWN", (3)
  "components": {
    "diskSpace": {
      "status": "UP",
      "details": {
        "total": 402008244224,
        "free": 320568209408,
        "threshold": 10485760,
        "exists": true
      }
    },
    "nodes": {
      "status": "DOWN", (2)
      "details": {
        "totalInstances": 2,
        "runningInstances": 0 (1)
      }
    },
    "ping": {
      "status": "UP"
    }
  }
}
1 Beispielsweise durch Neustart der Instanzen könnte es sein, dass es keine laufenden FVA-Workbench-Instanzen gibt.
2 Keine laufenden FVA-Workbench-Instanzen liefert DOWN für den Status der Komponente nodes.
3 Das DOWN für die Komponente nodes resultiert im Health-Status DOWN, obwohl der Dienst zur Verfügung steht.

Nachher:

HTTP/1.1 200
Date: Fri, 13 Jan 2006 15:32:43 GMT
Location: http://example.com/actuator/health
Content-Type: application/json

{
  "status": "UP", (1)
  "components": {
    "diskSpace": {
      "status": "UP",
      "details": {
        "total": 402008244224,
        "free": 320568209408,
        "threshold": 10485760,
        "exists": true
      }
    },
    "ping": {
      "status": "UP"
    }
  }
}
1 Die Anzahl der laufenden FVA-Workbench-Instanzen haben keinen Einfluss auf den Health-Status.

2.6. Konfigurationsparameter app.workbench.instances[0].templatePath entfernt

Die Angabe des Konfigurationsparameters app.workbench.instances[0].templatePath ist ab jetzt nicht mehr möglich.

Seit Version 9.0 können FVA-Workbench-Instanzen mehrfach aus einem Installationsverzeichnis gestartet werden. Aus diesem Grund ist der Parameter nicht mehr notwendig und wurde entfernt.

2.7. error.log zu protocol.log umbenannt

Die in dem Endpunkt /api/2.0/workbench/task/execute-batch-job/{id}/result standardmäßig enthaltene Datei error.log wurde zu protocol.log umbenannt.

Die Datei ist auch bei einer erfolgreichen Bearbeitung immer Bestandteil des Ergebnisses und enthält zudem allgemeine Informationen zur Bearbeitung innerhalt der FVA-Workbench. Der bisherige Dateiname war demnach irreführend.

Beispiel für die Antwort des Endpunkts /api/2.0/workbench/task/execute-batch-job/{id}/result:

{
  "status": "FINISHED",
  "id": "b431a18d-8e92-46d9-a9a5-b456dbc898e3",
  "executingWorkbench":
  {
    "id": "foo",
    "version": "7.1.0",
    "revision": "12345"
  },
  "batchExecutionStatus": "OK",
  "requestedDatetime": "2022-03-30T13:20:48.940547",
  "startedDatetime": "2022-03-30T13:25:48.4796426",
  "endedDatetime": "2022-03-30T13:25:58.6424796",
  "outputFiles": [
    {
      "filename": "protocol.log", (1)
      "content": "UEsDBAoAAAAAAKlbVlIAAAAAAAAAAAAAA..."
    }
  ]
}
1 Der Dateiname lautet jetzt protocol.log.

2.8. Rückgabe der Log-Dateien bei fehlgeschlagenen Batch-Jobs

Die wärend eines Batch-Jobs erstellte Log-Datei (früher: error.log, jetzt: protocol.log) wurde bei einem Abbruch oder Fehlschlag nicht mit über den Endpunkt /api/2.0/workbench/task/execute-batch-job/{id}/result zurückgegeben.

Ab sofort werden alle Dateien, die bis zum Abbruch oder Fehlschlag im Ausgabeverzeichnis hinterlegt wurden, als Bestandteil des Ergebnisses mit zurückgegeben.

2.9. Aufräumen der Ausführungsdateien von FVA-Workbench-Instanzen

FVA-Workbench-Instanzen benötigen zur Ausführung ein Verzeichnis in dem verschiedene Progammdateien abgelegt werden. Bisher wurden diese Verzeichnisse in den temporären Dateien hinterlegt und nicht automatisiert gelöscht.

Ab sofort kann das Verzeichnis für die Ausführungsdateien der FVA-Workbench-Instanzen mit dem Konfigurationsparameter app.workbench.dataDirectory festgelegt werden. Dieses Verzeichnis wird durch die Anwendung überwacht und nicht mehr benötigte Dateien und Verzeichnisse werden automatisiert gelöscht.

2.10. Untersützung der REXS-Dateiformate .rexsz und .rexsj

Mit dem Endpunkt zur Bearbeitung von Batch-Jobs können jetzt auch die REXS-Dateiformate .rexsz und .rexsj verwendet werden.

2.11. Informationen der FVA-Workbench-Instanzen um Startzeitpunkt erweitert

Die Endpunkte mit Informationen zu FVA-Workbench-Instanzen wurden um den Startzeitpunkt der Instanzen erweitert.

Die Antworten der folgenden Endpunkte wurden um die zusätzlichen Informationen erweitert: * GET /api/2.0/workbench/node/instance/list * GET /api/2.0/workbench/node/instance/{id}

Beispiel für die Antwort des Endpunkts /api/2.0/workbench/node/instance/{id}:

{
  "id": "btuU-dRQkvJ3YeEEzWaRz",
  "version": "7.1.0",
  "revision": "12345",
  "labels": [],
  "status": "UP",
  "startedDatetime": "2022-03-30T13:25:48.4796426", (1)
  "working": false
}
1 startedDatetime gibt an, wann die FVA-Workbench-Instanz gestartet wurde.

2.12. Task-Endpunkte um Klassifizierungen erweitert

Die Endpunkte mit Informationen zu Tasks wurden um Klassifizierungen erweitert.

Die Antworten der folgenden Endpunkte wurden um die zusätzlichen Informationen erweitert: * GET /api/2.0/workbench/task/list * GET /api/2.0/workbench/task/{id}

Beispiel für die Antwort des Endpunkts /api/2.0/workbench/task/{id}:

{
  "id": "mRsoooWBmyFNtk0x3ug6j",
  "type": "SIMULATE_WORK",
  "name": "My simulate work task",
  "priority": "NORMAL",
  "classifiers": [ (1)
    {
      "type": "VERSION",
      "value": "7.1.1"
    },
    {
      "type": "PRIORITY",
      "value": "NORMAL"
    },
  ],
  "creator": "user1",
  "requestedDatetime": "2022-03-30T13:20:48.940547",
  "startedDatetime": "2022-03-30T13:25:48.4796426",
  "endedDatetime": "2022-03-30T13:25:58.4796426",
  "status": "FINISHED"
}
1 classifiers gibt alle, dem Task zugeordneten, Klassifizierungen an.

2.13. Abbruch auch für laufende Tasks

Mit dem Endpunkt DELETE /api/2.0/workbench/task/{id}/cancel können jetzt auch laufende Tasks abgebrochen werden. Bisher war das nur für Tasks in der Warteschlange möglich.

3. Gelöste Anforderungen

3.1. Gelöste Anforderungen in v2.0.0

Type Summary

Neue Funktion

API-Versionierung zu 2.0 geändert

Neue Funktion

Unterstützendes UI mit ReactJS

Neue Funktion

Wildcard-Zeichen bei Zuordnung der Workbench-Version

Neue Funktion

Result-Endpunkte um Zeitstempel erweitert

Neue Funktion

Query-Parameter zum Filtern von List-Endpunkten

Neue Funktion

Konfiguration der ID von Workbench-Instanzen ermöglicht

Neue Funktion

Eigener Storage zur Übertragung großer Dateien

Neue Funktion

Übernahme von Konfigurationsdateien für Workbench-Instanzen

Neue Funktion

Zeitgesteuerter Neustart von Workbench-Instanzen

Neue Funktion

Automatisiertes Abbrechen und Löschen von Tasks

Neue Funktion

Löschen von Tasks ermöglicht

Verbesserung

Migration zu Java 21

Verbesserung

Optimierung des Load Balancing

Verbesserung

Konfigurationsparameter app.task.defaultWorkbenchVersion optional

Verbesserung

Informationen zur ausführenden FVA-Workbench um id erweitert

Verbesserung

Health-Komponente nodes entfernt

Verbesserung

Konfigurationsparameter app.workbench.instances[0].templatePath entfernt

Verbesserung

error.log zu protocol.log umbenannt

Verbesserung

Rückgabe der Log-Dateien bei fehlgeschlagenen Batch-Jobs

Verbesserung

Aufräumen der Ausführungsdateien von FVA-Workbench-Instanzen

Verbesserung

Untersützung der REXS-Dateiformate .rexsz und .rexsj

Verbesserung

Informationen der FVA-Workbench-Instanzen um Startzeitpunkt erweitert

Verbesserung

Task-Endpunkte um Klassifizierungen erweitert

Verbesserung

Abbruch auch für laufende Tasks

Bugfix

FVA-Workbench-Instanzen mit initialStatus=DOWN konnte nach dem Start der Anwendung nicht mehr gestartet werden

Bugfix

Wegen JobTimeout beendete FVA-Workbench-Instanzen führten zu Fehlschlägen bei nachfolgenden Tasks

Bugfix

Fehlerhafte Übernahme von JobTimeout korrigiert (betrifft nur Werte größer gleich 1.000)

Dokumentation

Installationsanleitung wurde komplett überarbeitet

Dokumentation

Abschnitt "Entwicklung" wurde um Tutorials erweitert