Benötigt werden hierzu drei verschiedene Azure-Komponenten:
- Einen Integration Account zum Speichern der AS2Zertifikate
- Einen Key Vault zum Speichern das Private Keys
- Logic Apps zum versenden bzw. empfangen der Nachrichten
Standardmäßig wird zur AS2-Kommunikation ein Mailzertifikat benötigt. Im Falle von Azure braucht man den öffentlichen Teil als .cer und den Private Key als .pfx-Datei.
Im Integration Account wird unter „Certificates“ der öffentliche Teil hochgeladen.
Zum Erstellen des Private Certificates muss der Private Key in den Key Vault hochgeladen werden.
Mit dem gespeicherten Private Key kann nun auch das Private Certificate in den Integration Account geladen werden. Macht man dies das erste Mal bekommt man vermutlich folgenden Fehler. Ursache hierfür ist, dass die Logic Apps keine Berechtigungen auf den Key Vault besitzen. Um diesen Fehler zu beheben speichert man sich die GUID des Service Principals (in diesem Fall „7cd684f4-****-…..).
Im Key Vault muss nun unter „Access Policies“ ein Eintrag für die Logic Apps angelegt werden und anschließend die richtigen Berechtigungen verteilt werden.
Mit den richtigen Berechtigungen für die Logic Apps lässt sich nun auch das Private Certificate hochladen. Hierzu muss das öffentliche Zertifikat (.cer) ausgewählt werden und den im Key Vault gespeicherten Private Key.
Als nächstes müssen die AS2- Identities für das AS2-Agreement im Integration Account angelegt werden.
Zwischen den beiden Identities kann nun ein AS2-Agreement aufgezogen werden.
Azure bietet hierzu alle Einstellungsmöglichkeiten, die man auch aus dem BizTalk kennt.
Sind sowohl Zertifikate hochgeladen, als auch die Partner und Agreements im Integration Account angelegt können die Logic Apps angelegt werden. Möchte man eine valide AS2-Empfangsstelle bereitstellen wird die Empfangs-Logic App aufgebläht, da man alle drei Antwort-Möglichkeiten abdecken muss:
- Kein MDN
- Synchrone MDN
- Asynchrone MDN
Im Minimum sieht die Logic App dann so aus:
Die Empfangsseite kann dafür generisch für alle anzuhängenden Partner erstellt werden. Das Decode AS2 Shape löst selber das passende Agreement aus dem Integration Account auf.
Mit Hilfe der Output-Properties des Decode Shapes lässt sich der Logik-Baum aufspannen. (MDN Expected und MDN-Type)
Zum Senden des Asynchronen-MDN’s werden folgende Felder benötigt.
{
"inputs": {
"method": "POST",
"uri": "@body('Decode_AS2_message')?['OutgoingMdn']?['ReceiptDeliveryOption']",
"headers": "@body('Decode_AS2_message')?['OutgoingMdn']?['OutboundHeaders']",
"body": "@body('Decode_AS2_message')?['OutgoingMdn']?['Content']"
}
}
Wichtig ist auch, dass man um die ganze Logik einen Code aufspannt, und auch im negativen Fall einen http Response versendet.
Die Versandseite sieht wie folgt aus: In der Regel würde man den Trigger für diese Logic App auf ein File-Verzeichnis legen, zur Simulation wird hier ein Recurrence Trigger verwendet und der Nachrichteninhalt in einer Variablen gesetzt.
Beim Versenden muss angeben werden, von welchem Partner an welcher gesendet werden soll. Das Shape schaut dann automatisch in den Integration Account und versucht das Agreement hierzu aufzulösen. Die Eingabe über Textfelder erlaubt dafür, auch diesen Teil generisch zu programmieren.
Beim Versenden via http sind neben der eigentlichen AS2-Nachricht auch die OutboundHeaders nötig, die das Encode Shape liefert.
Die HTTP-Response mit der die Gegenseite antwortet, muss auch wieder durch das Decode AS2-Shape verarbeitet und über das Feld „MdnStatusCode“ ermittelt werden, ob die Nachricht angenommen wurde.
Dieser Technik-Tipp kommt von Ben, QUIBIQ Stuttgart