Changelog

Daten, die bei OIDC-Providern für den Login verwendet werden, werden in einem Cookie verschlüsselt beim Client hinterlegt. Dadurch wird eine Auslastung durch sehr viele Login-Anfragen verhindert.

Für BPC-Modulentwickler

Sollten Sie eine eigene UserFlowIdentityProvider-Implementierung entwickelt haben, müssen Sie diese anpassen. Die Funktion URI createAuthenticationRequestURI(String requestUrl) wurde mit UserFlowLoginContext createAuthenticationRequestContext(String requestUrl) ersetzt und gibt neben der Redirect-URL zum OIDC-Login nun auch einen Cookie, welcher den Login-State enthält, zurück. Dieser Cookie wird beim Login-Versuch vom Frontend gesetzt.

Für BPC-Administratoren

Installieren Sie die neuen Module bpc-be-core.jar und bpc-fe-core.war. Ein Neustart des BPCs/Karaf ist notwendig. Sollte das BPC dann immer noch nicht zur Verfügung stehen, löschen Sie bitte das Verzeichnis karaf/data und starten sie den Karaf erneut. (Evtl. machen Sie davor ein Backup Ihrer Log-Files)

Im Process-Monitoring wurden die Einstellungen inubit_referenceEndpoint, inubit_proxyId, inutbit_baseUrl zum Download über einen HTTP-Proxy zusammengeführt und in httpProxy_referenceEndpoint umbenannt, so dass die Möglichkeit eines Downloads über eine generische HTTP-Proxy-Verbindung verdeutlicht wird. Die Einstellung inubit_dbTablePrefix wurde entfernt, da sie nur für Legacy-Szenarien verwendet wurde.

Timeseries Management Administratoren brauchen, wenn sie nicht der Rolle "bpcadmin" angehören und bisher nur das Recht "webtsm_admin" hatten, nun statt dessen das Recht "webtsm_edit". Einem Timeseries Management Administrator könnte - anstatt dem spezifischen Recht - auch die Rolle "WEBTSM_ADMIN" zugewiesen werden. Dies wäre auch gleich Zukunftssicherer, wenn z.B. in Folgeversionen bei den Endpunkten - anstatt dem Recht "webtsm_edit" fein granulare Rechte festgelegt werden.

Das Data Management Modul hat keine eigenständige Backend-Komponente (bpc-be-vam.jar) mehr. Die muss beim Update entfernt werden. Für die Verwendung des Moduls reicht die Verwendung von bpc-fe-vam.war aus.

Das Data Management Modul wurde in den regulären Releasezyklus mit aufgenommen.

Das Setting baseUrl entfällt, da der Wert (cxf) ein statischer Teil der API URL ist und nicht geändert wird.

Nicht zu verwechseln, mit bpcBaseUrl. Dieses Setting bleibt unverändert bestehen.

Das Format für Index-Imports wurde auf ein ZIP-basiertes Format geändert. Dies ist dasselbe Format das auch unser opensearch-tool zum Importieren und Exportieren von Indizes erzeugt. In der Administrationsoberfläche unter Core Services → Indizes können solche Index-Export-Dateien heruntergeladen werden.

Achtung: Sollten Sie die Index-Import-Funktionalität für eine Installation mit vorkonfiguriertem BPC verwenden, muss die Export-Datei neu erstellt werden.

Siehe auch Installation mit vorkonfiguriertem BPC.

Dateien im File-Storage können neben einem direkten Upload nun auch über eine Referenz zu einer Datei im Cloud-Storage-Provider erstellt werden. Dafür wird ein neuer Endpunkt in der File-Storage API angeboten. Im Log-Service können Dateien (bei Feldern vom Typ file-storage) auch als Dateireferenz zum Cloud-Storage-Provider übermittelt werden.

Darüber hinaus wird beim Upload und Download bei allen unterstützten Cloud-Providern der Content-Typ gesetzt.

File-Storage-Backend Connections können nun so konfiguriert werden, dass Downloads über das BPC geleitet werden. Siehe core:/admin/modules/backend_connections.adoc#file_storage. Downloads über den File-Storage-Service werden nun im Audit-Log dokumentiert.

Die File-Storage Log-Service-Integration wurde für den Process-Monitor angepasst, sodass dieser diese Dateien als Download und zur Ansicht anbieten kann: Dafür wird im Log-Service für Felder vom Typ file-storage beim Logging in OpenSearch und relationale Datenbanken zwei weitere Felder mit dem suffix _filename und _contentType erstellt.

Im Process-Monitor können jetzt auch Dateien aus dem File-Storage bezogen werden.

Das Format für Index-Imports wurde auf ein ZIP-basiertes Format geändert. Dies ist dasselbe Format das auch unser opensearch-tool zum Importieren und Exportieren von Indizes erzeugt. In der Administrationsoberfläche unter Core Services → Indizes können solche Index-Export-Dateien heruntergeladen werden.

Achtung: Sollten Sie die Index-Import-Funktionalität für eine Installation mit vorkonfiguriertem BPC verwenden, muss die Export-Datei neu erstellt werden.

Siehe auch Installation mit vorkonfiguriertem BPC.

Über die WebTSM Einstellung module_apis können zusätzliche HTTP Header definiert werden, welche dann bei jedem WebTSM API Aufruf gesetzt werden. Dazu das Feld additionalHttpHeaders mit den zu setzenden HTTP Header aufnehmen (siehe Beispiel). Als Variablen, wie das unten stehende ${config.de.virtimo.bpc.core.karaf.uuid}, können die Gleichen wie beim BPC HTTP Proxy gesetzt werden.

Die Konfiguration von Dateianhängen und Download im BPC-Monitor wurde umstrukturiert:

Weitere Informationen können hier nachgelesen werden: Konfiguration der Monitor-Spalten und Dateianhänge.

Achtung: Monitorinstanzen hatten die Einstellung column_mimetype zum Festlegen des Spaltennamens bereitgestellt, welcher auf den Content-Typ der Dateien verweist. Im Backend wurde jedoch inkonsistent der Spaltenname contentType verwendet. Deshalb wurde bei der Migration der Instanzen die Einstellung column_mimetype ignoriert. Falls diese verwendet wurde, überprüfen Sie bitte die entsprechende Monitor-Instanz und passen Sie diese ggf. an.

Sharing-Links für Monitor Prozesse wurden gekürzt. Der Link enthält nur noch Informationen über die aktive Ansicht, die Filter und Sorter.

Formularversionen und Formulare können jetzt im Forms Repository gelöscht werden.

disabled und readOnly ist verfügbar für Tabellenspalten. disabled, readOnly und required werden bei Gruppen Komponenten nur noch zur Konfiguration vererbt. Attribute werden dabei nicht überschrieben.

