Dieser Abschnitt beschreibt zunächst den AS4 Systemkontext. Er hilft bei der Installation des AS4-Systems.

Es folgt eine Übersicht über die AS4 Workflows Outbound & Inbound. Diese dienen dem Versand & Empfang von AS4 Nachrichten.

Es gibt einen Abschnitt zum Routingflow. Hier wird beschrieben, wie Nachrichten auf unterschiedliche Queues verteilt werden können.

Es gibt einen Abschnitt zum Fehlerhandling. Hier wird beschrieben, wie Fehler in Deadletter-Queues behandelt werden können.

Zuletzt wird der Pathswitch-Prozess mit seinen Workflows beschrieben.

Systemkontext

Das AS4-System besteht aus mehreren Microservices, die untereinander asynchron per Message-Broker sowie synchron per REST-APIs kommunizieren. Die Services benötigen teilweise SQL-Datenbanken.

Das AS4 System wird mit Mako-Systemen (z.B. die B2B by Practise) asynchron per Message-Broker (RabbitMQ) verbunden. Es empfängt & überträgt Marktübertragungsnachrichten (Edifact) an die Mako-Systeme. (Für die asynchrone Anbindung des B2B-Systems muss ein neuer B2B Microservice genutzt werden: der B2B-Message-Service.)

Das AS4 System kann AS4 Nachrichten von Marktpartnern per AS4 Webservice empfangen. Ebenso kann es AS4 Nachrichten an unterschiedliche Marktpartner per AS4 Webservice senden.

Das AS4-System bietet REST-APIs zur Steuerung. Diese können direkt oder über die Frontends der B2B genutzt werden. Die APIs können über oauth2 abgesichert werden. Hierfür ist ein Authorization Server (Keycloak) zu nutzen.

Das AS4 System setzt zur Zertifikatsverwaltung den FSS ein.

Das AS4 System setzt zur sicheren Verwahrung von privaten Schlüsseln ein HSM ein. Der FSS ist als Proxy vor das HSM geschaltet.

Die obige Grafik stellt folgende Aspekte dar:

• Anbindung Marktpartner
• Anbindung Mako-System (am Beispiel B2B)
• Anbindung Message-Broker
• Anbindung Datenbanken
• Anbindung FSS & HSM

Die obige Grafik stellt folgende Aspekte dar:

• verfügbare REST-APIs
• Anbindung des Frontends
• Absicherung per oauth2 Authorization Server

Aus Gründen der Ausfallsicherheit wird empfohlen, mehrere Instanzen der gleichen Microservices parallel zu betrieben. REST-APIs sollten deshalb jeweils hinter einem Loadbalancer gebündelt werden. Wir empfehlen mindestens die Services hinter Loadbalancer zu packen, deren REST-APIs an der Marktkommunikation beteiligt sind. Dies sind folgende Services:

• FSS
• AS4-Address-Service
• B2B-Message-Service

Standard-Workflows: Empfang & Versand von AS4 Nachrichten

Im Folgenden werden die beiden Workflows für den Empfang und Versand von AS4 Nachrichten beschrieben. Wir unterscheiden:

• AS4 Outbound Workflow: Versand einer AS4 Geschäftsnachricht an einen Marktpartner, sowie der Empfang der zugehörigen Quittung
• AS4 Inbound Workflow: Empfang einer AS4 Geschäftsnachricht von einem Marktpartner sowie der Versand der zugehörigen Quittung

