Migration von BPC 4.* auf BPC 5.0

Diese Seite beschreibt die Migration einer bestehenden BPC 4-Installation auf BPC 5.

Migration von Indizes für OpenSearch 3.x

Wie bei jedem OpenSearch-Update empfehlen wir dringend, vor dem Update ein Backup der OpenSearch-Indizes zu erstellen.

Sichern Sie hierfür das Verzeichnis INSTALLATIONSVERZEICHNIS/opensearch_data.

Siehe auch Update-Guide für OpenSearch.

Die folgenden Schritte sind erforderlich, wenn in der zu migrierenden Installation ein OpenSearch-System verwendet wird, das Indizes enthält, die ursprünglich mit einer Elasticsearch-Version erstellt wurden. Wir bieten ein Migrationstool an, mit dem alle alten Indizes migriert werden können.

Wenn OpenSearch 3.x mit alten Indizes gestartet wird, kann es passieren, dass einige Indizes auf Version 3.x aktualisiert werden, während alte Elasticsearch-Indizes bestehen bleiben. In diesem Fall startet OpenSearch weder in der Version 2.x noch in der Version 3.x.

Deshalb empfehlen wir, auf jeden Fall ein Backup des opensearch_data-Verzeichnisses zu erstellen und das Migrationstool auszuführen, auch wenn keine Indizes vorhanden sind, die mit Elasticsearch erstellt wurden.

Die Migration der alten Elasticsearch-Indizes wird wie folgt durchgeführt:

  1. OpenSearch mit Version 2.x starten

  2. Das Migrationstool opensearch-migrator.jar herunterladen

  3. In das Download-Verzeichnis wechseln

  4. Sicherstellen, dass sich Java 21 (aus der BPC-Installation) im PATH befindet und JAVA_HOME korrekt gesetzt ist

  5. Das Migrationstool starten, abhängig davon, wie OpenSearch angesprochen wird:

  6. Sollte das Tool beim Ausführen eine Meldung ausgeben, dass System-Indizes oder geschlossene Indizes aus einer alten Version vorhanden sind, sollten diese auch migriert werden (Siehe Warnungen/Konsolenausgaben des Tools). Dafür muss das Migrationstool erneut mit den Argumenten --migrateSystemIndices bzw. --deleteOldClosedIndices ausgeführt werden.

  7. Die Elasticsearch-Indizes sollten ohne Fehler migriert werden

  8. OpenSearch 3.x sollte nun ohne Fehler starten

Je nach Umfang der Indizes kann diese Migration (Reindex von Indizes) von einigen Minuten bis zu mehreren Stunden dauern.

Update der jvm.options bei ausgelagerter OpenSearch-Konfiguration

Sollte die OpenSearch-Konfiguration in ein separates Verzeichnis ausgelagert sein, und nicht im OpenSearch-Verzeichnis im BPC-Installationspfad liegen (INSTALLATIONSVERZEICHNIS/opensearch/config), ist es notwendig, die Datei jvm.options zu aktualisieren. (Siehe auch OpenSearch-Konfiguration auslagern)

Bei neueren Installationen über das mitgelieferte Bundle ist das standardmäßig konfiguriert. Dort ist die Konfiguration nach INSTALLATIONSVERZEICHNIS/opensearch-config ausgelagert.

Eine alte jvm.options-Datei aus einer OpenSearch 2.x Installation führt zu folgendem Fehler:

fatal error in thread [main], exiting
java.lang.NoClassDefFoundError: org/opensearch/javaagent/bootstrap/AgentPolicy$AnyCanExit

In diesem Fall ersetzen Sie bitte die Datei INSTALLATIONSVERZEICHNIS/opensearch-config/jvm.options mit der neuen Datei INSTALLATIONSVERZEICHNIS/opensearch-3.2.x/config/jvm.options.

Manuelle Änderungen, die an der Datei jvm.options gemacht wurden, müssen erneut durchgeführt werden.

Änderung der Aufrufstruktur bei Prozess Aktionen, Prozess Startern und Prozessstatuswechsel

