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