Die grundlegende Struktur einer AS2-Nachricht umfasst das MIME-Format in einer HTTP-Nachricht mit zusätzlichen AS2-spezifischen Headern. Die Art der Nachricht unter den HTTP-, AS2- und MIME-Headern hängt vom Typ der Nachricht ab:
Signiert : Wenn die Nachricht signiert ist, wird um die Dokumentnutzlast ein Signaturwrapper hinzugefügt.
Komprimiert : Wenn die Nachricht komprimiert ist, wird ein Komprimierungswrapper um die Dokument- und Signaturnutzlasten hinzugefügt.
Verschlüsselt : Wenn die Nachricht verschlüsselt ist, wird ein Verschlüsselungswrapper um die Dokument-, Signatur- und Komprimierungsnutzlasten hinzugefügt.
In der untenstehenden Tabelle wird die Nachrichtenstruktur einer AS2-Nachricht in Abhängigkeit von Verschlüsselung, Signatur und Komprimierung veranschaulicht.
Wenn die Dokumentnutzlast mehrere Dokumenten umfasst, werden diese in einem mehrteiligen/verwandten MIME-Umschlag gespeichert. Eine Beschreibung hierzu finden Sie in RFC 2387. Mit einem MIME-Header vom Typ "Content-Disposition" kann der Dateiname der einzelnen Dokumente innerhalb der Nachricht angegeben werden.
In der untenstehenden Tabelle wird die Nachrichtenstruktur einer AS2-Nachricht mit mehreren Anlagen auf der Grundlage der Optionen für Nachrichtenverschlüsselung, Signatur und Komprimierung veranschaulicht.
Zu den Kontexteigenschaften für das Verarbeiten von AS2-Nachrichten zählen Eigenschaften, die höher gestuft werden können, sowie Eigenschaften, die nicht öffentlich verfügbar gemacht werden, die jedoch in angehaltenen und nachverfolgten Nachrichten angezeigt werden können. Eine Liste der AS2-Kontexteigenschaften finden Sie unter AS2-Kontexteigenschaften.
AS2-Header
Die AS2-Header in AS2-Nachrichten beschreiben die empfangende und die sendende Partei. Zudem werden damit die Informationen bereitgestellt, die die empfangende Partei zum Senden einer MDN-Antwort benötigt. Die empfangende Partei verwendet die MDN-Header, es sei denn, die Eigenschaft Vereinbarungseinstellungen für Validierung und MDN anstelle von Nachrichtenheader verwenden ist in der AS2-Vereinbarung ausgewählt, oder wenn die Informationen in den Vertragseigenschaften nicht verfügbar sind.
Eine AS2-Nachricht wird eindeutig durch die Kontexteigenschaften AS2-From-Header, AS2-To-Header und MessageId beschreiben. Zudem wird damit eine MDN-Nachricht der AS2-Nachricht zugeordnet, deren Antwort sie darstellt.
Diese Header sind in der folgenden Tabelle (in alphabetischer Reihenfolge) aufgeführt:
AS2-Header
Erforderlich/Optional
Werte
AS2-Version
Optional
"1.1"
AS2-From
Erforderlich
Name der Firma, die die AS2-Nachricht gesendet hat.
Werte: Zeichenfolge in ASCII (Printable)-Codierung mit einer Länge von 1 bis 128 Zeichen
AS2-To
Erforderlich
Name der Firma, an die AS2-Nachricht gesendet wurde.
Werte: Zeichenfolge in ASCII (Printable)-Codierung mit einer Länge von 1 bis 128 Zeichen
AS2-Text
Erforderlich
Text (in diesem Header in der Nachricht)
Werte: Zeichenfolge in ASCII (Printable)-Codierung mit einer Länge von 1 bis 128 Zeichen
Disposition-Notification-To
Erforderlich
Fungiert (sofern vorhanden) als Anforderung zum Zurückgeben einer MDN. Wenn er von einem Receipt-Delivery-Option-Header begleitet wird, handelt es sich um die Anforderung einer asynchronen MDN. Andernfalls handelt es sich um die Anforderung einer synchronen MDN.
Wenn dieser Header nicht vorhanden ist, ist keine MDN erforderlich.
Wert: eine E-Mail-Adresse, die vorhanden sein muss. Damit darf jedoch nicht angegeben werden, an welche Adresse die MDN zurückgegeben werden soll. Die E-Mail-Adresse muss von der empfangenden Anwendung ignoriert werden, und es darf keine Verletzung der Adresssyntax gemeldet werden.
EDIINT-Funktionen
Erforderlich
Gibt die vom Ursprungssystem unterstützten Funktionen an. BizTalk gibt mithilfe dieses Headers die Unterstützung mehrerer Anlagen an.
Wert: "MA"
Receipt-Delivery-Option
Erforderlich
Gibt die URL an, an die die MDN gesendet werden soll. Wenn der Receipt-Delivery-Option-Header vorhanden ist, stellt Disposition-Notification-To die Anforderung einer asynchronen MDN dar. Receipt-Delivery-Option muss immer von Disposition-Notification-To begleitet werden.
Wenn Receipt-Delivery-Option nicht vorhanden ist, während Disposition-Notification-To vorhanden ist, fungiert Disposition-Notification-To als Anforderung einer synchronen MDN.
Werte: eine URL-Zeichenfolge.
signed-receipt-protocol
(in Disposition-Notification-Options)
Optional
Wenn der Wert "pcks7-signature" festgelegt ist, wird eine signierte Bestätigung durch die empfangende Partei angefordert. Außerdem wird damit das Format angegeben, in dem die signierte Bestätigung an die anfordernde Partei zurückgegeben werden soll.
Werte: optional, pcks7-signature
signed-receipt-micalg
(in Disposition-Notification-Options)
Optional
Eine Liste der von der anfordernden Partei bevorzugten MIC-Algorithmen für die Signierung der zurückgegebenen Bestätigung. Die Liste der MIC-Algorithmen ist von der empfangenden Partei von links nach rechts zu berücksichtigen.
Werte: optional, MD5 oder SHA1
Für eingehende Nachrichten werden die Werte von Signed-Receipt-Protocol und Signed-Receipt-MIC-Algorithm in den AS2-Vereinbarungseigenschaften von den Empfangspipelines AS2EdiReceive und AS2Receive überprüft.
Für ausgehende AS2-Nachrichten füllen die Sendepipelines AS2EdiSend und AS2Send die obigen AS2-Header mit Werten auf, die in der AS2-Vereinbarung eingegeben wurden (mit Ausnahme der AS2-Version, die als 1.1 hartcodiert ist).
MDN-Anforderung
Eine Anforderung, dass die empfangende Partei eine Nachrichten-Benachrichtigungsdisposition (Message Disposition Notification, MDN) zurückgibt, erfolgt durch Einbinden des folgenden Headers in die zu sendende Nachricht:
Mit der E-Mail-Adresse wird nicht angegeben, an welche Adresse die MDN zurückgegeben werden soll. Der Wert muss von empfangenden Anwendungen ignoriert werden, und es darf kein Fehler zu Verletzungen der Adresssyntax ausgegeben werden.
Möchten Sie erfahren, wie Sie elektronische Dokumente in Business Central senden und empfangen? In diesem Modul wird die für das Senden elektronischer Dokumente erforderliche Einrichtung beschrieben. Anschließend wird veranschaulicht, wie elektronische PEPPOL-Dokumente mit und ohne Anbieter gesendet und empfangen werden.