Der Content-Type x-www-form-urlencoded und das XML-basierte Format wurden auf ein einheitliches JSON-Format umgestellt.
Dadurch werden Änderungen in den Backend-Systemen wie INUBIT und IGUASU notwendig.

Query-String-Parameter sowie die Legacy-Parameter gridExtId, tablePrefix und mandant werden nicht mehr unterstützt und wurden entfernt.

Ein Request-Objekt besteht nun immer aus den folgenden Elementen:

  • "config": Ein Konfigurationsobjekt.

  • "bpcUrl": Eine eindeutige URL zur Identifizierung des Ziels im Format bpc://<flow/backendconnection>/<instanceId>/<EndpointOrProcessor>.

  • "records" (optional): Ein Array von Datensätzen, falls ein Kontext übergeben wird.

  • "metadata" (optional): Ein Objekt für zusätzliche Kontext- oder Konfigurationsinformationen, in dem bspw. Legacy-Parameter übergeben werden können, falls notwendig.

Eine detaillierte Beschreibung aller Endpunkte finden Sie in unserer OpenAPI Spezifikation.

Prozess Aktionen

Die Ausführung von Prozess-Aktionen wurde von Form Data auf die neue, einheitliche JSON-Struktur umgestellt.

Konfiguration
Die bisherige Konfiguration über die Einstellungen Function_InubitBackendConnection (inubit_proxyId), Function_InubitBaseURL (inubit_baseUrl) und Function_ProcessActionsEndpoint ist veraltet. Diese Einstellungen werden automatisch zur Einstellung Function_ActionsEndpointProcessor migriert.

Die neue Konfiguration erfordert nur noch die Einstellung Function_ActionsEndpointProcessor. Über diese Einstellung kann entweder ein Prozessor aus dem Flow Modul oder eine Backend Connection (HTTP-Proxy) mit einem benutzerdefinierten Endpunkt ausgewählt werden.

Metadaten
Um bei Prozess-Aktionen zusätzliche Metadaten mitzusenden, können diese nun zentral in den Monitor-Einstellungen unter "Prozessaktions-Metadaten" konfiguriert werden.

Beispiel: Aufrufstruktur im Vergleich
Hier sehen Sie den direkten Vergleich zwischen der alten Form-Struktur und der neuen JSON-Struktur.

ALT mit zwei ausgewählten Indizes (Form Data)
URL: /cxf/bpc-monitor/monitor/httpProxy/inubit-placeholder/ibis/servlet/IBISHTTPUploadServlet/PM_LogMonitor_Action?gridId=singlegrid&gridExtId=PM-core-singlegrid-grid&multiRecords=true&buttonId=action_test&action_test=Action%20Requires%20Comments

Content-Type: application/x-www-form-urlencoded

index0_action_test:[{"id": "simple-action","name": "A Simple Action","iconCls": "x-fal fa-alarm-clock","sortValue": 1},{"id": "action-requires-comments","name": "Action Requires Confirmation","iconCls": "x-fal fa-biking-mountain","sortValue": 1, "requireConfirmation": true}]
index0_collabdata:Collaboration Service not available or collabReferenceKey not set
index0_id:1
index0_text:requireConfirmation true
index0__id:1
index0_action_test_zwo:action zwo
index0_bpccleanedid:_1
index0_tablePrefix:single_
index1_action_test:[{"id": "simple-action","name": "A Simple Action","iconCls": "x-fal fa-alarm-clock","sortValue": 1},{"id": "action-requires-comments","name": "Action Requires Comments","iconCls": "x-fal fa-biking-mountain","sortValue": 1,"requireComment": true, "requireConfirmation": true}]
index1_collabdata:Collaboration Service not available or collabReferenceKey not set
index1_id:2
index1_text:requireConfirmation true requireComment true
index1__id:2
index1_action_test_zwo:action zwo
index1_bpccleanedid:_2
index1_tablePrefix:single_
actionConfig_id:action-requires-comments
actionConfig_name:Action Requires Comments
actionConfig_iconCls:x-fal fa-biking-mountain
actionConfig_sortValue:1
actionConfig_requireComment:true
actionConfig_requireConfirmation:true
actionConfig_label:Action Requires Comments
actionConfig_column:action_test
actionConfig_type:processAction
actionConfig_comment:Kommentar