Diese universellen Workflows können für unterschiedliche AS4 Prozesse genutzt werden, beispielsweise für die AS4 Prozesse Marktkommunikation (AS4 ServiceId = https://www.bdew.de/as4/communication/services/MP) oder Pathswitch (AS4 ServiceId = https://www.bdew.de/as4/communication/services/pathSwitch).

Ein genaues Verständnis über die Workflows hilft insbesondere dann, wenn Nachrichten aufgrund von Fehlern in DeadLetter-Queues geroutet werden. Anhand der DeadLetter-Queue kann erkannt werden, an welcher Stelle der Prozess fehlgeschlagen ist. (Zu jeder normalen Queue gibt es eine zugehörige DeadLetter-Queue.)

AS4 Outbound Workflow

Der AS4 Outbound Workflow hat den Versand einer AS4-Geschäftsnachricht zum Ziel. Ein Mandant schickt eine Nachricht an seinen Partner.

Im Folgenden wird der Workflow am Beispiel des AS4 Prozesses Marktkommunikation beschrieben.

Der Workflow kann wie folgt initiiert werden: Das Mako-System überträgt eine Marktübertragungsnachricht.

Mit Abschluss des Workflows wird ein Bericht an das Mako-System übermittelt. Der Bericht enthält neben der Geschäftsnachricht auch die Quittung. Für einen erfolgreichen Versand ist der Erhalt einer positiven Quittung notwendig.

Im Diagramm sind die folgenden Microservices des AS4-Systems als weiße Rechtecke zu erkennen:

• AS4 Outbound-Market-Message-Service
• Crypto-Operations
• AS4-Outbound-Sender
• AS4-Receipt-Service
• AS4-Message-Service

Zur besseren Differenzierung werden teilweise innerhalb der Microservices noch einzelne Komponenten unterschieden.

Im Diagramm werden die Queues des Message-Brokers als flache Zylinder dargestellt. Zu jeder Queue gehört auch immer eine eigene Exchange. Diese werden nicht explizit dargestellt. Der letzte Teil des Queue-Namens gibt die Gruppenbezeichnung an, z.B. .default oder .delivery. Der Name einer Exchange entspricht dem Namen der Queue ohne Gruppenbezeichnung. Beispiel: Exchange as4.outbound und Queue as4.outbound.default.

Folgende Umsysteme sind aufgeführt:

• Marktpartner
• Mako-System

Die Pfeilrichtung zeigt den Datenfluss. Dies bedeutet im Einzelnen:

• ein AMQP Producer zeigt auf die Exchange/Queue
• die Queue zeigt auf ihren AMQP Consumer
• der AS4 Webservice Client zeigt auf den AS4 Webservice Server (Versand der AS4-Geschäftsnachricht)
• der AS4 Webservice Server zeigt auf den AS4 Webservice Client (Rückübertragung der AS4-Quittung)

Der Workflow folgt der Nummerierung. Die Nummern werden im Folgenden erläutert.

1. Marktübertragungsnachricht übertragen

Das Mako-System überträgt asynchron eine Marktübertragungsnachricht sowie zugehörige Metadaten.

Zur Übertragung wird die Exchange as4.outbound.request genutzt.

2. AS4 Nachricht erstellen

Der AS4-Outbound-Market-Message-Service empfängt Marktübertragungsnachrichten & Metadaten asynchron über die Queue as4.outbound.request.default.

Er erstellt auf Basis der Marktübertragungsnachricht eine AS4-Nachricht (zunächst noch unverschlüsselt und noch nicht signiert). Weiterhin ermittelt er den Empfänger mithilfe des AS4-Address-Service.

Die AS4-Nachricht wird asynchron über die Exchange as4.encrypt.sign übergeben.

3. AS4 Nachricht verschlüsseln & signieren

Die AS4-Crypto-Operations empfangen asynchron eine unverschlüsselte & nicht signierte AS4-Nachricht über die Queue as4.encrypt.sign.default.

Die Anwendung verschlüsselt den Anhang und signiert die Nachricht. Hierfür wird auf den FSS zugegriffen.

Die verschlüsselte & signierte AS4-Nachricht wird asynchron über die Exchange as4.outbound übergeben.

4. AS4 Nachricht versenden

Der AS4-Outbound-Sender empfängt asynchron eine verschlüsselte & signierte AS4-Nachricht über die Queue as4.outbound.default.

Die Anwendung sendet die Nachricht per AS4 Soap Webservice an den Empfänger. Die Antwort in Form einer Quittung wird über die gleiche Verbindung empfangen.

Die Geschäftsnachricht sowie ein Versandbericht werden asynchron über die Exchange as4.messages übergeben.

Ein Quittungsbericht und die Quittung (falls vorhanden) wird asynchron über die Exchange as4.verify übergeben.

5. Signatur der Quittung prüfen

Die AS4-Crypto-Operations empfangen die Quittung über die Queue as4.verify.default.

Die Anwendung überprüft die Signatur der Quittung. Hierfür wird auf den FSS zugegriffen.

Die Quittung & der Signatur-Prüfungsbericht werden asynchron über die Exchange as4.receipt.parse übergeben.

6. Quittung validieren

Der AS4-Receipt-Service empfängt Quittung und Bericht über die Queue as4.receipt.parse.default.

Der Service validiert die Quittung: Es wird geprüft, ob die Quittung einen Fehlerbericht enthält. In diesem Fall sprechen wir von einer negativen Quittung, andernfalls von einer positiven Quittung.

Der Service übergibt die Quittung und den Bericht asynchron über die Exchange as4.receipt.

7. Geschäftsnachricht & Quittung synchronisieren

Der AS4-Message-Service empfängt die Geschäftsnachricht über die Queue as4.messages.default. Er empfängt außerdem die Quittung (oder mindestens den Quittungsbericht) über die Queue as4.receipt.default.

Der Service speichert beide Nachrichten in der Datenbank. Nachdem beide Nachrichten eingetroffen sind, wird ein ganzheitlicher Bericht erstellt.

Der ganzheitliche Bericht wird asynchron über die Exchange as4.receipt.outbound übergeben.

8. Versand-Bericht übertragen

Das Mako-System empfängt den ganzheitlichen Bericht des Outbound-Versands asynchron über die Queue as4.receipt.outbound.delivery. Diese Queue beinhaltet nur Berichte über die Prozesse der Marktkommunikation, Berichte über den Pathswitch Prozess werden anders geroutet.

Der Bericht kann sowohl die Geschäftsnachricht, Quittung als auch eine Referenz auf die ursprüngliche Marktübertragungsnachricht enthalten.

AS4 Inbound Workflow

Der AS4 Inbound Workflow ermöglicht den Empfang einer AS4-Geschäftsnachricht. Ein Mandant empfängt eine Nachricht von seinem Partner.

Im Folgenden wird der Workflow am Beispiel des AS4 Prozesses Marktkommunikation beschrieben.

Der Workflow wird durch einen Marktpartner initiiert: Der Marktpartner überträgt eine AS4-Nachricht.

Mit Abschluss des Workflows wird ein Bericht an das Mako-System übermittelt. Der Bericht enthält neben der Geschäftsnachricht auch die Quittung sowie die entschlüsselte Marktübertragungsnachricht.

Im Diagramm sind die folgenden Microservices des AS4-Systems als weiße Rechtecke zu erkennen:

• AS4-Inbound-Endpoint
• Crypto-Operations
• AS4-Receipt-Service
• AS4-Message-Service

Zur besseren Differenzierung werden teilweise innerhalb der Microservices noch einzelne Komponenten unterschieden.

Im Diagramm werden die Queues des Message-Brokers als flache Zylinder dargestellt. Zu jeder Queue gehört auch immer eine eigene Exchange. Diese werden nicht explizit dargestellt. Der letzte Teil des Queue-Namens gibt die Gruppenbezeichnung an, z.B. .default oder .delivery. Der Name einer Exchange entspricht dem Namen der Queue ohne Gruppenbezeichnung. Beispiel: Exchange as4.inbound und Queue as4.inbound.delivery.

Folgende Umsysteme sind aufgeführt:

• Marktpartner
• Mako-System

Die Pfeilrichtung zeigt den Datenfluss. Dies bedeutet im Einzelnen:

• ein AMQP Producer zeigt auf die Exchange/Queue
• die Queue zeigt auf ihren AMQP Consumer
• der AS4 Webservice Client zeigt auf den AS4 Webservice Server (Versand der AS4-Geschäftsnachricht)
• der AS4 Webservice Server zeigt auf den AS4 Webservice Client (Rückübertragung der AS4-Quittung)

Der Workflow folgt der Nummerierung. Die Nummern werden im Folgenden erläutert.

1. AS4 Nachricht empfangen

Ein Marktpartner ruft den AS4 Webservice des AS4-Inbound-Endpoint auf. Er überträgt eine AS4-Nachricht.

Die Anwendung hält die Verbindung offen, um später die Quittung übertragen zu können.

Zunächst übergibt die Anwendung die AS4-Geschäftsnachricht asynchron über die Exchange as4.decrypt.verify.

2. Signatur prüfen & Anhang entschlüsseln

Die AS4-Crypto-Operations empfangen die AS4-Nachricht über die Queue as4.decrypt.verify.default.

Der Anhang wird entschlüsselt, die Signatur überprüft. Hierfür wird auf den FSS zugegriffen.

Die entschlüsselte Marktübertragungsnachricht, die AS4-Geschäftsnachricht sowie der Signatur-Bericht werden asynchron über die Exchange as4.receipt.create übergeben.

3. Quittung erstellen

Der AS4-Receipt-Service empfängt die AS4-Geschäftsnachricht über die Queue as4.receipt.create.default.

Zunächst wird die AS4-Geschäftsnachricht und der Anhang validiert. Anschließend wird eine Quittung erstellt.

Die AS4-Geschäftsnachricht und der entschlüsselte Anhang werden über die Exchange as4.messages übergeben.

Die Quittung wird asynchron über die Exchange as4.sign übergeben.

4. Quittung signieren

Die AS4-Crypto-Operations empfangen die Quittung über die Queue as4.sign.default.

Die Anwendung signiert die Quittung. Hierfür wird auf den FSS zugegriffen.

Die signierte Quittung wird asynchron über die Exchange as4.send.receipt übergeben.

5. Quittung versenden

Der Service AS4-Inbound-Endpoint empfängt die Quittung asynchron über die queue as4.send.receipt.default.

Der Service nutzt die offen gehaltene AS4-Verbindung, um die Quittung zu übermitteln.

Ein Quittungsbericht und die Quittung wird asynchron über die Exchange as4.receipt übergeben.

6. Geschäftsnachricht & Quittung synchronisieren

Der AS4-Message-Service empfängt die Geschäftsnachricht und den zugehörigen entschlüsselten Anhang über die Queue as4.messages.default. Er empfängt außerdem die Quittung (oder mindestens den Quittungsbericht) über die Queue as4.receipt.default.

Der Service speichert beide Nachrichten in der Datenbank. Nachdem beide Nachrichten eingetroffen sind, wird ein ganzheitlicher Bericht erstellt.

Der ganzheitliche Bericht wird asynchron über die Exchange as4.inbound übergeben.

7. Marktübertragungsnachricht & Empfangsbericht übertragen

Das Mako-System empfängt den ganzheitlichen Bericht des Inbound-Empfangs asynchron über die Queue as4.inbound.delivery. Diese Queue beinhaltet nur Berichte über die Prozesse der Marktkommunikation, Berichte über den Pathswitch Prozess werden anders geroutet.

Der Bericht kann sowohl die Geschäftsnachricht, Quittung als auch die entschlüsselte Marktübertragungsnachricht enthalten.

Routingflow

Routing ermöglicht das Filtern von Eingängen in den Queues. Es kann ergänzend angewendet werden, wenn die Nachrichten zur besseren Übersichtlichkeit oder zur Steigerung de Performance auf mehrere Queues verteilt werden sollen.

Im unteren Beispielbild erhält der AS4 Outbound Market Message Service vier Edifact Nachrichten, die für verschiedene Empfänger vorgesehen sind. Für das Routing wurde für die Eigenschaft des Empfängers (Feld partner) ein Filter konfiguriert, der die Werte 9900051000004, 9900051000005 und 9900051000006 (Exchanges) enthält. Der Wert des vierten Empfängers (9900051000007) ist nicht enthalten. Die Nachrichten für die ersten drei Empfänger werden entsprechend der Konfiguration auf die Queues as4.encrypt.sign.990005100000x verteilt, während die Edifact-Nachricht an den Empfänger 9900051000007 auf die Default Queue geroutet wird. Die Nachrichten an die 3 definierten Empfänger werden auch von jeweils einem dezidierten Crypto Operations empfangen.

Nachfolgend filtern bzw. routen die einzelnen Instanzen des Crypto Operations zur Weitergabe an den AS4 Outbound Sender nach dem sector, erkennbar wiederum am Namen der Queues as4.outbound.ELECTRICITY bzw. as4.outbound.GAS.

Da sich der Name der Queue aus der Exchange Bezeichnung und der Gruppe . (Bsp. as4.outbound.9900051000004) bildet, muss der Consumer der Gruppe hinzugefügt werden.

Bei der Konfiguration des Routing (Routingwerte und HeaderValues) muss zwingend die Groß- und Kleinschreibung beachtet werden, bsp. headerValues=GAS; GAS → as4.outbound.GAS; gas → as4.outbound.default.

Fehlerbehandlung

Das AS4 System sorgt dafür, dass möglichst alle bekannten Fehler in das Mako-System geroutet werden. Ein Fehlermonitoring kann somit primär über das Mako System durchgeführt werden. Falls die B2B als Mako-System genutzt wird, kann hierfür der Nachrichtenmonitor genutzt werden. Dieser zeigt beispielsweise negative Quittungen mit einem negativen Bestätigungsstatus an der Geschäftsnachricht an und routet entsprechende Nachrichten in einen Fehlerchannel.

Jede Queue besitzt eine Dead-Letter-Queue, z.B. as4.outbound.default.dlq, in der die fehlgeschlagenen Nachrichten gesammelt werden, die nicht an das Mako-System geroutet werden konnten. Diese Nachrichten müssen manuell überwacht und können bei Bedarf neu gestartet werden. Dies geschieht über die Weboberfläche des Message Brokers.

Die Nachrichten in der DLQ (Dead Letter Queue), beispielsweise die Queue as4.outbound.default.dlq, lassen sich erneut versenden. Im hiesigen Beispiel handelt es sich um den Message Broker RabbitMQ. Dieser ermöglicht leider keine Elementauswahl, sondern erlaubt nur das erneute Starten aller enthaltenen Nachrichten.

Zum Versenden muss das Ziel angegeben werden. Dieses ist im Beispiel die as4.outbound.default Queue.

BDEW AS4 Adresswechsel

Zum besseren Verständnis des folgenden Abschnitts wird auf das Glossar verwiesen. Insbesondere die Begriffe Mandant & Partner sowie Geschäftsnachricht & Quittung sowie AS4-Inbound & Outbound sind sauber zu unterscheiden.

Motivation

Zwei Marktpartner wollen miteinander Marktübertragungsnachrichten per AS4 austauschen.

Der BDEW fordert, dass beide zuvor den Pathswitch-Prozess ausführen.

Pathswitch hilft beiden Marktpartnern, ihre AS4-Verbindung zu testen und AS4-Adressen auszutauschen. Der Prozess alleine stellt jedoch nicht den Austausch der Verschlüsselungszertifikate sicher.

Pathswitch Prozess

Die Marktpartner Blue-Energy und Green-Energy wollen den Pathswitch-Prozess durchführen.

Während des Pathswitch-Prozesses teilen beide Marktpartner ihre AS4-Adressen (als Teil des Signaturzertifikats).

Marktpartner Blue-Energy sendet ein Pathswitch-Request an Marktpartner Green-Energy (beantwortet mit einer Quittung).

Dies erfordert, dass Blue-Energy vorher bereits die AS4-Adresse von Green-Energy kennt.

Der Pathswitch-Request liefert die AS4-Adresse von Blue-Energy an Green-Energy.

Der Marktpartner Green-Energy kann (automatisch) mit einer Pathswitch-Confirmation (beantwortet durch eine Quittung) antworten.

Nur wenn sowohl Request als auch Confirmation mit einer positiven Quittung beantwortet werden, war der Adresswechsel erfolgreich.

Sowohl Request als auch Confirmation enthalten einen leeren Body und keinen Anhang. Beide sind mit einem Zertifikat signiert, welches MPID & AS4-Adresse des Absenders enthält. Sender & Empfänger sind im Head der Nachricht aufgeführt. Darüber hinaus gibt es keinerlei Rückbezug auf den Request innerhalb der Confirmation.

Vorbereitungen zum Pathswitch

Voraussetzungen

Das AS4-System wurde installiert & konfiguriert.

Initialisierung

Mandant anlegen:

• Der Administrator erstellt ein Schlüsselpaar für den Mandanten (z.B. mit Hilfe des CSR-Service).
• Der Administrator erstellt mithilfe einer Sub-CA Zertifikate und speichert diese für den Mandanten im FSS ab (z.B. mithilfe des CSR-Service) (Zertifikat enthält die AS4-Adresse des Mandanten)
• Der Administrator legt die MPID des Mandanten über die REST API des AS4-Address-Service an und aktiviert den Mandanten (z.B. über die AS4-Kommunikationsbeziehungen-UI).

Partnerbeziehung anlegen:

• Der Administrator legt die Mandant-Partner-Beziehung an (z.B. über die Benutzeroberfläche der Marktpartner-Verwaltung).
• Die Beziehung kann erst angelegt werden, nachdem der Mandant angelegt worden ist
• Ein Pathswitch Confirmation wird nur erzeugt, wenn die Beziehung vorher angelegt worden ist.
• Der Administrator hat das Signatur-Zertifikat des Partners (sowie zugehörige Aussteller-Zertifikate) im FSS gespeichert.

Pathswitch Workflows

Es ist zu unterscheiden, ob der Pathswitch Request vom Mandanten oder vom Partner ausgeht. Hieraus ergeben sich zwei unterschiedliche Workflows. Nur einer der beiden Workflows muss abgeschlossen werden, damit der Pathswitch für beide Marktpartner erfolgreich ist.

Die Workflows werden aus Sicht des AS4-Address-Service beschrieben. Er nutzt im Hintergrund die Standard-AS4-Workflows Outbound & Inbound.

Die Workflows enden jeweils mit einer Benachrichtigung des Mako-Systems. Das Mako-System muss wissen, ob der Pathswitch abgeschlossen worden ist, um zu entscheiden, ob Marktübertragungsnachrichten an das AS4-System geroutet oder anderweitig (z.B. per Mail/AS2) verschickt werden sollen.

Workflow: Pathswitch Request vom Mandanten

Der Administrator initiiert den Adresswechsel für den Mandanten (z.B. über die AS4-Kommunikationsbeziehungen-UI).

1. Outbound Request auslösen

Das Frontend löst den Pathswitch-Workflow durch Aufruf der AS4-Address-Service REST API POST /as4-address/pathswitches aus.

Der AS4-Address-Service liefert eine asynchrone Nachricht über die Queue as4.outbound.request.pathswitch an den AS4-Outbound-Market-Message-Service. Ziel ist das Erstellen und Ausliefern eines Pathswitch-Requests Outbound.

2. Outbound Request Quittung erhalten

Der AS4-Message-Service übermittelt ein asynchrones Ereignis über die Queue as4.receipt.outbound.pathswitch an den AS4-Address-Service: Es wurde eine positive Pathswitch-Request-Quittung empfangen.

Es wird ein Partnerbeziehung-Eintrag erstellt, Status: requested.

3. Inbound Confirmation erhalten

Der AS4-Message-Service übermittelt ein asynchrones Ereignis über die Queue as4.inbound.pathswitch an den AS4-Address-Service: Eine positive Pathswitch-Confirmation-Quittung wurde verarbeitet.

Der Partnerbeziehung-Eintrag wird aktualisiert, Status: confirmed.

Es wird ein asynchrones Ereignis über die Queue as4.pathswitch.delivery übermittelt, um das Mako-System zu benachrichtigen.

Workflow: Pathswitch Request vom Partner

Der Partner sendet eine AS4-Pathswitch-Request-Nachricht an den Mandanten.

1. Inbound Request erhalten

Der AS4-Message-Service übermittelt ein asynchrones Ereignis über die Queue as4.inbound.pathswitch an den AS4-Address-Service: Eine positive Pathswitch-Request-Quittung wurde verarbeitet.

Es wird ein Partnerbeziehung-Eintrag erstellt, Status: requested.

Es wird automatisch eine Confirmation ausgelöst: Der AS4-Address-Service liefert eine asynchrone Nachricht über die Queue as4.outbound.request.pathswitch an den AS4-Outbound-Market-Message-Service, Ziel: Erstellen und Bereitstellen einer Pathswitch-Bestätigung für ausgehenden Datenverkehr. (Hierbei wird als actionId https://www.bdew.de/as4/communication/actions/confirmSwitch übergeben.)

2. Outbound Confirmation Quittung erhalten

Der AS4-Message-Service übermittelt ein asynchrones Ereignis über die Queue as4.receipt.outbound.pathswitch an den AS4-Address-Service: Es wurde eine Pathswitch-Confirmation-Quittung empfangen.

Der Partnerbeziehung-Eintrag wird aktualisiert, Status: confirmed.

Es wird ein asynchrones Ereignis über die Queue as4.pathswitch.delivery übermittelt, um das Mako-System zu benachrichtigen.

Nächste Schritte

Bevor Marktübertragungsnachrichten übermittelt werden können, müssen beide Marktpartner die Verschlüsselungszertifikate ihres Partners herunterladen und im FSS speichern. Wir empfehlen dies zu gewährleisten, bevor die Partnerbeziehung angelegt wird.

View Me   Edit Me