In den Monitoreinstellungen kann man nun die initiale Sortierreihenfolge für Gruppen konfigurieren. Siehe Einstellung column_groupDirection

Daten, die bei OIDC-Providern für den Login verwendet werden, werden in einem Cookie verschlüsselt beim Client hinterlegt. Dadurch wird eine Auslastung durch sehr viele Login-Anfragen verhindert.

Für BPC-Modulentwickler

Sollten Sie eine eigene UserFlowIdentityProvider-Implementierung entwickelt haben, müssen Sie diese anpassen. Die Funktion URI createAuthenticationRequestURI(String requestUrl) wurde mit UserFlowLoginContext createAuthenticationRequestContext(String requestUrl) ersetzt und gibt neben der Redirect-URL zum OIDC-Login nun auch einen Cookie, welcher den Login-State enthält, zurück. Dieser Cookie wird beim Login-Versuch vom Frontend gesetzt.

Für BPC-Administratoren

Installieren Sie die neuen Module bpc-be-core.jar und bpc-fe-core.war. Ein Neustart des BPCs/Karaf ist notwendig. Sollte das BPC dann immer noch nicht zur Verfügung stehen, löschen Sie bitte das Verzeichnis karaf/data und starten sie den Karaf erneut. (Evtl. machen Sie davor ein Backup Ihrer Log-Files)

Nur das WebTSM Backend kommuniziert direkt mit Hakom. Das WebTSM Frontend nur noch mit dem WebTSM Backend. Das bedeutet, dass keine Backend Connection vom Typ "HTTP Proxy" mehr notwendig und die Einstellung "tsm_backendConnectionId" bei den WebTSM Viewer Komponenten entfallen ist.

Wenn beim Prozessstatuswechsel "useRendererValues" true ist, werden in der Status-Combobox nicht mehr die Fallback Werte "" und "*" angezeigt.

Im Process-Monitoring wurden die Einstellungen inubit_referenceEndpoint, inubit_proxyId, inutbit_baseUrl zum Download über einen HTTP-Proxy zusammengeführt und in httpProxy_referenceEndpoint umbenannt, so dass die Möglichkeit eines Downloads über eine generische HTTP-Proxy-Verbindung verdeutlicht wird. Die Einstellung inubit_dbTablePrefix wurde entfernt, da sie nur für Legacy-Szenarien verwendet wurde.

Mehrsprachigkeit wurde verbessert. Die Sprachen cs, da, de, en, es, fi, fr, it, js, ko, nl, pt, ru entsprechend der ISO 639-1 Sprachcodes sind nun verfügbar. Falls eine Sprache nicht verfügbar ist oder unvollständig, wird auf Englisch zurückgegeriffen.

Bitte in der Timeseries Management JSON Einstellung Allgemein → module_apis die Werte mit dem Key "authorization" entfernen. Dieser Wert beinhaltet den Benutzername und Passwort im Klartext (Base64 encoded) und wird nicht mehr benötigt.

Timeseries Management Administratoren brauchen, wenn sie nicht der Rolle "bpcadmin" angehören und bisher nur das Recht "webtsm_admin" hatten, nun statt dessen das Recht "webtsm_edit". Einem Timeseries Management Administrator könnte - anstatt dem spezifischen Recht - auch die Rolle "WEBTSM_ADMIN" zugewiesen werden. Dies wäre auch gleich Zukunftssicherer, wenn z.B. in Folgeversionen bei den Endpunkten - anstatt dem Recht "webtsm_edit" fein granulare Rechte festgelegt werden.

Durch diese Änderung können Tabellen in der GUI besser automatisiert getestet werden.

Das Setting baseUrl entfällt, da der Wert (cxf) ein statischer Teil der API URL ist und nicht geändert wird.

Nicht zu verwechseln, mit bpcBaseUrl. Dieses Setting bleibt unverändert bestehen.

Doppelte Setting-Gruppen werden zu einer Gruppe gemerged

Falls in einer Monitor-Instanz mehrere Spalten konfiguriert sind, die den selben dataIndex verwenden, aber durch Custom-Renderer unterschiedlich dargestellt werden, wird dies jetzt beim Export korrekt berücksichtigt. Außerdem werden beim Export Mappings für leere Werte und Fallback-Werte in Custom-Renderern berücksichtigt. (Einträge "!" und "*")

Fehler in der Schemagenerierung von einigen DTO-Klassen wurde behoben.

Bei einem Monitor-Export von Child-Daten wird die data_filter-Einstellung auf die dazugehörigen Parent-Einträge angewendet.

Das Filtern auf die Spalte ist nun wieder möglich. Es wurde auch eine zusätzliche Option eingefügt, für den Filter ein abweichendes Template zu setzen. Dies kann nötig sein, wenn das Spalten-Template auf andere Felder als das in dataIndex angegebene zugreift.

Siehe auch Konfiguration der Monitor-Spalten

targetModule wird in der viewConfiguration automatisch zu einem String umgewandelt

Absicherung von BpcCommon.Api.getTranslation: Falls eine Übersetzung fälschlich ein Objekt liefert (z. B. bei config), wird nun auf den Schlüsselstring zurückgefallen, um [object Object] zu vermeiden.

Beim Prozessstatuswechsel kann jetzt auch "preselectState": "_first", wenn "useDistinctValues" false ist und custom States verwendet werden. Siehe auch Prozessstatuswechsel Konfiguration

Das Spacing Problemen von Checkboxen innerhalb einer Checkboxgroup wurde behoben.

Zuvor wurden nur Spalten in den Child-Daten exportiert, für die es auch Spalten im Parent-Monitor gibt, die einen gleichnamigen dataIndex verwenden.

Ein Export im Process-Monitor funktioniert jetzt, auch wenn instance_data_view_limit bzw. monitor_data_view_limit kleiner als 2500 ist.

Die Dokumentation zum Binding in Forms wurde erweitert.

Siehe:

Siehe Status Wechsel - Syntax

Aktualisieren Sie OpenSearch entsprechend der Updateanleitung

Mit diesem Update wird die Version von Apache Karaf auf 4.4.10 angehoben. In diesem Zusammenhang ist es erforderlich, die folgenden Module zu aktualisieren: bpc-be-core, bpc-be-analysis, bpc-be-forms und bpc-be-monitor.

Bitte aktualisieren Sie Karaf gemäß der Updateanleitung.

Anpassung der Logging-Konfiguration

Die Konfigurationsdatei etc/org.ops4j.pax.logging.cfg wurde im Zuge eines Log4J-Updates angepasst. Wichtig: Übernehmen Sie diese Datei nicht unverändert aus einer bestehenden (alten) Karaf-Installation. Falls Sie individuelle Anpassungen vorgenommen haben, übertragen Sie diese bitte manuell in die neue Konfigurationsdatei.

Hinweis für BPC Modul-Entwickler