NEU (JSON)

{
  "config": {
    "id": "action-requires-comments",
    "name": "Action Requires Comments",
    "iconCls": "x-fal fa-biking-mountain",
    "sortValue": 1,
    "requireComment": true,
    "requireConfirmation": true,
    "label": "Action Requires Comments",
    "column": "action_test",
    "type": "processAction",
    "instanceId": "process-actions-test-monitor-notifications",
    "comment": "Kommentar"
  },
  "metadata": {
    "foo": "bar"
  },
  "bpcUrl": "bpc://flow/flow_iguasu/endpointOrProcessor",
  "records": [
    {
      "action_test": "[{\"id\": \"simple-action\",\"name\": \"A Simple Action\",\"iconCls\": \"x-fal fa-alarm-clock\",\"sortValue\": 1},{\"id\": \"action-requires-comments\",\"name\": \"Action Requires Confirmation\",\"iconCls\": \"x-fal fa-biking-mountain\",\"sortValue\": 1, \"requireConfirmation\": true}]",
      "collabdata": "Collaboration Service not available or collabReferenceKey not set",
      "id": "1",
      "text": "requireConfirmation true",
      "_id": "1",
      "action_test_zwo": "action zwo",
      "bpccleanedid": "_1"
    },
    {
      "action_test": "[{\"id\": \"simple-action\",\"name\": \"A Simple Action\",\"iconCls\": \"x-fal fa-alarm-clock\",\"sortValue\": 1},{\"id\": \"action-requires-comments\",\"name\": \"Action Requires Comments\",\"iconCls\": \"x-fal fa-biking-mountain\",\"sortValue\": 1,\"requireComment\": true, \"requireConfirmation\": true}]",
      "collabdata": "Collaboration Service not available or collabReferenceKey not set",
      "id": "2",
      "text": "requireConfirmation true requireComment true",
      "_id": "2",
      "action_test_zwo": "action zwo",
      "bpccleanedid": "_2"
    }
  ]
}

Prozess Starter

Auch das Starten von Prozessen folgt nun der neuen JSON-Struktur.

Konfiguration
Ähnlich wie bei den Prozess-Aktionen entfallen die Einstellungen Function_InubitBackendConnection, Function_InubitBaseURL und Function_ProcessStarterEndpoint. Diese Einstellungen werden automatisch zur Einstellung Function_VpsEndpointProcessor migriert.

Stattdessen wird nur noch die Einstellung Function_VpsEndpointProcessor benötigt, um das Ziel (Flow-Prozessor oder Backend Connection) zu definieren.

Metadaten
Zusätzliche Metadaten können direkt in der Prozess-Starter-Konfiguration im Monitor für jeden Prozess individuell über ein metadata-Objekt hinzugefügt werden.

Beispiel: Aufrufstruktur im Vergleich
ALT "mit Kontext" (XML)

<root>
	<portletArchiveName></portletArchiveName>
	<operation>startProcess</operation>
	<mandant>default</mandant>
	<gridID>singlegrid</gridID>
	<key>datenuebertragen</key>
	<bpcModule>monitor</bpcModule>
	<bpcModuleInstanceId>process-starter-start-with-context</bpcModuleInstanceId>
	<data type="array">
		<item type="tuple">
			<statusField>ERROR</statusField>
			<textField>This is third test object</textField>
			<idField>3</idField>
			<dateField>2020-02-01</dateField>
			<records type="array">
				<item type="tuple">
					<status>ERROR</status>
					<collabdata>Collaboration Service not available or collabReferenceKey not set</collabdata>
					<text>This is third test object</text>
					<_id>3</_id>
					<processid>3</processid>
					<timestamp>2020-02-01T12:00:00.000+0200</timestamp>
					<bpccleanedid>_3</bpccleanedid>
				</item>
			</records>
		</item>
	</data>
