Die B2B-UI wird auch B2B-Functional-UI genannt.

Funktionalität

Die UI enthält:

• Dashboard mit News & Statistiken
• MessageMonitor
• Arbeitsvorräte
• MpidEditor
• Systemweiche
• Manueller Versand

Architektur

Die UI kommuniziert mit einer B2B im Tomcat.

Sowohl UI als auch Tomcat müssen über Keycloak abgesichert sein. Im Rahmen dieser Doku wird beschrieben, wie ein entsprechender Tomcat im Docker ausgeführt werden kann.

Die folgende Abbildung skizziert die Zusammenhänge der einzelnen Komponenten des Setups:

Remote-B2B

Als “Remote-B2B” wird das System/Server bezeichnet in dem die bestehende B2B betrieben wird.

Remote-B2B-Datenbank

Als “Remote-B2B-Datenbank” wird das System/Server bezeichnet in dem die Datenbank der Remote-B2B betrieben wird.

keycloak

Unser Docker-Container “keycloak” stellt eine entsprechende Instanz zur Verfügung, die für die Authentifizierung der Nutzer über die B2B-New-UI gegen das B2B-Backend zuständig ist. Diese Keycloak-Instanz wird innerhalb des Dockers betrieben und speichert die Daten (Rollen und Nutzer) in einer eigenen Datenbank. In diesem Setup wird als Datenbank die standardmäßig integrierte H2-Datenbank genutzt. Über ein docker mount wird die Datenbank in das Dateisystem des Docker-Host gemountet, sodass die Daten auch nach dem Löschen des Keycloak-Containers zur Verfügung stehen.

Für einen produktiven Keycloak Einsatz empfehlen wir statt der integrierten H2 Datenbank eine DB analog zur Remote-B2B-Datenbank zu nutzen, also z.B. Postgres oder Oracle.

Für einen produktiven Keycloak Einsatz in einer öffentlichen Umgebung empfehlen wir dringend den Einsatz von HTTPS.

b2bui

Dieser Docker-Container stellt die eigentliche B2B-New-UI-Instanz bereit. Dies läuft in einem nginx Webserver.

b2b

Der Docker-Container der B2B ist prinzipiell nicht zwingend notwendig, wird in diesem Setup aber vorgesehen, da die B2B-Instanz mit der die B2B-New-UI kommuniziert, ebenfalls an keycloak angebunden sein muss. Damit die bestehende B2B (Remote-B2B), nicht für die Anbindung an Keycloak umkonfiguriert werden muss, wurde sich für eine separate B2B-Instanz in einem Docker-Container entschieden.

Übergangsweise ist ein Mischbetrieb denkbar, bei dem insbesondere die Knoten, die vom Frontend angesprochen werden, auf Keycloak umgestellt werden, während gerade die für Backendprozesse relevanten Knoten zunächst weiterhin über BasicAuth angesprochen werden.

B2B Vorinstallation

Voraussetzung dieser Dokumentation ist, dass Sie bereits mind. einen B2B Knoten samt Datenbank eingerichtet haben. Dieser Knoten wurde im vorherigen Abschnitt Remote B2B genannt, die Datenbank wurde Remote-B2B-Datenbank genannt.

Voraussetzungen

• Docker einsatzbereit
• Keycloak installiert
• Remote B2B-Datenbank installiert

Installation

Anpassungen der bestehenden B2B-Instanz

Um einen reibungslosen Start der B2B-Instanz im Docker sicherzustellen, müssen noch die folgenden Anpassungen an der bestehenden B2B-Instanz vorgenommen werden.

Anpassungen der Remote-B2B-Datenbank

In dem Schema der bestehenden B2B-DB-Instanz müssen die hier aufgeführten Datenbankanpassungen durchgeführt werden.

Anpassungen des Customizings

Anpassen einer GlobalProperty für die ClusterCommunication

Wie für die B2B üblich muss einem neuen Knoten eine Knotennummer in den GlobalProperties zugewiesen werden. Danach muss der Knoten neugestartet werden.

In der DB-Tabelle B2BBP_ADM_GLOBAL_PROPERTY muss der PROPERTYKY=b2b-tomcatusrlocaltomcatwebappsb2bbp-engine eingefügt werden. Der Wert des Feldes PROPERTYKEY setzt sich wie folgt zusammen:

[in der docker-compose.yml angegebene hostname des b2b-Containers][Pfad (ohne Trennzeichen "/") der gestarteten B2B-Instanz im Docker-Container)]

