Freigeben über

BTARN-Empfangspipeline

  • Artikel

Microsoft BizTalk Accelerator for RosettaNet (BTARN) führt den RnIF-Nachrichtenempfang (RosettaNet Implementation Framework) mit der RNIFReceive-Pipeline (RNIFReceive.btp) durch. Die Empfangspipeline enthält die folgenden Komponenten:

  • ReceiveMessageNonRepudiate

  • RNMimeDecoder (MIME-Präprozessor/-Decoder)

  • RNDAsm (XML-Disassembler)

  • RNPartyRes (Komponente zum Auflösen der Partei)

  • MessageUpdater

ReceiveMessageNonRepudiate

Diese Komponente speichert die empfangene Nachricht in der Tabelle MessageStorageIn. Diese Komponente führt die von den RNIF-Standards erforderliche Verarbeitung ohne Ablehnung durch.

RNMimeDecoder

Diese Komponente basiert auf dem nativen BizTalk Server MIME-Präprozessor/Decoder. RNMimeDecoder fügt die folgende Funktionalität für die RNIF-Verarbeitung hinzu:

  • Für RNIF 2.01 entschlüsselt der Dienstinhalt und die Anlagen, sofern sie vorhanden sind.

  • Für RNIF 1.1 werden der 8-Byte-Header und der getrennte Signaturheader am Ende der Nutzlast verarbeitet.

    Weitere Informationen zum nativen BizTalk Server Präprozessor/Decoder finden Sie unter "MIME/SMIME Decoder Pipeline Component" in BizTalk Server Hilfe.

RNDAsm

Diese Komponente basiert auf dem nativen BizTalk Server XML-Disassembler. RNDAsm fügt die folgende Funktionalität für die RNIF-Verarbeitung hinzu:

  • Wenn ein eingehendes Dokument über einen DOCTYPE-Header verfügt, generiert diese Komponente daraus einen Namespace und verschiebt alle Knoten im eingehenden Dokument in diesen Namespace.

  • Führt eine Nachrichtenkorrelation aus, um zu bestimmen, ob es sich bei einer eingehenden Nachricht um ein Duplikat handelt, und generiert eine Fehlermeldung, wenn die Nachricht ein Duplikat ist.

  • Speichert Anlagen als zusätzliche Teile der Nachricht.

  • Erhöht Nachrichteneigenschaften.

    Weitere Informationen zum nativen BizTalk Server Disassembler finden Sie unter "XML Disassembler Pipeline Component" in BizTalk Server Hilfe.

RNPartyRes

Diese Komponente basiert auf der nativen BizTalk Server-Parteiauflösungskomponente. RNPartyRes fügt die folgende Funktionalität für die RNIF-Verarbeitung hinzu:

  • Ordnet das Absenderzertifikat zu, wenn die eingehende Nachricht bei einer BizTalk-Partei signiert ist. Wenn die eingehende Nachricht nicht signiert ist und die Handelspartnervereinbarung dies zulässt, ruft diese Komponente die Absenderpartei aus dem Übermittlungsheader für RNIF 2.01 oder dem Serviceheader für RNIF 1.1 ab.

  • Überprüft, ob der Absender vorhanden ist und dass der Absender über eine Handelspartnervereinbarung mit dem Home-organization verfügt.

    Weitere Informationen zur lösungsbasierten BizTalk Server-Lösungskomponente finden Sie unter "Party Resolution Pipeline Component" in BizTalk Server Hilfe.

MessageUpdater

Diese Komponente fügt die folgende Funktionalität für die RNIF-Verarbeitung hinzu:

  • Updates die Tabelle MessageStorageIn mit Details zu PIP-Code, PIP-Version, Quellpartei, Zielpartei und Nachrichtennachverfolgungs-ID der Von der ReceiveMessageNonRepudiate-Komponente gespeicherten Wire Message-Nachricht.

  • Wenn die PIP keine Ablehnung erfordert, markieren Sie den Datensatz zum Löschen, und legen Sie fest ToBePurged = True.

Nachrichtenfluss