</root>

NEU "mit Kontext" (JSON)

{
  "config": {
    "id": "datenuebertragen",
    "label": "startWithContextProcess",
    "parameters": {
      "statusField": "ERROR",
      "textField": "This is third test object",
      "idField": "3",
      "dateField": "2020-02-01"
    },
    "type": "processStarter",
    "instanceId": "process-starter-start-with-context"
  },
  "bpcUrl": "bpc://flow/flow_iguasu/endpointOrProcessor",
  "records": [
    {
      "status": "ERROR",
      "collabdata": "Collaboration Service not available or collabReferenceKey not set",
      "text": "This is third test object",
      "_id": "3",
      "processid": "3",
      "timestamp": "2020-02-01T12:00:00.000+0200",
      "bpccleanedid": "_3"
    }
  ]
}

ALT "mit Grid" (XML)

<root>
	<portletArchiveName></portletArchiveName>
	<operation>startProcess</operation>
	<mandant>default</mandant>
	<gridID>singlegrid</gridID>
	<key>sendOrders</key>
	<bpcModule>monitor</bpcModule>
	<bpcModuleInstanceId>process-starter-with-role</bpcModuleInstanceId>
	<data type="array">
		<item type="tuple">
			<receiver>Nummer 1</receiver>
			<artikelnummer>Nummer 2</artikelnummer>
			<positionen>
				<record>
					<id>extModel408-1</id>
					<artikelnummertabelle>Nummer 1</artikelnummertabelle>
					<quantity>1</quantity>
				</record>
				<record>
					<id>extModel408-2</id>
					<artikelnummertabelle>Nummer 2</artikelnummertabelle>
					<quantity>2</quantity>
				</record>
			</positionen>
		</item>
	</data>
</root>

NEU "mit Grid" (JSON)

{
  "config": {
    "id": "sendOrders",
    "label": "Bestellung aufgeben (für BPC-4638)",
    "parameters": {
      "receiver": "Nummer 1",
      "artikelnummer": "Nummer 2",
      "positionen": [ (1)
        {
          "id": "extModel409-1",
          "artikelnummertabelle": "Nummer 1",
          "quantity": 1
        },
        {
          "id": "extModel409-2",
          "artikelnummertabelle": "Nummer 2",
          "quantity": 2
        }
      ]
    },
    "type": "processStarter",
    "instanceId": "process-starter-with-role"
  },
  "bpcUrl": "bpc://flow/flow_iguasu/endpointOrProcessor"
}
1 "positionen" ist die ID (key) des Grids in der Prozess-Starter Konfiguration

ALT "mit mode = initialRemote & reloadRemoteData" (XML)
URL: /cxf/bpc-httpproxy/httpProxy/inubit-placeholder/ibis/servlet/IBISHTTPUploadServlet/BPC_PS_Listener?reloadOnChange=true

<root>
	<portletArchiveName></portletArchiveName>
	<mandant>default</mandant>
	<gridID>singlegrid</gridID>
	<custom>true</custom>
	<bpcModule>monitor</bpcModule>
	<bpcModuleInstanceId>process-starter-forms</bpcModuleInstanceId>
	<process>sendOrders</process>
	<key>artikelnummer</key>
	<operation>choiceList</operation>
	<formData>
		<receiver>Nummer 1</receiver>
		<artikelnummer>null</artikelnummer>
		<positionen></positionen>
	</formData>
</root>

NEU "mit mode = initialRemote & reloadRemoteData" (JSON)

{
  "config": {
    "id": "sendOrders",
    "label": "Bestellung aufgeben (für BPC-4638)",
    "parameters": {
      "receiver": "Nummer 1",
      "artikelnummer": "",
      "positionen": {}
    },
    "type": "processStarter",
    "instanceId": "process-starter-forms"
  },
  "metadata": { (1)
    "process": "sendOrders",
    "key": "artikelnummer",
    "operation": "choiceList",
    "reloadOnChange": true  (2)
  },
  "bpcUrl": "bpc://flow/flow_iguasu/endpointOrProcessor"
}
1 Das "metadata"-Objekt wird gesetzt, wenn mode auf "initialRemote" gesetzt wird oder reloadRemoteData true ist.
2 "reloadOnChange" wird nur gesetzt, wenn reloadRemoteData = true.