Dieser Datensatz erhält nach dem Start des B2B-Containers automatisch einen Wert [Knotennr.],LAST STARTED AT: [Datum] at [Uhrzeit].

Für dieses Feature wird der hostname in der docker-compose.yml explizit angegeben.

Anpassungen der Arbeitsvorräte

Die B2B-Arbeitsvorräte (nicht zu verwechseln mit den CCM-Arbeitsvorräten) werden nun nicht mehr über die Rollenattribute sondern über die Extension WORKLISTS konfiguriert. Bei der Umstellung hilft das Migration-Tool.

Docker-Compose

docker-compose Umgebung

Unsere Docker Umgebung wird hauptsächlich durch eine Reihe von Konfigurationsdateien gesteuert. Diese im Folgenden beschriebenen Dateien können von NLI gebündelt als zip-Archiv bereitgestellt werden.

Das Setup der hier beschriebenen Umgebung basiert auf einem docker-compose file. Diese Konfiguration definiert die einzelnen Container, deren Sichtbarkeit und die einzubindenden Dateien.

Die docker-compose Umgebung besteht letztlich aus einer Verzeichnisstruktur, die die einzelnen im Folgenden beschriebenen Dateien enthält. Die Verzeichnisstruktur stellt sich wie folgt dar:

| base/
  |- b2b-tomcat/
  |  |- lib/
  |  |  |- [DB-JDBC-Treiber].jar
  |  |- tomcat_all/
  |  |  |- index/
  |  |     |- full/
  |  |     |- arc/
  |  |     |- ccm/
  |  |- b2bbp-engine.xml
  |  |- keycloak.json
  |- b2b-ui/
  |  |- keycloak.json
  |- docker-compose.yml
  |- .env
  |- system.json

Diese Dokumentation basiert auf der folgenden docker-compose.yml:

version: '3.7'
services:
  traefik:
    image: "traefik:v2.3"
    command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.traefik.address=:7777"
      - "--entryPoints.web.forwardedHeaders.insecure"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
#   For running local
    ports:
      - 80:80
#    For Linux machine
#    network_mode: host
  b2b:
    image: ${NEXUS}/b2b:2021-02-22
    restart: always
    hostname: b2b
    ports:
      # Port unter dem die B2B-Instanz (auch von außen) erreichbar ist
      - ${B2B_PORT}:8080
    environment:
      TZ: ${TIME_ZONE}
      SYSTEM_NAME: ${SYSTEM_NAME}
      KC_REALM: ${KC_REALM}
      KC_URL: ${KC_URL}
      KC_SSL_REQUIRED: ${KC_SSL_REQUIRED}
      KC_CLIENT: b2b-ui
    volumes:
      # mount point für die zu verwendende B2B-DB-Konfiguration
      - ./b2b-tomcat/b2bbp-engine.xml:/usr/local/tomcat/conf/Catalina/localhost/b2bbp-engine.xml
      # mount point für die zu verwendende B2B-keycloak-Konfiguration
      - ./b2b-tomcat/keycloak.json:/usr/local/tomcat/conf/keycloak.json
      # mount für die logs
      - ./b2b-tomcat/tomcat_all/logs:${LOGS}
      # mount points für die zu verwendende B2B-Indizes
      - ./b2b-tomcat/tomcat_all/index/full:${FUL_IDX_PATH}
      - ./b2b-tomcat/tomcat_all/index/arc:${ARC_IDX_PATH}
      - ./b2b-tomcat/tomcat_all/index/ccm:${CCM_IDX_PATH}
      # mount point für den zu verwendenden B2B-DB-Treiber
      - ./b2b-tomcat/lib/${DB_DRV_FILE}:/usr/local/tomcat/lib/${DB_DRV_FILE}
  # Container-Definition für die B2B-New-UI-Instanz
  b2b-ui:
    image: ${NEXUS}/b2b-ui:2023-08-10
    restart: always
    ports:
      # Port unter dem die B2B-New-UI-Instanz (auch von außen) erreichbar ist
      - ${NUI_PORT}:8080
    environment:
      TZ: ${TIME_ZONE}
    volumes:
      - ./b2b-ui/logs:/var/log/nginx
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.b2b-ui.rule=Host(`${TRAEFIK_HOST}`) && PathPrefix(`/B2B-UI`)"	  
    depends_on:
      - b2b

Bitte folgen Sie unseren Konventionen für Servicenamen (aus denen sich dann die Hostnamen ergeben).