Der Nachrichtenfluss durch die BTARN-Empfangspipeline lautet wie folgt:

  1. Der HTTP-Adapter empfängt ein RNIF 1.1-Objekt oder eine RNIF 2.01-Geschäftsnachricht über HTTP POST.

  2. Wenn der Adapter die Nachricht erfolgreich empfängt, extrahiert der Adapter das RosettaNet-Objekt oder die Geschäftsnachricht und leitet sie an die Empfangspipeline weiter.

  3. Wenn das Objekt oder die Geschäftsnachricht signiert ist, entfernt der MIME-Präprozessor/Decoder die Signatur.

  4. Wenn die Signatur gültig ist, liest der Disassembler die Präambel.

  5. Wenn es sich bei der Nachricht um eine Aktionsmeldung handelt und keine Ablehnung erforderlich ist (die Einstellung Nicht zurückweisen von Ursprung und Inhalt in den Prozesskonfigurationseinstellungen ist True), berechnet und speichert der Decoder den Digest.

  6. Der Disassembler überprüft die Präambel (mit MsG-Richtlinien (Message) und das Präambelschema in den globalen Variablen).

  7. Für RNIF 2.01 liest der Disassembler den Übermittlungsheader und überprüft den Header mithilfe der MSG-Richtlinien und des Übermittlungsheaderschemas in den globalen Variablen.

  8. Für RNIF 2.01 extrahiert der Disassembler die Partnerinformationen aus dem Übermittlungsheader und überprüft die Signatur, um zu überprüfen, ob sie dem Partner gehört.

  9. Wenn die Nutzlast für RNIF 2.01 verschlüsselt ist, entschlüsselt der Decoder den Nutzlastcontainer.

  10. Der Disassembler liest den Dienstheader und überprüft den Header mithilfe der MSG-Richtlinien und des Dienstheaderschemas in den globalen Variablen.

  11. Für RNIF 1.1 extrahiert der Disassembler die Partnerinformationen aus dem Dienstheader und überprüft die Signatur, um zu überprüfen, ob sie dem Partner gehört.

  12. Der Disassembler prüft, ob der Partner für das PIP autorisiert ist. Andernfalls antwortet der Disassembler bei Bedarf auf einen HTTP POST mit einer HTTP 403-status-Nachricht und postet einen Fehler.

  13. Wenn es sich bei der Nachricht um eine signierte Aktionsnachricht handelt und Nicht-Zurückweisung von Ursprung und Inhalt auf Truefestgelegt ist, behält die ReceiveMessageNonRepudiate-Komponente die ursprüngliche Nachricht in der Tabelle MessageStorageIn bei.

  14. Wenn die Nachricht eine signierte Signalnachricht ist und Non-Repudiation Required auf Truefestgelegt ist, behält die ReceiveMessageNonRepudiate-Komponente die Signalnachricht in der Tabelle MessageStorageIn bei.

  15. Wenn die Nachricht in der Tabelle MessageStorageIn zur Nicht-Ablehnung beibehalten wurde, aktualisiert der MessageUpdater die MessageStorageIn-Tabelle mit Eigenschaften der Prozesskonfiguration der Nachricht.

  16. Wenn es sich bei der Nachricht um eine Aktionsnachricht handelt, die ein Duplikat einer zuvor verarbeiteten Aktionsnachricht ist, sendet BTARN einen Fehler.

  17. Bei RNIF 2.01 entschlüsselt der Decoder die Nutzlast, wenn die Aktionsnachricht verschlüsselt ist und eine Übereinstimmung zwischen den Anforderungen an die HTTP-Synchronizität und pip-Synchronizität besteht.

  18. Der Disassembler liest den Dienstinhalt und überprüft ihn mithilfe der MSG-Richtlinien und des Schemas.

  19. Für RNIF 2.01 überprüft der Disassembler, ob das Manifest gültig ist und die Inhalts-ID vorhanden ist.

  20. Für RNIF 2.01 liest der Disassembler alle Anlagen.

  21. BTARN leitet die RosettaNet-Header, Dienstinhalte und Anlagen an den öffentlichen Prozess weiter.

Weitere Informationen

Nachrichtenverarbeitung in BTARN