Prozessstatuswechsel

Die Änderung des Prozessstatus wurde ebenfalls auf die vereinheitlichte JSON-Struktur umgestellt.

Konfiguration
Die Konfiguration über Function_InubitBackendConnection, Function_InubitBaseURL und Function_ChangeStateEndpoint ist nicht mehr notwendig. Diese Einstellungen werden automatisch zur Einstellung Function_ChangeStateEndpointProcessor migriert.

Die Definition des Ziels erfolgt nun ausschließlich über die Einstellung Function_ChangeStateEndpointProcessor.

Metadaten
Sollen beim Statuswechsel Metadaten übergeben werden, kann ein metadata-Objekt direkt in der ChangeStateConfig für jede Spalte hinzugefügt werden.

Beispiel: Aufrufstruktur im Vergleich
ALT (Form Data)

Content-Type: application/x-www-form-urlencoded

tablePrefix:single_
mandant:default
timelineUpdate:TIMESTAMP
childStatus:Info
command:StatusChange
columnsstring:status
changeStatusBox_status:on
newStatusCombo_status:inprocess
commentfield:Starte Verarbeitung
processes:extModel8836-1

NEU (JSON)

{
  "config": {
    "timelineUpdate": "TIMESTAMP",
    "type": "statusChange",
    "column": "status",
    "newStatus": "inprocess",
    "comment": "Starte Verarbeitung",
    "processes": "extModel8836-1",
    "instanceId": "change-status-test-monitor"
  },
  "bpcUrl": "bpc://flow/flow_iguasu/endpointOrProcessor",
  "metadata": {
    "childStatus": "Info" (1)
  }
}
1 "childStatus": "Info" ist nicht mehr Teil der Default ChangeStateConfig. Wenn childStatus gesetzt ist, wird es automatisch in das metadata-Objekt migriert.

Änderungen im Forms Modul

Innerhalb des Forms-Moduls wurden einige Änderungen und Vereinheitlichungen vorgenommen. Davon betroffen sind überwiegend die Formularkonfiguration an sich, aber auch der Nachrichtenaustausch aus einer Forms-Applikation heraus.

Formularkonfiguration

Damit eine Formularkonfiguration angezeigt werden kann, sind einige Änderungen erforderlich. Die Konfiguration onChangeBufferTime wurde entfernt, da validateOnChange überarbeitet wurde und nun nur noch nach Beendigung der Bearbeitung auslöst. dataUrl wurde mit stateUrl ersetzt und ermöglicht das Laden von Daten in den state.

Das Schema zur Validierung von Formularkonfigurationen ist wesentlich restriktiver. Dadurch werden Formulare öfter nicht angezeigt, wenn sie nicht dem vorgegebenen Schema entsprechen.

Mehrsprachigkeit wurde überarbeitet und kann an erheblich mehr Stellen eingesetzt werden. Allerdings muss nun der Tag MULTI_LANGUAGE verwendet werden. Der MULTI_LANGUAGE Tag ist an allen Stellen erforderlich, an denen eine Übersetzung erwartet wird.

Tabelle 1. Mehrsprachigkeit
Vorher Nachher 
{
  "type": "textfield",
  "label": {
    "de": "deutsches label",
    "en": "englisch label"
  }
}
 
{
  "type": "textfield",
  "label": {
    "MULTI_LANGUAGE" : {
      "de": "deutsches label",
      "en": "englisch label"
    }
  }
}
 
{
  "state": {
    "data": {
      "options": [{
        "value": "one",
        "label": {
          "de": "Eins",
          "en": "One"
        }
      },
      {
        "value": "two",
        "label": {
          "de": "Zwei",
          "en": "Two"
        }
      }]
    }
  }
}
 