Achten Sie beim image darauf, eine aktuelle Version gemäß unserer Kompatibilitätsübersicht anzugeben.

Die oben aufgeführte docker-compose.yml beinhaltet verschiedene Variablen “${Variable}”. Diese Variablen dienen der Auslagerung von speziellen Bedingungen. Diese Variablen sind in der Datei .env enthalten und werden während des Starts der Container via docker-compose angewendet. Für die oben aufgeführte docker-compose.yml sieht die .env wie folgt aus:

NEXUS=docker-nob-erf.next-level-apps.com
TIME_ZONE=Europe/Berlin
B2B_PORT=8081
NUI_PORT=8082
FUL_IDX_PATH=/usr/local/tomcat_all/index/full
ARC_IDX_PATH=/usr/local/tomcat_all/index/archive
CCM_IDX_PATH=/usr/local/tomcat_all/index/ccm
LOGS=/usr/local/tomcat_all/logs
DB_DRV_FILE=postgresql-42.2.16.jar
TRAEFIK_HOST=localhost
SYSTEM_NAME="B2B Local"
KC_REALM=b2b
KC_URL=http://host.docker.internal:9000/auth/
KC_SSL_REQUIRED=none

Weiterhin werden in der oben aufgeführten docker-compose.yml verschiedenen Dateien referenziert. Sowohl die angegebenen Verzeichnisse der einzelnen Dateien, als auch die Dateien an sich, sind Bestandteil der docker-compose Umgebung und werden in den Abschnitten der konkreten Applikationen aufgeführt und erläutert.

optionale Docker-Compose Konfiguration

Falls es bei Ihnen zu Abbrüchen während der Volltextsuche oder in den Arbeitsvorräten kommt (besonders bei MSSQL- und Oracle-Datenbanken beobachtet), müssen Sie das Auxiliary Search Threshold konfigurieren. Es steuert, ab welcher Anzahl an Treffern die Hilfstabelle zum Einsatz kommen soll. Die Hilfstabelle verhindert, dass Datenbankanfragen zu groß werden. Reduzieren Sie den Wert der Eigenschaft, wenn es zu Abbrüchen bei der Volltextsuche oder Suche in den Arbeitsvorräten kommt. Default ist 30000, für MSSQL empfehlen wir als Wert 2000, für Oracle 1000.

Die Eigenschaft kann als Umgebungsvariable bei einer Docker Installation in der docker-compose.yml gesetzt werden:

  b2b:
    environment:
      AUXILIARY_SEARCH_THRESHOLD: 2000

Dasselbe bewirkt die Systemeigenschaft auxiliarySearchThreshold, z.B. als Java-Property -DauxiliarySearchThreshold=2000 konfiguriert.

Wenn Sie einen vom Standard abweichenden Service in Ihrer Reverse-Proxy-Konfiguration konfigurieren möchten, folgen Sie bitten den Hinweisen in der Docker-Compose-Dokumentation

Traefik

Der Traefik Container wird für das Routing der Request verwendet. Durch das Hinzufügen von verschienden Lables zu den anderen Containern wird der Traefik konfiguriert. Durch die Umgebungsvariable TRAEFIK_HOST muss der durch Traefik verwendete Hostname gesetzt werden.

B2B-Tomcat

Das Veröffentlichen des B2B-Tomcat-Ports nach außen ist optional, solange der Tomcat nur von der UI angesprochen wird. Wird der Port veröffentlicht, kann man z.B. zu Testzwecken auf die Swagger-UI zugreifen.

Einbindung des Datenbank-Treibers

Wenn als Remote B2B-Datenbank eine Oracle eingesetzt wird und die entsprechenden Datenbank-Treiber aus Lizenzgründen nicht durch uns ausgeliefert werden dürfen, sind diese durch den Kunden in das Verzeichnis ./b2b-tomcat/lib/ zu kopieren. Als Bezugsquelle für die JDBC-Treiber kann die entsprechende Download-Seite von Oracle verwendet werden (siehe auch hier). Der Dateiname ist in der Umgebungsvariablen DB_DRV_FILE anzugeben.

./b2b-tomcat/b2bbp-engine.xml

Verwendung von Umgebungsvariablen (ab August 2023)

Wir empfehlen die Verwendung von Umgebungsvariablen in der b2bbp-engine.xml, sofern keine zusätzlichen Eigenschaften konfiguriert werden sollen.

