AS4 Receipt Service Dokumentation

Der AS4 Receipt Service validiert eingehende Empfangsbestätigungen (Receipts) von Marktpartnern und erstellt Empfangsbestätigungen als Response für erhaltene AS4-Nachrichten.

Features

Feature Property Default Beschreibung
Kryptografie überspringen skipCrypt false Deaktiviert die Anbindung an Crypto Operations (nur für Entwicklung)
Beziehung prüfen (Strom & Gas) checkRelation false Lehnt Nachrichten ohne bestätigte Beziehung per negativem Receipt ab
Beziehung prüfen (nur Gas) checkRelationGas false Lehnt nur Gas-Nachrichten ohne bestätigte Beziehung ab
Beziehung automatisch bestätigen autoConfirmRelation false Bestätigt unbekannte Beziehungen automatisch beim Inbound
Beziehung automatisch bestätigen (nur Strom) autoConfirmRelationElectricity false Bestätigt nur Strom-Beziehungen automatisch
BDEW DocumentType Validierung überspringen validation.bdew-document-type-skip-tenants (leer) Überspringt die BDEW-DocumentType-Validierung für bestimmte Mandanten
Zip Payload zipPayload false Zippt die Nutzlast im eingehenden Fluss
Parallelität Receipt Parse receiptParseMaxConcurrency 50 Maximale Anzahl gleichzeitiger Threads für eingehende Receipts
Parallelität Receipt Create receiptCreateMaxConcurrency 50 Maximale Anzahl gleichzeitiger Threads für Nachrichten, für die ein Receipt erstellt wird
Keycloak spring.profiles.active keycloak-enriched REST-API-Absicherung per OAuth2

Hardware Anforderungen

Eine Service-Instanz erfordert mindestens 1024 MB RAM.

Wir empfehlen 0,6 CPU-Kerne je Instanz.

Logs werden auf die Festplatte geschrieben, entsprechend muss genügend Speicherplatz vorhanden sein.

Abhängigkeiten

Der Service greift auf einen Message-Broker zu, um Nachrichten zu empfangen und zu versenden.

Einfache Konfiguration der as4-receipt-service.properties

Die Kommunikation zwischen den verschiedenen AS4 Services erfolgt über einen Message-Broker.

#=== RabbitMQ Configuration ===#
rabbitmq.host=localhost
rabbitmq.port=5672
rabbitmq.username=guest
rabbitmq.password=guest

Kryptografie überspringen (Entwicklung)

Mit skipCrypt lässt sich die Anbindung an den Crypto Operations Service für Entwicklungszwecke deaktivieren. Default: false.

skipCrypt=false

AMQP Routing Konfiguration

Im Standard-Routing ist keine weitere Konfiguration nötig. Die folgende Tabelle gibt eine Übersicht über alle vom Service genutzten Exchanges und ihre Gegenstellen. Die Default-Queue ergibt sich aus <exchange>.default.

Richtung Property Exchange Default-Queue Gegenstelle Zweck
Consumer receiptParseExchangeName as4.receipt.parse as4.receipt.parse.default Crypto Operations Empfang eingehender Receipts vom Marktpartner zur Validierung
Consumer receiptCreateExchangeName as4.receipt.create as4.receipt.create.default Crypto Operations Empfang eingehender Business Messages zur Receipt-Erzeugung
Producer receiptExchangeName as4.receipt as4.receipt.default AS4 Message Service Persistierung der vom Marktpartner empfangenen Bestätigung
Producer businessMessageExchangeName as4.messages as4.messages.default AS4 Message Service Persistierung der eingehenden Business Message
Producer createdReceiptExchangeName as4.sign as4.sign.default Crypto Operations Signierung der erstellten Empfangsbestätigung
Producer pathswitchConfirmationExchangeName as4.outbound.pathswitch as4.outbound.pathswitch.default AS4 Address Service Bestätigung der Adressänderung an den Marktpartner
Producer relationCreateExchangeName as4.relation.create as4.relation.create.default AS4 Address Service Automatische Anlage einer AS4-Beziehung (siehe autoConfirmRelation)

Consumer-Gruppen anpassen

Für die Consumer-Exchanges kann die Gruppe geändert werden, falls Routing genutzt wird (ansonsten auf default belassen):