{
  "state": {
    "data": {
      "options": [{
        "value": "one",
        "label": {
          "MULTI_LANGUAGE": {
            "de": "Eins",
            "en": "One"
          }
        }
      },
      {
        "value": "two",
        "label": {
          "MULTI_LANGUAGE": {
            "de": "Zwei",
            "en": "Two"
          }
        }
      }]
    }
  }
}

Data-Binding verwendet eine andere Syntax als zuvor. Für Binding ist es nun erforderlich ${} zu verwenden.

Tabelle 2. Data-Binding
Vorher Nachher 
{
  "type": "textfield",
  "value": "/data/text"
}
 
{
  "type": "textfield",
  "value": "${/data/text}"
}

Nachrichtenaustausch

Von diesen Änderungen betroffen sind Iframe Nachrichten, Server Nachrichten und auch onChange innerhalb der Formularkonfiguration.

Die Struktur zum Aufruf einer Aktion wurde vereinheitlicht. Somit sind an Stellen Änderungen erforderlich, an denen mit dem Forms-Modul interagiert wird.

Tabelle 3. Aktion Anfrage
Vorher Nachher

Iframe Nachrichten.

{
  "sourceId": "SOURCE_ID",
  "requestName": "setData",
  "request": {
    "welcomeMsg" : "<h1>Willkommen</h1>"
  }
}

Bei Iframe Nachrichten ist action statt requestName und payload statt request zu verwenden.

{
  "sourceId": "SOURCE_ID",
  "action"  : "setFormState",
  "payload": {
    "data": {
      "welcomeMsg": "<h1>Willkommen</h1>"
    }
  }
}

Antwort auf einen erfolgreichen Submit.

{
  "result" : "success",
  "action" : "downloadFile",
  "data"   : {
    "fileName" : "testfile.txt",
    "data"     : "Hello World"
  }
}

Bei Antworten auf einen erfolgreichen Submit ist payload statt data zu verwenden. Zudem wird der Tag result nicht mehr verwendet. Um eine Rückmeldung an den Nutzer zu geben, kann nun die Aktion dialog verwendet werden.

{
  "action"  : "downloadFile",
  "payload" : {
    "fileName" : "testfile.txt",
    "data"     : "Hello World"
  }
}

onChange Konfiguration.

{
  "type": "textfield",
  "onChange": {
    "action": "getFormState",
    "data": {
      "stateUrl": "http://localhost:3000/load"
    }
  }
}
 
{
  "type": "textfield",
  "onChange": {
    "action": "getFormState",
    "payload": {
      "url": "http://localhost:3000/load"
    }
  }
}

Die Nachrichten aus dem Forms-Modul heraus wurden nur im Kontext von Iframe Nachrichten verändert. Hierbei wurde ein success Tag hinzugefügt, der angibt ob die Aktion durchgeführt werden konnte. requestName wurde mit action ersetzt.

Tabelle 4. Aktion Antwort
Vorher Nachher

Iframe Nachrichten.

{
  "requestName" : "setFormConfig",
  "destinationId" : "*",
  "response" : {}
}
 
{
  "success" : true,
  "action" : "setFormConfig",
  "destinationId" : "*",
  "response" : {}
}

Im Iframe Kontext wurden diverse Aktionen zur Vereinheitlichung umbenannt.

Tabelle 5. Umbenennung Aktionen
Vorher Nachher

getFormConfig

Diese Funktion wurde entfernt. getFormConfig hat nun eine andere Bedeutung und wird zum Laden von einer Formularkonfiguration verwendet.

printForm

print

resetForm

reset

setData

setFormState

submitData

submit

validateData

validate

Einige Funktionen wurden zur Vereinheitlichung in der Struktur angepasst.

Tabelle 6. Strukturanpassung Aktionen
Vorher Nachher 
{
  "result": "success",
  "action": "setFormConfig",
  "data": {
    "formConfig": {
      "metaData": {
        "id": 0,
        "version": 0
      },
      "components": [
        {
          "type": "html",
          "value": "setFormConfig"
        }
      ],
      "configuration": {}
    }
  }
}