Die Standard b2bbp-engine.xml für die B2B sieht aktuell wir folgt aus (die letzten beiden Parameter bzgl. Keycloak sind im b2b-basicauth-DockerImage nicht enthalten):

<?xml version="1.0" encoding="UTF-8" ?>
<Context path="/b2bbp-engine" reloadable="false" cachingAllowed="true" crossContext="true">
	<Resource name="jdbc/b2bbp"
			  auth="Container"
			  type="javax.sql.DataSource"
			  driverClassName="${DB_DRIVER}"
			  url="${DB_URL}"
			  username="${DB_USER}"
			  password="${DB_PASSWORD}"
			  maxActive="${DB_MAX_ACTIVE}"
			  initialSize="5"
              maxIdle="10"
              minIdle="1"
              maxWait="1200000"
              validationQuery="${DB_VALIDATION_QUERY}"
              validationInterval="30000"
              timeBetweenEvictionRunsMillis="30000"
              testOnBorrow="true"
              removeAbandoned="false"
              testOnReturn="true"
              testWhileIdle="true"
              maxAge="30000"
              logAbandoned="true"
              suspectTimeout="60"
              logValidationErrors="true"
             />

	<Valve className="org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve"/>

	<Parameter name="keycloak.config.file" value="/usr/local/tomcat/conf/keycloak.json" override="false"/>

</Context>

Die definierten Umgebungsvariablen werden beim Erzeugen des Docker-Containers gesetzt und verwendet, sofern keine b2bbp-engine.xml-Datei in den Container gemountet wurde.

Sollten sich Umgebungsvariablen zu einem späteren Zeitpunkt ändern (wie z.B. ein neues Passwort), so muss der DockerContainer neu erzeugt werden, damit der neue Wert der Umgebungsvariablen in die b2bbp-engine.xml übernommen wird.

Bei allen Datenbank-Parametern müssen XML-Sonderzeichen escaped werden, da sonst keine valide b2bbp-engine.xml erzeugt wird.

Als gesamte Datei

Diese Datei definiert die Datenbankverbindung, mit der sich die B2B-Instanz mit der Remote-B2B-Datenbank verbindet. Hier die für diese Dokumentation verwendete Datei:

<?xml version="1.0" encoding="UTF-8" ?>
<Context path="/b2bbp-engine" reloadable="true" cachingAllowed="true" crossContext="true">
	<Resource name="jdbc/b2bbp"
			  auth="Container"
			  type="javax.sql.DataSource"
			  driverClassName="[jdbc-Treiber, z.B. org.postgresql.Driver]"
			  url="jdbc:[Datenbank, z.B. postgresql]://[Host der Remote-B2B-DB]:[Port der Remote-B2B-DB]/[Name der Remote-B2B-DB]"
			  username="[username]"
			  password="[password]"
			  maxTotal="20"
			  maxIdle="10"
			  maxWaitMillis="-1"/>

	<Valve className="org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve"/>

	<Parameter name="keycloak.config.file" value="/usr/local/tomcat/conf/keycloak.json" override="false"/>

</Context>

./b2b-tomcat/keycloak.json

Verwendung von Umgebungsvariablen (ab August 2023)

Wir empfehlen die Verwendung von Umgebungsvariablen in der keycloak.json, sofern keine zusätzlichen Eigenschaften konfiguriert werden sollen.

Die Standard keycloak.json für die B2B sieht aktuell wie folgt aus (die keycloak.json ist im b2b-basicauth-DockerImage nicht enthalten):

{
  "realm": "${KC_REALM}",
  "auth-server-url": "${KC_URL}",
  "ssl-required": "${KC_SSL_REQUIRED}",
  "resource": "${KC_CLIENT}",
  "public-client": true,
  "confidential-port": 0
}

Die definierten Umgebungsvariablen werden beim Erzeugen des Docker-Containers gesetzt und verwendet, sofern keine keycloak.json-Datei in den Container gemountet wurde.

Sollten sich Umgebungsvariablen zu einem späteren Zeitpunkt ändern (wie z.B. ein neues Passwort), so muss der DockerContainer neu erzeugt werden, damit der neue Wert der Umgebungsvariablen in die keycloak.json übernommen wird.

Bei allen Keycloak-Parametern müssen json-Sonderzeichen escaped werden, da sonst keine valide keycloak.json erzeugt wird.

Als gesamte Datei

Diese Datei konfiguriert die Anbindung der B2B-Instanz an den keycloak. Folgende Konfiguration wurde für diese Dokumentation verwendet:

{
  "realm": "B2B",
  "auth-server-url": "http://keycloak:8080/auth/",
  "ssl-required": "external",
  "resource": "b2b-tomcat",
  "credentials": {
    "secret": "***"
  },
  "confidential-port": 0
}

Die Datei wird am besten direkt aus der Keycloak Admin-UI exportiert. In Keycloak muss dafür ein passender Client angelegt werden. Dies wird im Keycloak Abschnitt später genauer beschrieben.

Tomcat Classpath Konfiguration

Damit die keycloak.json in weiteren Tomcat Workflows genutzt werden kann, muss sichergestellt sein, dass sie im Classpath verfügbar ist. Wir empfehlen die Datei im Ordner tomcat/conf zu mounten, da dieser bereits zum Classpath des Images gehört.

tomcat_all Verzeichnis

In der docker-compose.yml sind bereits einige tomcat_all Verzeichnisse gemountet.

Hier sind ggf weitere geteilte Verzeichnisse zu hinterlegen, z.B. für Filecrawler/Filewriter (sofern der Tomcat im Docker solche Aufgaben übernehmen soll).

Beim Mounting ist darauf zu achten, dass Verzeichnisstrukturen gewählt werden, die kompatibel zu denen im Customizing definierten Verzeichnispfaden sind.

Für weitere Tips zum mounten vgl. Sie auch den Abschnitt Anbindung der B2B-Indizes

Anbindung der B2B-Indizes

Da die B2B-Instanz (auch die im Docker gestartete) Zugriff auf die Verzeichnisse der Indizes benötigt, sind diese nun in die docker-compose Umgebung anzubinden. Dies erfolgt mit den folgenden Kommandos:

Für Linux:

:/opt/docker/b2b> sudo mount.cifs //[Remote-B2B-Server]/[Pfad zum Volltextindex] /opt/docker/b2b/b2b-tomcat/tomcat_all/index/full -o user=[Benutzername des Remote-B2B-Servers]
:/opt/docker/b2b> sudo mount.cifs //[Remote-B2B-Server]/[Pfad zum Archivindex] /opt/docker/b2b-tomcat/tomcat_all/index/arc -o user=[Benutzername des Remote-B2B-Servers]
:/opt/docker/b2b> sudo mount.cifs //[Remote-B2B-Server]/[Pfad zum CCM-Index] /opt/docker/b2b-tomcat/tomcat_all/index/ccm -o user=[Benutzername des Remote-B2B-Servers]

Für Windows-Systeme sind die Verzeichnisse über s.g. Netzwerklaufwerke einzubinden. Dabei müssen jedoch die Pfade in der docker-compose.yml angepasst werden.

Logging

Wie in der klassischen B2B üblich wird das Log-Verzeichnis über die Global Property B3P_LOG4J_BASE_DIR konfiguriert. Entsprechend muss über die docker-compose volumes das Verzeichnis an die definierte Stelle gemountet werden.

Das Image schreibt die Logs per default mit dem Linux User 5000:5000. Entweder, sie erlauben diesem User Schreibzugriff auf das Log-Verzeichnis, oder sie geben einen alternativen User in docker-compose an:

  b2b:
    image: ${NEXUS}/b2b:2021-02-22
    user: 1000:1000
    ...

Generell empfehlen wir immer das Einrichten des Loggings. Ferner kann es dazu kommen, dass einzelne Komponenten nicht richtig angezeigt werden, wenn das Logging nicht funktioniert.

B2B-UI

Keycloak Konfiguration

Wir empfehlen die Verwendung von Umgebungsvariablen für keycloak.

Die definierten Umgebungsvariablen werden beim Erzeugen des Docker-Containers gesetzt und verwendet, sofern keine keycloak.json-Datei in den Container gemountet wurde.

Bei allen Keycloak-Parametern müssen json-Sonderzeichen escaped werden.

allgemeine Konfiguration

Das Image bringt bereits eine Default nginx.conf & system.json mit. Es ist nicht empfohlen, diese zu überschreiben.

Sie kann aber über die folgenden Umgebungsvariablen individuell angepasst werden:

ENV PORTAL_UI_URL="http://portal-ui:8080"
ENV B2B_URL="http://b2b:8080"
ENV NOTIFICATION_URL="http://notification:8080"
ENV REVISION_URL="http://revision:8080"
ENV AS4_ADDRESS_URL="http://as4-address-service:8080"
ENV SYSTEM_NAME=B2B
ENV BACKGROUND_COLOR="#008ECC"
ENV ACTIVATE_USER_MESSAGES="true"
ENV AS4_STYLE="false"
ENV AS4_B2B_STYLE="false"
ENV AS4_ADDRESS_WRITE_HIDDEN="false"

Die Übersicht zeigt die Default-Werte.

Falls die Marktpartnerverwaltung sich mit dem AS4-Address-Service verbinden soll, ist die Property AS4_STYLE zu aktivieren. Falls sie hingegen die AS4-Beziehungen aus der Extension AS4_RELATIONS laden soll, ist die Property AS4_B2B_STYLE zu setzen.

Falls Sie nicht möchten, dass die AS4-Adresse manuell überschrieben werden kann, setzen Sie die Property AS4_ADDRESS_WRITE_HIDDEN.

Optionale Konfiguration

docker-compose.yml

environment:
    B2B_MESSAGE_MONITOR_DEFAULT_PERIOD: "last-2-hour"  
    B2B_MESSAGE_MONITOR_FULLTEXT_SEARCH_MIN_CHARACTERS: "6"

In der B2B-UI gibt es zwei neue optionale Konfigurationen. Mit B2B_MESSAGE_MONITOR_DEFAULT_PERIOD ist es möglich den Default für das Interval des Datepickers zu setzen. Der Wert muss folgendes Format haben: last-X-hours, X kann von 1 bis 23 gesetzt werden. Möchte man die letzten zwei Stunden sehen, so wäre last-2-hours anzugeben. Damit kann verhindert werden, dass standardmäßig ein zu großer Zeitraum mit zu vielen Nachrichten gesucht wird.

Mit B2B_MESSAGE_MONITOR_FULLTEXT_SEARCH_MIN_CHARACTERS ist es möglich eine Minimumlänge für die Volltextsuche zu definieren. Das heißt, es müssen mindestens so viele Zeichen angegeben werden. Damit wird sichergestellt, dass nicht eine zu allgemeine Volltextsuche abgesetzt wird, die gegebenenfalls die Performance beeinflusst.

Logging

Das access_log und das error_log werden in der nginx.conf definiert.

Damit das Log nicht mit einem weggeworfenen Container verloren geht, kann man das Log auch von außen in den Container mounten. Hierfür sind die Log-Files in den docker-compose/volumes mit anzugeben. Für diese Lösung müssen die Dateien vorher bereits auf dem Docker-Host angelegt und mit geeigneten Berechtigungen versehen sein.

Start docker container (New-UI, B2B)

Mit dem folgenden Kommando können die Container im Docker gestartet werden:

:opt/docker/b2b/> docker-compose up -d

Mit folgendem Kommando können die Container im Docker gestoppt werden:

:opt/docker/b2b/> docker-compose stop

Keycloak

Keycloak Client für die B2B-Docker-Instanz

Für den Client “b2b-tomcat” müssen die Einstellungen wie folgt vorgenommen werden:

Folgende Werte müssen gesetzt sein:

Durch ein Klick auf “Save” werden die Einstellungen gespeichert und die Übersichtsseite des neuen Clients wird angezeigt:

Als Access-Type muss confidential gesetzt werden.

Als Login-Theme kann das nli Thema gewählt werden.

Weitere Anpassungen sind hier nicht vorzunehmen.

Keycloak Client für die B2B-New-UI-Docker-Instanz

Für den Client “b2b-functional-ui” müssen die Einstellungen wie folgt vorgenommen werden:

Folgende Werte müssen gesetzt sein:

Durch ein Klick auf “Save” werden die Einstellungen gespeichert und die Übersichtsseite des neuen Clients wird angezeigt:

Der Standard Flow ist zu aktivieren.

Der Access Type ist auf public zu setzen.

Als Login-Theme kann das nli Thema gewählt werden.

Weitere Anpassungen sind hier nicht vorzunehmen.

Keycloak Rollen & Attribute

Die Konfiguration der benötigten Rollen und Attribute wird hier beschrieben.

UI Komponenten werden nur angezeigt, wenn die entsprechenden Rollen den Usern zugewiesen worden sind.

Mandantenfilterung

Die B2B-UI unterstützt eine Mandantenfilterung. Die Konfiguration wird hier beschrieben. Falls diese konfiguriert ist, werden nur die Nachrichten angezeigt, die zum Mandanten des Users passen.