Wenn in Ihrem BPC-Backend-Modul die Abhängigkeit jackson-annotations verwendet wird und dabei bislang die Variable ${jackson.version} genutzt wurde (um die gleiche Version wie in den BPC-Core-Modulen zu referenzieren), ist dies anzupassen. Verwenden Sie stattdessen ${jackson.annotations.version}.

Das Data Management Modul hat keine eigenständige Backend-Komponente (bpc-be-vam.jar) mehr. Die muss beim Update entfernt werden. Für die Verwendung des Moduls reicht die Verwendung von bpc-fe-vam.war aus.

Das Data Management Modul wurde in den regulären Releasezyklus mit aufgenommen.

Die URL zu Flow-Endpunkten kann direkt aus dem Flow Manager in die Zwischenablage kopiert und bspw. für Forms submit URLs weiterverwendet werden.

Das Plugin prometheus-exporter wird nun standardmäßig mit OpenSearch ausgeliefert.

Die BPC-API bietet nun auch eine Authentifizierung über Access-Tokens an, welche vom konfigurierten OIDC-Provider ausgestellt wurden. Die Authentifizierung über Access-Token muss explizit in der Identity Provider Konfiguration aktiviert sein. Wahlweise kann neben der Validierung der Signatur und Gültigkeit des Access-Tokens auch der Introspection-Endpunkt des OIDC-Providers verwendet werden, der zusätzlich überprüft, ob die Session beendet wurde (Token Revocation). Weitere Informationen können hier nachgelesen werden: Access-Tokens und Keycloak als Identity Provider.

Im Frontend wird vor dem Wechsel zu einer neuen Ansicht (Modul bzw. Modulkomponente) der globale Event beforeShowModule gefeuert. Als Parameter werden übergeben: Modul-ID der aktuellen Ansicht, Modul-ID der neu anzuzeigenden Ansicht und weitere Optionen. Wenn ein Event-Listener false zurück gibt, dann wird der Wechsel zur neuen Ansicht abgebrochen. Sollte dieses Verhalten angewendet werden, dann sollte der Benutzer auch eine Rückmeldung erhalten, warum der Wechsel abgebrochen wurde.

Seit BPC 4.2.13 und 4.1.25 wurden Prozess Aktionen in Child Grids nicht mehr angezeigt. Das wurde behoben und Prozess Starter werden nicht mehr fälschlicherweise im Child Grid angezeigt.

Das in BPC 4.2.16 und 5.0.2 eingeführte Verhalten, dass in der Backend Connection die Verbindung explizit geschlossen wird, führte teilweise zu Problemen, bei denen Antworten vom Server nicht oder nur unvollständig übertragen wurden.

BPC Breadcrumb Plugin wird wieder angezeigt

Im Forms Live-Editor gibt es nun eine KI-Unterstützung beim Erzeugen von Forms. Die Unterstützung wird in folgenden Releases an weiteren Stellen angeboten werden.

Für die Nutzung des KI-Assistenten fügen Sie bitte das Plugin z.B. zu ihrer Application Toolbar hinzu.

Siehe auch: KI-Assistent KI-Assistent Rio Virtimo KI-Services Generierung von BPC Forms (AI Generation)

Der BPC File-Storage-Service unterstützt neben AWS S3 jetzt auch Azure Blob Storage und Google Cloud Storage.

Um die File-Storage-Funktionalität zu nutzen, ist es erforderlich, dass das entsprechende Modul für den jeweiligen Cloud-Provider installiert ist, siehe File-Storage-Module. (Dies ist auch dann erforderlich, wenn zuvor File-Storage mit AWS S3 genutzt wurde.) Falls File-Storage mit AWS S3 schon verwendet wird, muss entsprechend auch das AWS S3 File-Storage-Module installiert werden.

Es wurde ein Security-Check eingeführt, der für die bpcBaseUrl-Einstellung prüft, dass HTTPS verwendet wird.

Es ist nun möglich am HTTP-Proxy zusätzliche Header zu hinterlegen, die mit zum Server gesendet werden.

Analog zum Import von Moduleinstellungen bieten wir nun die Möglichkeit, vorkonfigurierte OpenSearch-Indizes zu importieren, siehe Installation mit vorkonfiguriertem BPC.