receiptParseGroup=default
receiptCreateGroup=default

Producer-Routing nach Header

Für Producer-Exchanges lässt sich das Routing über <exchangeProperty>HeaderName und <exchangeProperty>HeaderValues aktivieren. Nachrichten mit Werten, die nicht in HeaderValues aufgelistet sind, laufen weiterhin über die Default-Route. Die Gegenstelle muss entsprechend eingerichtet werden.

Mögliche HeaderName-Werte:

  • tenant: ILN Nummer des Senders
  • partner: ILN Nummer des Empfängers
  • sector: GAS, ELECTRICITY

Beispiel für receiptExchangeName:

receiptExchangeName=as4.receipt
receiptHeaderName=tenant
receiptHeaderValues=9907647000008,9903111000003

Validierung

Um zu einer eingehenden Nachricht ein Receipt zu erstellen, wird die Nachricht vorerst validiert. Zur Validierung sind die folgenden Parameter erforderlich. Wichtig ist hier, für die Variable expectedSystems die Receiver, also die Mandanten selbst einzutragen, damit geprüft werden kann, ob der Marktpartner auch an den richtigen Mandanten geantwortet hat. Um die Validierung auf den Receiver/Mandanten zu überspringen, kann der Wert leer gelassen, oder die Property entfernt werden.

Die weiteren Prüfungskategorien sind AS4 Protokoll spezifisch und sollten von einem Fachmann verändert werden. ServiceId gibt dabei den Service aus dem Header der AS4 Message an und ActionId die Action aus dem Header.

expectedSystems=9907647000008,9903111000003,9900051000002

expectedElectricityServiceIds=https://www.bdew.de/as4/communication/services/MP,https://www.bdew.de/as4/communication/services/pathSwitch,http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/service,https://www.bdew.de/as4/communication/services/FP
expectedElectricityActionIds=http://docs.oasis-open.org/ebxml-msg/as4/200902/action,https://www.bdew.de/as4/communication/actions/requestSwitch,https://www.bdew.de/as4/communication/actions/confirmSwitch,http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/test

expectedGasServiceIds=A02
expectedGasActionIds=http://docs.oasis-open.org/ebxml-msg/as4/200902/action,http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/test

Neben den fachlichen Paramtern, wird ebenfalls validiert, ob das Receipt einen negativen StatusCode hat, oder Probleme bei der Signierung, Ver- und Entschlüsselung vorliegen. Das Receipt wird mit der jeweiligen Fehlermeldung an den as4-message-service gesendet und dort persistiert. Vorliegende Fehler lassen sich im Nachrichtenmonitor einsehen.

Validierung BDEW Document Type

Die Validierung des BdewDocumentType basiert auf der serviceId der AS4-Nachricht. Sie wird übersprungen, wenn mindestens eine der folgenden Bedingungen erfüllt ist:

Mindestens ein PartyIdType ist urn:oasis:names:tc:ebcore:partyid-type:unregistered:BAHN. Der Mandant ist in validation.bdew-document-type-skip-tenants konfiguriert. Standardmäßig ist die Validierung für alle Mandanten aktiv. Um sie zu deaktivieren, können Mandanten-IDs als kommagetrennte Liste hinterlegt werden.

Beispiel-Konfiguration:

validation.bdew-document-type-skip-tenants=990000000001,19000000001,98000000001

Validierung Relation: Strom und Gas

Mit der Eigenschaft checkRelation=true werden Marktnachrichten per negativem Receipt abgelehnt, wenn eine unbestätigte oder keine Beziehung vorliegt. Zudem werden Pathswitch- und Pingnachrichten per negativem Receipt abgelehnt, wenn keine Beziehung vorliegt.

Um eine Beziehung zu validieren, muss außerdem ein API-Aufruf beim as4-Adress-Service erfolgen, um zu prüfen, ob die Beziehung bereits bestätigt ist oder nicht. Standardmäßig ist AddressServiceUrl leer.

addressServiceUrl=http://as4-address-service:8080/aep-as4-address-service

Validierung Relation: Gas

Mit der Eigenschaft checkRelationGas=true werden Gas-Marktnachrichten per negativem Receipt abgelehnt, wenn eine unbestätigte oder keine Beziehung vorliegt. Stromnachrichten werden nicht abgelehnt.