Der zuvor erforderliche Tag formConfig wurde entfernt.

{
  "action": "setFormConfig",
  "payload": {
    "metaData": {
      "id": 0,
      "version": 0
    },
    "components": [
      {
        "type": "html",
        "value": "setFormConfig"
      }
    ],
    "configuration": {}
  }
}

Iframe Nachricht.

{
  "requestName": "setData",
  "request": {
    "welcomeMsg" : "<h1>Willkommen</h1>"
  }
}

Server Nachricht.

{
  "action" : "setFormState",
  "data"   : {
    "state" : {
      "welcomeMsg" : "<h1>Willkommen</h1>"
    }
  }
}

Sowohl für Iframe als auch Server Nachrichten wurden zuvor die neuen Daten direkt in den data Bereich im state geschrieben. Daten werden jetzt direkt in den state geschrieben. Für das gleiche Ziel ist daher ein extra data erforderlich. Für Server Nachrichten entfällt zudem der zusätzliche tag state.

{
  "action"  : "setFormState",
  "payload": {
    "data": {
      "welcomeMsg": "<h1>Willkommen</h1>"
    }
  }
}

Validierung

Die Validierung wurden an mehreren Stellen überarbeitet. Die Data-Schema Validierung startet nun auf der state Ebene.

Tabelle 7. Data-Schema Validierung
Vorher Nachher 
{
  "dataSchema": {
    "type": "object",
    "properties": {
      "textValue": {
        "minLength": 20,
        "type": "string"
      }
    }
  }
}
 
{
  "dataSchema": {
    "type": "object",
    "properties": {
      "data": {
        "type": "object",
        "properties": {
          "textValue": {
            "minLength": 20,
            "type": "string"
          }
        }
      }
    }
  }
}

Das Nachrichtenformat der serverseitigen Validierung wurde geändert. validationErrors ist nun eine eigene Aktion, die ausgelöst werden kann und wird nicht mehr als eigenes Attribut gewertet. Der instancePath startet auf state Ebene und verwendet die neue Data-Binding Notation.

Tabelle 8. Serverseitige Validierung
Vorher Nachher 
{
  "validationErrors": [
    {
      "instancePath": "/textValue",
      "message": "validation error"
    }
  ]
}
 
{
  "action": "validationErrors",
  "payload": [
    {
      "instancePath": "${/data/text}",
      "message": "validation error"
    }
  ]
}

Die Validierungsfehler werden anders im state anders abgespeichert.

Tabelle 9. Serverseitige Validierung
Vorher Nachher 
{
  "state": {
    "valid": true,
    "validationOk" :  {
      "server": true,
      "client": true
    },
    "validationErrors": {
      "server": [],
      "client": []
    }
  }
}
 
{
  "state": {
    "validationOk" :  {
      "all": true,
      "dataSchema": true,
      "field": true,
      "server": true
    },
    "validationErrors": {
      "all": [],
      "dataSchema": [],
      "field": [],
      "server": []
    }
  }
}

Maskierung von API Keys im Frontend

In BPC 5.0 werden API Keys im Frontend maskiert und können daher nicht mehr ausgelesen werden. Wir empfehlen deshalb, dass Sie vorhandene API Keys an einem sicheren Ort ablegen (z.B. in einem Passwort-Manager), falls Sie dies noch nicht gemacht haben.

Nachwievor können API Keys direkt aus OpenSearch ausgelesen werden, zum Beispiel mit curl:

curl --cert {OPENSEARCH-ZERTIFIKAT} {OPENSEARCH-URL}/bpc-configuration/_doc/_core_noinstance_apiKeys/\?pretty

Unter Direkter Zugriff auf OpenSearch finden Sie mehr Details, wie man mit curl auf OpenSearch zugreift.

Keywords:
Press Esc to exit full screen
Modal image placeholder
Press Esc to exit full screen