Es steht ein Kommandozeilentool zur Auflistung, Löschung sowie zum Export/Import von Indices zur Verfügung. Es heisst bpc-opensearch-tool.jar und kann vom Fileserver (https://files.virtimo.net/bpc/) geladen werden. Per java -jar bpc-opensearch-tool.jar --help wird die Hilfe aufgerufen.

Beim Erstellen einer Logservice-Instanz ist jetzt in der Standardkonfiguration das Feld External Reference vorhanden. Des Weiteren wurden die Feldtypen object und flat_object hinzugefügt.

Es wurde ein Security-Check eingeführt, der prüft, dass BPC nur über HTTPS erreichbar ist.

Die ausgelieferte Konfigurationsdatei de.virtimo.bpc.core.security.checks.cfg enthält korrigierte und an aktuelle Checks angepasste Voreinstellungen.

Tooltips mit URL-Links können mit dem Cursor erreicht werden, ohne dass diese verschwinden.

Beim Erstellen einer Monitorinstanz ist jetzt per Default der Export im JSON Format aktiviert und steht somit zur Auswahl im Monitor Export Fenster

Behebung eines potenziellen DoS-Angriffs, der bei sehr vielen parallelen Log-In-Aufrufen zu hohem Speicherverbrauch führt.

Das konfigurierte Limit (Max. Anzahl Datensätze) für XLSX wird beim Daten Export im Monitor wieder berücksichtigt. Für CSV und JSON kann jetzt auch ein Limit in der Export-Maske konfiguriert werden. Eine Obergrenze gibt es nur für XLSX, nicht für andere Dateiformate.
Siehe auch Konfiguration des Monitor-Daten-Exports
Export von Prozessen

Beim Export von Monitor-Daten mit konfigurierten Custom-Renderern wurden folgende Fehler behoben: - Custom-Renderer wurden nur auf Daten vom Typ String angewandt. Jetzt werden Custom-Renderer beim Exportieren auch auf die Typen Integer, Long und Boolean angewandt. - Für eine Spalte kann man als Custom-Renderer den Wert true setzen. In diesem Fall wird ein zum dataIndex gleichnamiger Custom-Renderer verwendet. Falls dieser nicht existiert, wird auf der Custom-Renderer "defaultRenderer" verwendet. Beim Export wurde in diesem Fall nur "defaultRenderer" verwendet. Dies wurde behoben.

Bei GUI-Modulen, die Typen anbieten, können wieder Komponenten mit Typen angelegt werden. Übersetzungen für die Bezeichnung eines Typs erfordern keinen "CORE_" Präfix mehr. Das Schema für die Übersetzungsschlüssel ist "<MODULID>_INSTANCE_TYPE_<WERT>".

Behebung einer Exception beim Konfigurations-Update, wenn das Security Cockpit noch nicht geöffnet war.

Security-Check-Messungen erfassen nun wieder einen Timestamp.

Der HttpProxySecurityCheck wird pro Instanz nur einmal ausgeführt.

Die Default-Instanzen im Analysis-Modul werden jetzt korrekt initialisiert, sodass der Datenmodifikator direkt verfügbar ist.

Eine fehlerhafte Pluginkonfiguration wird nun während der Migration ignoriert und als Warnung geloggt.

Ausführliche Dokumentation der Prozessstatuswechsel-Konfiguration. Siehe Prozessstatuswechsel

Siehe Konfiguration des Monitor-Daten-Exports

Die Dokumentation von Formattern in Spalten und Formattern im Export wurde verbessert.

Die Listen der jeweiligen Modul-Einstellungen wurden überarbeitet bzw. werden nun automatisch generiert. So sind die Bezeichner und Beschreibungstexte identisch mit der GUI. Siehe Konfiguration von Data Analysis Core Services Einstellungen Konfiguration des Process Dashboards Konfiguration von Forms Konfiguration des Process Monitorings

Siehe Chart-Editor

Der Abschnitt "Benutzer" in der Dokumentationsseite "BPC Administration" wird ausführlicher beschrieben. Siehe BPC Administration

Erweiterte Beschreibung der Prozess-Aktions-Konfiguration. Siehe Konfiguration von Prozessaktionen

Die HTTP Proxy Konfigurationen überprüfen und ggf. anpassen. Bisher wurde an die konfigurierte Verbindungs-URL immer ein '/' angehängt. Dies ist nun nicht mehr der Fall. Falls ihr HTTP Proxy Ziel dies benötigt und die URL derzeit ohne '/' am Ende konfiguriert ist, dann passen Sie dieses bitte an.

Es wurden zwei neue Plugins hinzugefügt, um auf interne oder externe Inhalte zu verlinken. Siehe auch External Link und Internal Link

Im Frontend gibt es jetzt die Möglichkeit, für Replikationsjobs einen Tail-Sync manuell zu starten. Darüber hinaus lässt sich ein manueller Tail-Sync auch über die REST-API starten, siehe Replication API.

BPC unterstützt nun PKCE (Proof Key for Code Exchange) für OpenID-Connect und Keycloak Identity Provider um einen gehärteten Login-Flow zu ermöglichen. Um dies zu aktivieren, müssen Sie an der Identity-Provider Backend-Connection die PKCE-Methode einstellen und dies ggf. in Ihrem Keycloak-Client konfigurieren.

Tail Sync durchläufe können nun protokolliert werden. Bei aktiviertem Logging wird dazu in den Index bpc-tailsync-log geschrieben. Zusätzlich wird der Monitor Tail Sync Log Monitor angelegt. Mehr dazu können Sie unter Replikation nachlesen.

Die Markierung von Einstellungen, die vom Default abweichende Werte haben, wurde geändert.

Beim Formular zum Versenden von Benachrichtigungen ist die Rolle bpcuser als Empfängergruppe vorausgewählt. Ein Absenden einer Benachrichtigung ohne jegliche Empfängergruppe ist nicht mehr möglich.

Beim Reindizieren wird der alte Index gelöscht, anstatt wie bisher geschlossen. Dem Nutzer wird angeboten, vor dem Reindizieren ein Backup zu erstellen.

Die Werte der verschiedenen Optionen in Comboboxen werden nun nicht mehr pauschal durch ein   ergänzt. Dies erleichtert das automatisierte Testen der Oberflächen.

Code, der als deprecated markiert war, wurde aus BPC entfernt.

Der über pax-jdbc-mssql bereitgestellt Treiber wird nicht mehr mit ausgeliefert.

Es ist darauf zu achten, dass der verwendete MSSQL Treiber mindestens folgende Version hat: 10.2.4, 11.2.4, 12.2.1, 12.6.5, 12.8.2, 12.10.2, 13.2.1

Falls ein älterer Treiber verwendet wird, dann sollte dieser ersetzt werden. Entfernen Sie den alten Treiber durch Entfernen aus dem Deploy-Verzeichnis oder Deinstallieren von pax-jdbc-mssql bzw. des Treibers. Anschließend einen aktuellen Treiber installieren (ohne das Feature pax-jdbc-mssql). Siehe dazu: Datenbanken

Ein Bug wurde behoben, bei dem ein falscher Prozess Starter angezeigt wurde, wenn genau zwei Prozess Starter konfiguriert wurden, wovon einer hidden ist.

Die HTTP Proxy Konfigurationen überprüfen und ggf. anpassen. Bisher wurde an die konfigurierte Verbindungs-URL immer ein '/' angehängt. Dies ist nun nicht mehr der Fall. Falls ihr HTTP Proxy Ziel dies benötigt und die URL derzeit ohne '/' am Ende konfiguriert ist, dann passen Sie dieses bitte an.

Tritt bei der Migration eines Index ein Fehler auf, so wird der für die Migration neu angelegte Index wieder entfernt, um Folgefehler zu vermeiden bzw. wieder auf einen stabilen Stand zurückzufallen.

Buttons, die lokale Änderungen verwerfen, haben jetzt eine bessere Textbeschreibung.

Änderungen vom gültigen Wertebereich wirken sich direkt auf die Validierung des Standardwertes aus.

In der Konfigurationsdatei muss der Wert für deleteCheckResultsOlderThan von 10 days auf 10 days ago geändert werden.

Standardmäßig wird ab sofort die Erreichbarkeit des Karafs über SSH-Verbindungen auf den Host localhost eingeschränkt. Um eine Erreichbarkeit über externe Verbindungen zu ermöglichen, nutzen Sie die zentrale Konfigurationsdatei. Siehe Karaf SSH Zugriff.

Die Verbindungen zu OpenSearch werden nun ausschließlich über de.virtimo.bpc.core.opensearch.hosts konfiguriert. Bei einem Update von einer älteren Version müssen Sie in der Konfigurationsdatei karaf/etc/de.virtimo.bpc.core.cfg den Eintrag de.virtimo.bpc.core.opensearch.hosts ergänzen. Zusätzlich empfiehlt es sich, die zentrale Konfigurationsdatei mit den Zeilen

bzw.

zu ergänzen (hier am Beispiel https://localhost:9200). Sie können sich hier an den Dateien aus dem Download-File-Server orientieren.

Der Einsatz von Java 21 ist nun notwendig.

Diese Metriken wurden umbenannt:

INUBIT wird nicht mehr als Identity Provider unterstützt.

Bei den Identity Provider (Backend Connections) wurde bisher einer großer Teil über ein JSON Setting konfiguriert. Dieses wurde in einzelne Settings aufgesplittet. Bestehende Konfigurationen werden automatisch migriert. Kommen ältere Deployment Exporte von Identity Provider Komponenten zum Einsatz, dann sind diese am besten neu zu erstellen.

Siehe auch: Identity Provider anlegen, konfigurieren und verwenden, Datenbank als Identity Provider, Keycloak als Identity Provider, Keycloak und dynamische Redirect URIs, Deployment Constraints

Der Endpunkt /cxf/bpc-core/status/server/{serverUUID} der Status-API, der den Status eines remote-BPCs abfragte, wurde entfernt.

Die Query String Parameter gridId, gridExtId, multiRecords, buttonId und der Form Parameter tablePrefix wurden aus den Prozess Aktion Anfragen entfernt. Um zusätzliche Kontext- oder Konfigurationsinformationen mitzusenden, kann "Prozessaktions-Metadaten" in den Monitor-Einstellungen konfiguriert werden.

In Prozessstartern wurde das mitgesendete XML durch JSON ersetzt. Dadurch wurden portletArchiveName, operation, mandant, gridID, key, bpcModule, bpcModuleInstanceId und custom entfernt. key wurde einheitlich zu id umbenannt. Zusätzliche Kontext- oder Konfigurationsinformationen können durch die "metadata" Konfiguration in der Prozessstarter-Konfiguration in den Monitor-Einstellungen zuverlässig mitgesendet werden. Die Prozessparameter sind gebündelt unter config.parameters im Request Payload zu finden. Fileuploads enthalten filename, type und data. Grids enthalten eine Liste mit ihren Records.

Bei Change State wurden tablePrefix, mandant und changeStatusBox_<Spaltenname> entfernt. command wurde einheitlich umbenannt zu type und erhält den Wert "statusChange". columnsstring wurde umbenannt zu column. newStatusCombo_<Spaltenname> wurde umbenannt zu newStatus. commentfield wurde umbenannt zu comment. childStatus wird nicht mehr per Default in der Change State Konfiguration auf "Info" gesetzt und wird, falls konfiguriert, nach metadata migriert. Im "metadata" Objekt in der Change State Konfiguration können zusätzliche Informationen übergeben werden.

Siehe auch Migration von BPC 4.* auf BPC 5.0 Konfiguration von Prozessaktionen Prozess Starter

Die ungenutzten Einstellungen inubit_aperakEndPoint, inubit_dbGridId und inubit_pmMandant wurden entfernt. Die Einstellungen inubit_actionEndpoint, inubit_changeStateEndpoint und inubit_VpsEndpoint wurden durch actionEndpointProcessor, changeStateEndpointProcessor und vpsEndpointProcessor ersetzt.

HTTP-Proxy Backend-Connections und Flow-Verbindungen filtern jetzt stets den Session-Cookie, damit ein Empfänger nicht im Kontext des Benutzers Aufrufe im BPC tätigen kann. Die Einstellung filterSessionCookie entfällt somit. Stattdessen gibt es mit der neuen Einstellung sendSessionId die Möglichkeit, die Session-ID des Benutzers mitzuschicken, welche am Endpunkt GET /cxf/bpc-core/authentication/session/{sessionid} überprüft werden kann. Bei aktivierter Einstellung injectUserSessionJWT wird nun nicht mehr ein selbst-erstellter JWT mitgeschickt, sondern der signierte ID-Token des OpenID Connect Providers gesendet. Genaueres können Sie in Backend Connections - HTTP-Proxy nachlesen.

Http-Calls über eine Http-Proxy oder Flow Verbindung filtern den BPC Api-Key-Header (X-APIKey) heraus. Achtung: Dies könnte Einfluss auf bestehende BPC Konfigurationen haben, wenn zum Beispiel ein INUBIT-Prozess angestoßen wird, der mit dem mitgesandten API-Key wiederum Aufrufe in der BPC-Api macht. (Hier wäre es besser, einen festen BPC-API-Key im INUBIT-Prozess zu hinterlegen.)

Benutzer der Log Service API müssen in ihren POST-Daten alle Vorkommen von childs durch children ersetzen. Innerhalb einer Übergangszeit kann childs eingehend noch verwendet werden. Diese Rückwärtskompatibilität wird in einem folgenden Release entfernt. Auch ist darauf zu achten, dass in den Rückantworten der Log Service Endpunkte nun children anstatt childs enthalten ist.

Das OpenSearch-Konfigurationsverzeichnis lässt sich über OPENSEARCH_PATH_CONF konfigurieren. Damit können Sie das Konfigurationsverzeichnis aus dem OpenSearch-Verzeichnis auslagern. Dadurch überschreiben Sie dieses nicht mehr bei einem OpenSearch-Update. Siehe auch OpenSearch-Konfiguration auslagern.

In der Bundle-Installationsdatei wird BPC jetzt mit einem nach INSTALLATIONSVERZEICHNIS/opensearch_config ausgelagertem Konfigurationsverzeichnis ausgeliefert.

Es wird empfohlen OPENSEARCH_PATH_CONF in der bpc.env zu setzen.

Es wurde ein neuer Aktions-Typ "bulkAction" hinzugefügt, um Aktionen für alle Datensätze ausführen zu können. Siehe Mehrfach-Aktionen

Wird IGUASU korrekt über das Flow-Modul angebunden, können verfügbare Prozessoren einfach über die Konfigurations-Oberfläche der Monitor Aktionen ausgewählt werden.

Es steht nun eine Konfigurationsoberfläche für Identity Provider zur Verfügung.

Mit diesem Update ist es erforderlich, den Karaf zu aktualisieren.

Das BPC stellt OpenApi-konforme Spezifikationsdateien für unsere APIs bereit. Diese befinden sich unter Downloads und können alternativ auch dynamisch über das BPC aufgerufen werden, sofern diese Option aktiviert ist. Mehr Informationen finden Sie im Abschnitt BPC-API.

Es wird im Administrationsbereich nun ein Security Cockpit angeboten, dass einen Überblick über die Applikationssicherheit bietet.

Details siehe Security-Cockpit

Ein neuer API-Endpunkt /cxf/bpc-core/collaboration/online-users bietet die Möglichkeit, alle angemeldeten Benutzer aufzurufen. (Siehe Collaboration API). Ein neues Plugin "List Online Users" ermöglicht, im Frontend alle angemeldeten Benutzer anzuzeigen. (Siehe Online User List))

Es wurde ein Chat-Plugin hinzugefügt. Der Chat ist zustandslos, sodass die Nachrichten bei Abmeldung, Neuladen oder Schließen der Seite verloren gehen. Neue Nachrichten erhält man nur, während man angemeldet ist. Siehe auch Chat

Man kann sich über die Log Service API direkt in die Log Service Konfiguration oder zu angebundene Monitore weiterleiten zu lassen. Dazu gibt es gibt zwei neue LogService Endpunkte, welche den Benutzer beim Aufruf auf die entsprechenden BPC Seiten weiterleiten:

Siehe auch API Dokumentation: Log Service API

Es ist nun möglich beim Schreiben von Audit-Informationen Referenzen auf externe Ressourcen anzugeben. So kann zum Beispiel auf die IGUASU-Instanz verwiesen werden, die den Eintrag erzeugt hat.

Die Replikation unterstützt jetzt alternativ zu bestehenden Datenbank-Tabellen/Views auch die direkte Eingabe einer SQL-Query.

Siehe auch sourceCommonTableExpressionQuery in Replication

Es kann nun über die Log Service API ein JSON Schema angefordert werden, dass den Payload für den Log Service beschreibt. Dies kann genutzt werden, um vorab eine Validierung durchzuführen.

Es wurde ein neues Setting hinzugefügt, mit dem sich die Endpunkte bzw. Prozessoren von Flow & Backend Connections auswählen lassen. Die Auswahl generiert eine BPC URL nach dem Schema bpc://<flow/backendconnection>/<instanceId>/<endpointOrProcessor>. Es gibt jeweils Settings für Prozess Aktionen, Prozess Starter und Change State.

Nachrichten können an einzelne Nutzer gesendet werden. Nachrichten können zeitlich beschränkt werden. Nachrichten können ein Thema setzen. Es ist möglich, alle Nachrichten eines einzelnen Themas zu löschen. Der Status, ob eine Nachricht gelesen ist, wird nun im Backend persistiert, anstatt im Localstorage des Browsers hinterlegt zu werden.

Siehe auch Benachrichtigungen an Anwender und Notification API für Änderungen an der API.

Die Backend-Connections werden um einen 'file_storage'-Typen erweitert, um Verbindungen zu AWS-S3 und S3-kompatiblen Dateispeichern zu konfigurieren.

Es wird eine File-Storage API zur Verfügung gestellt, die das Hochladen, Herunterladen und Verwalten von Dateien ermöglicht. Diese werden auf einem durch eine File-Storage-Backendconnection konfigurierten Dateispeicher abgelegt.

Siehe File-Storage API.

Unter Einstellungen→Übersicht→File Storage wird ein UI bereitgestellt, um Dateien des File-Storages anzuzeigen, herunterzuladen und zu löschen. Zusätzlich können Dateien in das File-Storage hochgeladen werden.

File-Storage-Integration in den Log-Service

Weiteres kann in File-Storage im Log-Service nachgelesen werden.

Im Frontend ist eine Weiterleitung über den Query-Parameter redirectPostAuth an eine BPC-URL nach dem Login-Vorgang möglich. Dies funktioniert für alle OIDC-Identity-Provider.

Ergebnisse aus der Validierung werden nun im state vorgehalten. Dadurch können diese z.B. auch für Bindungs verwendet werden. Siehe auch validate

Es wurde ein neues Setting hinzugefügt, mit dem sich die Endpunkte bzw. Prozessoren von Flow & Backend Connections auswählen lassen. Die Auswahl generiert eine BPC URL nach dem Schema bpc://<flow/backendconnection>/<instanceId>/<endpointOrProcessor>. Es gibt jeweils Settings für Prozess Aktionen, Prozess Starter und Change State. Die URL wird beim POST Request einheitlich immer mit im Payload an den httpProxy Endpunkt des Monitors übergeben. Der Monitor Endpunkt nutzt den Core Action Service, um die Daten weiterzuverarbeiten und gibt letztlich die Response zurück.

BPC-API-Anfragen, die durch einen Webbrowser stattfinden, leiten bei fehlender Authentifizierung nun auf den Keycloak (oder einen anderen OIDC UserFlowIdentityProvider) um. Nach dem Login findet eine Weiterleitung auf den ursprünglichen API-Endpunkt statt.

API Keys werden jetzt im Frontend, genauso wie Passwörter, maskiert. Beim Auslesen vorhandener API Keys in Einstellungen wird statt dem API Key nun angezeigt.

Wird ein neuer API Key erstellt, wird dieser einmalig angezeigt.

Siehe System Monitoring (Metriken für Prometheus)

Unterschreitet der freie Plattenplatz definierte Schwellwerte, so werden Shards auf andere Knoten verteilt. Es kann auch vorkommen, dass Indices auf read-only gesetzt werden, um ein voll laufen der Platte zu vermeiden.

Der Wert von cluster.routing.allocation.disk.threshold_enabled ist nun true. Dies entspricht dem OpenSearch Standardwert.

Das OpenSearch-Konfigurationsverzeichnis lässt sich über OPENSEARCH_PATH_CONF konfigurieren. Damit können Sie das Konfigurationsverzeichnis aus dem OpenSearch-Verzeichnis auslagern. Dadurch überschreiben Sie dieses nicht mehr bei einem OpenSearch-Update. Siehe auch OpenSearch-Konfiguration auslagern.

In der Bundle-Installationsdatei wird BPC jetzt mit einem nach INSTALLATIONSVERZEICHNIS/opensearch_config ausgelagertem Konfigurationsverzeichnis ausgeliefert.

Es wird empfohlen OPENSEARCH_PATH_CONF in der bpc.env zu setzen.

Die Verbindungen zu OpenSearch werden nun ausschließlich über de.virtimo.bpc.core.opensearch.hosts konfiguriert. Bei einem Update von einer älteren Version müssen Sie in der Konfigurationsdatei karaf/etc/de.virtimo.bpc.core.cfg den Eintrag de.virtimo.bpc.core.opensearch.hosts ergänzen. Zusätzlich empfiehlt es sich, die zentrale Konfigurationsdatei mit den Zeilen

bzw.

zu ergänzen (hier am Beispiel https://localhost:9200). Sie können sich hier an den Dateien aus dem Download-File-Server orientieren.

Das Setting Common Table Expression Abfrage in der Replikation kann nun in einem Editor bearbeitet werden, der SQL Syntax unterstützt.

Diese Metriken wurden umbenannt:

Das Standardmapping (Mapping von Organisationen, Rollen und Rechten) für Identity Provider wurde so angepasst, dass jeder User (über die Standardrolle bpcuser) das Recht bekommt alle Standard-Module des BPC zu verwendet. Außerdem wird das Recht gegeben die Liste von angemeldeten Benutzern zu sehen.

Diese Änderung wirkt sich nicht auf bestehende Konfigurationen aus.

Bei den Identity Provider (Backend Connections) wurde bisher einer großer Teil über ein JSON Setting konfiguriert. Dieses wurde in einzelne Settings aufgesplittet. Bestehende Konfigurationen werden automatisch migriert. Kommen ältere Deployment Exporte von Identity Provider Komponenten zum Einsatz, dann sind diese am besten neu zu erstellen.

Siehe auch: Identity Provider anlegen, konfigurieren und verwenden, Datenbank als Identity Provider, Keycloak als Identity Provider, Keycloak und dynamische Redirect URIs, Deployment Constraints

Das Setzen der ID-Spalten in der Logservice-Konfigurationsoberfläche erfolgt jetzt über Comboboxen. Die Konfiguration kann nur noch gespeichert werden, wenn mindestens eine ID-Spalte definiert ist. Zusätzlich wird überprüft, ob alle ID-Spalten in der Feldkonfiguration enthalten sind. Ist dies nicht der Fall, wird das Formular als ungültig markiert und die Speicherung verhindert.

Die im BPC konfigurierten HTTP-Proxys leiten nun auch OPTIONS- und PATCH-Requests weiter.

Für Benachrichtigungen gibt es nicht mehr den Typen 'link', stattdessen können alle Benachrichtigungen nun Verlinkungen angeben. Dafür wird das Feld linkData verwendet (davor typeSpecificData). Für Verweise auf externe Webseiten wird weiterhin das Feld url verwendet, für BPC-interne Navigationen wird nun die Hash-Komponente der BPC-URL im Feld navigation angegeben. Weiteres lesen sie in Benachrichtigungstypen und unter Notification API nach.

In der Benachrichtigungsoberfläche (BPC → Konfiguration → Übersicht → Benachrichtigungen) kann nun auch eine Verlinkung konfiguriert werden (siehe Benachrichtigungen an Anwender).

Der Submit wurde überarbeitet. Hier sind nun einige Änderungen erforderlich. Siehe Migration von BPC 4.* auf BPC 5.0. Die Struktur und die möglichen Aktionen der Nachrichten wurde angepasst.

Der Endpunkt /cxf/bpc-core/status/server/{serverUUID} der Status-API, der den Status eines remote-BPCs abfragte, wurde entfernt.

Das Plugin kann nun einen Prozess konfigurieren, der beim Auslösen direkt angezeigt wird. Außerdem kann der Text und Icon nun frei konfiguriert werden. Siehe auch Prozess Starter Plugin

Die Option für die Gruppierung von Einstellungen ist nun initial aktiviert. Es wird empfohlen diese Ansicht zu verwenden, da die Einstellungen so in einem gemeinsamen Kontext angezeigt werden.

Es gibt nun mehrsprachige Label an Gruppen von Einstellungen.

Log Services können nun einzeln (de)aktiviert werden. Der Begriff Wartungsmodus war in diesem Kontext irreführend.

Die Query String Parameter gridId, gridExtId, multiRecords, buttonId und der Form Parameter tablePrefix wurden aus den Prozess Aktion Anfragen entfernt. Um zusätzliche Kontext- oder Konfigurationsinformationen mitzusenden, kann "Prozessaktions-Metadaten" in den Monitor-Einstellungen konfiguriert werden.

In Prozessstartern wurde das mitgesendete XML durch JSON ersetzt. Dadurch wurden portletArchiveName, operation, mandant, gridID, key, bpcModule, bpcModuleInstanceId und custom entfernt. key wurde einheitlich zu id umbenannt. Zusätzliche Kontext- oder Konfigurationsinformationen können durch die "metadata" Konfiguration in der Prozessstarter-Konfiguration in den Monitor-Einstellungen zuverlässig mitgesendet werden. Die Prozessparameter sind gebündelt unter config.parameters im Request Payload zu finden. Fileuploads enthalten filename, type und data. Grids enthalten eine Liste mit ihren Records.

Bei Change State wurden tablePrefix, mandant und changeStatusBox_<Spaltenname> entfernt. command wurde einheitlich umbenannt zu type und erhält den Wert "statusChange". columnsstring wurde umbenannt zu column. newStatusCombo_<Spaltenname> wurde umbenannt zu newStatus. commentfield wurde umbenannt zu comment. childStatus wird nicht mehr per Default in der Change State Konfiguration auf "Info" gesetzt und wird, falls konfiguriert, nach metadata migriert. Im "metadata" Objekt in der Change State Konfiguration können zusätzliche Informationen übergeben werden.

Siehe auch Migration von BPC 4.* auf BPC 5.0 Konfiguration von Prozessaktionen Prozess Starter

Die ungenutzten Einstellungen inubit_aperakEndPoint, inubit_dbGridId und inubit_pmMandant wurden entfernt. Die Einstellungen inubit_actionEndpoint, inubit_changeStateEndpoint und inubit_VpsEndpoint wurden durch actionEndpointProcessor, changeStateEndpointProcessor und vpsEndpointProcessor ersetzt.

Ein ungültiger JSON-Payload in einem HTTP-Request-Body wird von API-Endpunkten nun mit dem Fehler 400 Bad Request beantwortet.

Die modelVersion wird nun auch angezeigt, wenn der Aufrufer keine Adminrechte hat.

Für das Forms Modul ist eine Migration erforderlich zwischen BPC 4.x und BPC 5. Informationen dazu sind hier zu finden.

Bei booleschen Werten in den Einstellungstabellen wird nun keine Combobox mehr angezeigt, sondern nur noch die Checkbox mit dem Wahrheitswert. Der Wert lässt sich per Klick, Leertaste oder Enter ändern.

Das Aussehen vom BPC wurde aktualisiert.

An Buttons können nun die Klassen arrow-spacing-sm (small) und arrow-spacing-xs (extra small) genutzt werden, um den Abstand des Pfeils zu reduzieren.

Für BPC Modul Entwickler:

Wenn in den Modul-Sourcen eine feature/feature.xml verwendet wird, dann bitte in der pom.xml den folgenden resource-Block entfernen:

Durch diesen Eintrag wurde die feature.xml als Ressource festgelegt und mit in die JAR-Datei eingebettet. Das ist nicht notwendig.

Allerdings muss trotzdem noch das maven-resources-plugin verwendet werden um Platzhalter in der feature.xml zu ersetzen.

Dazu folgendes Plugin-Aufruf hinzufügen:

Für die Migration von Installationen, die bereits Elasticsearch im Einsatz hatten, kann es bei der Umstellung auf OpenSearch 3 nötig sein einen zusätzlichen Migrationsschritt durchzuführen. Dafür wird ein entsprechendes Tool bereitgestellt. Für weitere Details siehe Migration von BPC 4.* auf BPC 5.0

Index Cleanups werden nach dem Start von BPC nach 60 Sekunden durchgeführt, und laufen dann im konfigurierten Intervall.

Es ist nun möglich in der valueMap eines Custom Renderers den Wert 0 zu verwenden und diesen auch als Label im Monitor zu sehen. Zuvor wurden 0 Werte nicht angezeigt.

Das Symbol für den Zugang zu Notifications und Anzeige der Anzahl ungelesener Notifications ist nun ein Plugin. Daher kann dieses nun wie andere Plugins auch an verschiedenen Stellen in der Oberfläche platziert werden.

Bei Benachrichtigungen gibt es nun zusätzlich die Option, die Nachricht nur an eingeloggte Benutzer zu senden. Die Filter nach Rollen und Organisationen sind dabei weiterhin aktiv. Siehe auch Benachrichtigungen. Bei Benachrichtigungen mit Empfängergruppe Benutzer werden die Empfänger nicht mehr angezeigt.

Benutzer der Log Service API müssen in ihren POST-Daten alle Vorkommen von childs durch children ersetzen. Innerhalb einer Übergangszeit kann childs eingehend noch verwendet werden. Diese Rückwärtskompatibilität wird in einem folgenden Release entfernt. Auch ist darauf zu achten, dass in den Rückantworten der Log Service Endpunkte nun children anstatt childs enthalten ist.

Die ungenutzte Einstellung identityProvider_ussUrl wurde entfernt.

An jeder Log Service Komponente kann eine JSON Schema Validierung, der zu schreibenden Daten, aktiviert werden. Voreinstellung ist 'Aus'. Das JSON Schema wird anhand der konfigurierten Keys und Fields automatisch generiert und kann bei Bedarf über den Log Service Endpunkt abgerufen werden.

Beim Event Handling sollte Map anstelle von Dictionary verwendet werden.

Jegliche Pfadangaben werden ignoriert, um Path-Traversal-Angriffe zu vermeiden.

Standardmäßig wird ab sofort die Erreichbarkeit des Karafs über SSH-Verbindungen auf den Host localhost eingeschränkt. Um eine Erreichbarkeit über externe Verbindungen zu ermöglichen, nutzen Sie die zentrale Konfigurationsdatei. Siehe Karaf SSH Zugriff.

Die Logging-Konfiguration wurde geändert, sodass Session-Tokens maskiert werden. Für neue Installationen des Karafs passiert das automatisch. Bei bestehenden Installationen passen Sie bitte die Konfigurationsdatei [KARAF]/etc/org.ops4j.pax.logging.cfg an. Ersetzen sie hier die alte Zeile

mit den Zeilen

Da bei Keycloak und OIDC die Session-Tokens UUIDs sind, die auch an anderen Stellen genutzt werden, loggen wir hier die ersten und letzten vier Zeichen.

HTTP-Proxy Backend-Connections und Flow-Verbindungen filtern jetzt stets den Session-Cookie, damit ein Empfänger nicht im Kontext des Benutzers Aufrufe im BPC tätigen kann. Die Einstellung filterSessionCookie entfällt somit. Stattdessen gibt es mit der neuen Einstellung sendSessionId die Möglichkeit, die Session-ID des Benutzers mitzuschicken, welche am Endpunkt GET /cxf/bpc-core/authentication/session/{sessionid} überprüft werden kann. Bei aktivierter Einstellung injectUserSessionJWT wird nun nicht mehr ein selbst-erstellter JWT mitgeschickt, sondern der signierte ID-Token des OpenID Connect Providers gesendet. Genaueres können Sie in Backend Connections - HTTP-Proxy nachlesen.

Http-Calls über eine Http-Proxy oder Flow Verbindung filtern den BPC Api-Key-Header (X-APIKey) heraus. Achtung: Dies könnte Einfluss auf bestehende BPC Konfigurationen haben, wenn zum Beispiel ein INUBIT-Prozess angestoßen wird, der mit dem mitgesandten API-Key wiederum Aufrufe in der BPC-Api macht. (Hier wäre es besser, einen festen BPC-API-Key im INUBIT-Prozess zu hinterlegen.)

Für neue Backend Connections des Typs HTTP-Proxy und Flow ist die Option BPC Session filtern standardmäßig aktiviert.

Wenn Sie die Datei custom.java.security nutzen, dann sollten Sie das Property jdk.tls.disabledAlgorithms anpassen, um die TLS Konfiguration strikter und damit sicherer zu gestalten.

Anleitung für die Migration von alten Indices bei der Migration auf OpenSearch 3. Siehe dazu Migration von BPC 4.* auf BPC 5.0

Der Einsatz von Java 21 ist nun notwendig.

Falls das BPC initial mit einer OpenSearch anstatt einer Elasticsearch Version installiert wurde, dann kann das [bpc]/opensearch_data Verzeichnis direkt übernommen werden.

Fall nicht, dann müssen zuerst Indices migriert werden.

Siehe dazu Migration von BPC 4.* auf BPC 5.0

Mit diesem Update wird die Karaf-Version auf 4.4.8 aktualisiert. Es ist erforderlich, die Module bpc-be-core, bpc-be-analysis, bpc-be-forms und bpc-be-monitor zu aktualisieren.

Für BPC Modul-Entwickler

Mit dem aktualisierten Karaf liefern wir CXF 3.6.8 statt 3.6.7 aus, welches Jackson in der Version 2.19.2 bereitstellt.

Bitte aktualisieren Sie die CXF-Version (3.6.8) und Jackson-Version (2.19.2) in Ihrer pom.xml. Prüfen Sie dazu, ob Sie eine Import-Package-Anweisung für diese Version haben. Diese muss hinzugefügt oder angepasst werden, wenn Sie Jackson-Funktionen wie die Klasse ObjectMapper verwenden.

Der Core wird nun nicht mehr in alte ECMAScript transpiliert und es werden keine Polyfills mehr hinzugefügt. Damit wird eine Unterstützung neuerer Sprachfeatures ermöglicht. Dies bedeutet, dass auch ExtJS-Packages in ihrer packages/local/PACKAGENAME/package.json folgenden Inhalt haben sollten:

INUBIT wird nicht mehr als Identity Provider unterstützt.

Siehe OpenAPI Spezifikation für Prozess Aktionen, Prozess Starter, Prozessstatuswechsel und Mehrfach-Aktionen

Der Renderer des Forms-Moduls ist nun nicht mehr in bpc-fe-forms enthalten, sondern wird separat als bpc-forms-renderer bereitgestellt. Dadurch ist es nun möglich, den Renderer unabhängig zu aktualisieren. Bei einem BPC Update wird die URL des Renderers am Forms Module automatisch auf bpc-forms-renderer/index.html geändert.

Der Renderer steht über Downloads zur Verfügung.

Der Detailansichten Element-Typ "taskPanel" wurde zusammen mit den zugehörigen Einstellungen function_interactionColumn und function_interactionFormId entfernt.

Für eine Übergangsphase wird noch die Verwendung von childs anstelle von children erlaubt. Dies betrifft nicht die Datenstruktur beim Auslesen von Daten.