Um eine Beziehung zu validieren, muss außerdem ein API-Aufruf beim as4-Adress-Service erfolgen, um zu prüfen, ob die Beziehung bereits bestätigt ist oder nicht. Standardmäßig ist AddressServiceUrl leer.

addressServiceUrl=http://as4-address-service:8080/aep-as4-address-service

Hinweis: Für Systeme, die den Pathswitch-Prozess für Gas-Nachrichten verwenden, empfehlen wir initial checkRelationGas zu verwenden, bis alle Beziehungen über den Pathswitch-Prozess bestätigt worden sind.

Beziehung automatisch bestätigen

Es ist möglich eine bisher unbekannte oder unbestätigte Beziehung automatisch während der Nachrichtenverarbeitung (Inbound außer ping/pathswitch) zu bestätigen. Nachdem die Beziehung bestätigt wurde, können Nachrichten dieser Beziehung verarbeitet werden.

Dieses Feature kann aktiviert werden, indem der folgende Parameter auf „true“ gesetzt wird. Standardmäßig ist er auf „false“ gesetzt.

autoConfirmRelation=true

Um eine Beziehung automatisch zu bestätigen, muss außerdem ein API-Aufruf beim as4-Adress-Service erfolgen, um zu prüfen, ob die Beziehung bereits bestätigt ist oder nicht. Standardmäßig ist AddressServiceUrl leer.

addressServiceUrl=http://as4-address-service:8080/aep-as4-address-service

Zusätzlich wird der Producer-Exchange relationCreateExchangeName verwendet (siehe AMQP Routing Konfiguration).

Beziehung automatisch bestätigen: Strom

Um die automatische Bestätigung von Beziehungen nur für Strom-Nachrichten zu aktivieren, ist anstatt der Eigenschaft autoConfirmRelation, die Eigenschaft autoConfirmRelationElectricity auf true zu setzen.

Hinweis: Für Systeme, bei denen Gas-Beziehungen noch über den Pathswitch-Prozess bestätigt werden sollen, empfehlen wir autoConfirmRelationElectricity anstelle von autoConfirmRelation, damit Gas-Beziehungen nicht automatisch bestätigt werden.

Max Concurrency - Parallelität

Für jeden Consumer ist es möglich die Eigenschaft max-concurrency zu setzen. Diese definiert die maximale Anzahl von gleichzeitigen Verarbeitungsthreads, die für einen Consumer gestartet werden können. Der Default steht für jeden Consumer auf 50.

receiptParseMaxConcurrency=50
receiptCreateMaxConcurrency=50

Keycloak

Bei Bedarf kann die REST-API per Keycloak abgesichert werden.

Zip Payload

Die Nutzlast/der Anhang im eingehenden Fluss wird genau dann gezippt, wenn zipPayload=true konfiguriert ist (Standardwert: false).

zipPayload=false

Falls dieses Feature genutzt wird, muss dies mit der technischen Mako abgestimmt werden. Falls Sie die B2B nutzen, können Sie die gleiche Property am B2B-Message-Service konfigurieren.

REST API Dokumentation

Die API bietet Server-Health Informationen an.

Der Port lässt sich über folgende Property konfigurieren: server.port=8080

Swagger

Die Beschreibung der REST API lässt sich, im Fall einer Docker Installation, unter

http://host.docker.internal:8095/aep-as4-receipt-service/swagger-ui/index.html

oder unter

http://localhost:8080/aep-as4-receipt-service/swagger-ui/index.html

finden.

Anhang: Gesamtkonfiguration

Folgende Konfiguration reicht in einem Standard-System aus: application.properties:

#=== RabbitMQ Configuration ===#
rabbitmq.host=rabbitmq3
rabbitmq.port=5672
rabbitmq.username=guest
rabbitmq.password=${RABBITMQ_PASSWORD}

#=== FSS ===#
fss.server.api.url=http://fss:2222/fss/api/v1

#=== Feature Flags ===#
skipCrypt=false
zipPayload=false

#=== Relation Validation ===#
checkRelation=false
autoConfirmRelation=false
addressServiceUrl=http://as4-address-service:8080/aep-as4-address-service

Allgemeine Hinweise zur Konfiguration finden Sie hier.

View Me   Edit Me