Freigeben über

Vereinbarungsauflösung, Schemaerkennung und Autorisierung für empfangene EDI-Nachrichten

  • Artikel

Wenn BizTalk Server eine EDI-Nachricht empfängt, führt die EDI-Empfangspipeline Such-, Schemaermittlungs- und Autorisierungsprozesse für Handelspartnervereinbarungen durch, um zu bestimmen, wie die Nachricht verarbeitet werden soll.

Vereinbarungsauflösung

Die EDI-Empfangspipeline führt die Auflösung des Handelspartnervertrags aus, indem mithilfe mehrerer Schritte ermittelt wird, ob eine Übereinstimmung zwischen Headerfeldern in der Nachricht und Eigenschaften in der Vereinbarungsdefinition vorliegt. Sobald BizTalk Server die Vereinbarung festgelegt hat, bestimmt es das Dokumentschema, das für den Austausch gilt (siehe unten). Zu diesem Zweck werden die Eigenschaften verwendet, die der betreffenden Vereinbarung zugeordnet sind, sowie das relevante Schema zum Überprüfen und Verarbeiten der empfangenen Nachricht.

Um die Vereinbarung zu lösen, gehen BizTalk Server wie folgt vor:

  1. Auflösen der Vereinbarung durch Herstellen der Übereinstimmung des Absenderqualifizierers und -bezeichners und des Empfängerqualifizierers und -bezeichners im Austauschheader mit den Angaben in den Eigenschaften einer Vereinbarung.

  2. Wenn Schritt 1 nicht erfolgreich ist, Auflösen der Vereinbarung durch Herstellen der Übereinstimmung nur des Absenderqualifizierers und -bezeichners im Austauschheader mit den Angaben in den Eigenschaften einer Vereinbarung. Da der erste Schritt nicht erfolgreich war, kann davon ausgegangen werden, dass BizTalk Server die Nachricht empfängt. Daher versucht BizTalk Server, den Empfängerqualifizierer und -bezeichner wie folgt zuzuordnen:

    • Werte "BT" und "HostX12Recvr" (für X12-codierte Nachrichten) und

    • Werte "BT" und "HostEdifactRecvr" (für EDIFACT-codierte Nachrichten).

    Wichtig

    • BizTalk Server 2013 R2, 2013 und 2010: Die Felder ISA5, ISA6, ISA7, ISA8, UNB2.1, UNB2.2, UNB3.1 und UNB3.2 sind in den Vertragseinstellungen obligatorisch.
      • BizTalk Server 2009 und 2006 R2: Die Felder ISA7, ISA8, UNB3.1 und UNB3.2 sind in den Parteieneinstellungen nicht obligatorisch. Wenn die Felder leer sind, bietet die EDI-Engine eine Lösung basierend auf den Werten von ISA5 und ISA6, UNB2.1 und UNB2.2.
      • Für die Unterstützung der Auflösungen aus BizTalk Server 2009 und 2006 R2 sowie neueren Versionen von BizTalk Server werden die hartcodierten IDs (HostX12Recvr und HostEdifactRecvr) und Qualifizierer (BT) eingeführt.
      • Ihre EDIFACT-Nachrichten sollten den UNECE-Richtlinien für Nachrichtensyntax und -regeln entsprechen.

  3. Wenn Schritt 2 nicht erfolgreich ist, werden die Eigenschaften der Ausweichvereinbarung verwendet.

    Im ersten Schritt verwendet BizTalk Server für X12 die folgenden Werte, um die Übereinstimmung herzustellen:

  • "ISA05" (Absenderqualifizierer)

  • "ISA06" (Absenderbezeichner)

  • "ISA07" (Empfängerqualifizierer)

  • "ISA08" (Empfängerbezeichner)

    Für EDIFACT verwendet BizTalk Server die folgenden Werte, um die Übereinstimmung herzustellen:

  • "UNB2.1" (Absenderbezeichner)

  • "UNB2.2" (Absenderqualifizierer)

  • "UNB3.1" (Empfängerbezeichner)

  • "UNB3.2" (Empfängerqualifizierer)

    Die für die Übereinstimmung verwendeten Vereinbarungseigenschaften werden auf der Seite Bezeichner der Registerkarten richtungsspezifische Vereinbarung des Dialogfelds Vereinbarungseigenschaften definiert.

    Diese vier empfänger- und absenderseitigen Eigenschaften identifizieren den Handelspartnervertrag eindeutig. Das Verwenden der vier Eigenschaften verleiht Ihnen eine größere Flexibilität bei der empfängerseitigen Verarbeitung. Diese Methode der Vereinbarungsauflösung ermöglicht z. B. das Senden von Bestätigungen an mehrere Parteien, ohne mehrere Sendeports erstellen zu müssen.

    Wenn BizTalk Server die Vereinbarung nicht mit allen vier Absender- und Empfängerqualifizierern und Bezeichnern auflösen kann, wird versucht, die Vereinbarung nur mithilfe des Absenderqualifizierers und -bezeichners aufzulösen. Für X12 handelt es sich um die Felder "ISA05" und "ISA06"; für EDIFACT handelt es sich um die Felder "UNB2.1" und "UNB2.2". Wie bei einer Übereinstimmung der Absender- und Empfängereigenschaften gleicht BizTalk Server die Werte im Austauschheader mit den Vereinbarungseigenschaften ab, die auf der Seite Bezeichner der Registerkarten für richtungsspezifische Vereinbarung des Dialogfelds Vereinbarungseigenschaften definiert sind. Wenn nur der Absenderqualifizierer und der Bezeichner zum Auflösen der Vereinbarung verwendet werden, sollten der Empfängerqualifizierer und der Bezeichner auf der Registerkarte bidirektionale Vereinbarung des Dialogfelds Vereinbarungseigenschaften nicht definiert sein.

    Wenn keine Vereinbarung gefunden wird, verwendet BizTalk Server die Fallback-Handelspartnervereinbarung, es sei denn, die Porteinstellung erfordert eine Authentifizierung. Wenn die Porteinstellung eine Authentifizierung erfordert (wenn entweder Nachrichten löschen, wenn die Authentifizierung fehlschlägt , oder Nachrichten beibehalten, wenn die Authentifizierung fehlschlägt ) auf der Seite Allgemein der Eigenschaften des Empfangsports ausgewählt ist, ist eine Vereinbarung für jeden Austausch erforderlich, der vom Empfangsport empfangen wird. In diesem Fall ist die Verwendung der Eigenschaften der Ausweichvereinbarung zum Ermitteln der Vereinbarung unzulässig, wenn die Vereinbarung nicht durch Herstellen der Übereinstimmung des Austauschheaders mit den Vereinbarungseigenschaften aufgelöst werden kann. Der Austausch wie bei einem Authentifizierungsfehler behandelt und angehalten, wenn keine Vereinbarung gefunden wurde.

Hinweis

Eine Nachricht in der EDI-Pipeline erreicht den nächsten Schritt in der Vereinbarungsauflösung, bis die Nachricht in dem Schritt aufgelöst wird, in dem die Vereinbarung den Status Aktivieren aufweist. Wenn die Nachricht z. B. im ersten Schritt der Vereinbarungsauflösung aufgelöst wird, die Vereinbarung jedoch einen deaktivierten Status aufweist, erreicht die Nachricht den nächsten Schritt für die Auflösung.

Schemaerkennung

Nachdem BizTalk Server die Vereinbarung ermittelt hat, die in die Nachricht aufgelöst wird, muss das Schema bestimmt werden, das zum Überprüfen und Verarbeiten der Nachricht verwendet werden soll. Dazu werden die Eigenschaften verwendet, die auf der Seite Einstellungen für den lokalen Host auf der Registerkarte One-Way(Send Side) Agreement des Dialogfelds Agreement Properties (Vereinbarungseigenschaften ) identifiziert werden.

Um das Schema zu bestimmen, müssen BizTalk Server zuerst den Schemanamespace bestimmen. Der EDI-Disassembler verwendet entweder einen Standardnamespace für die mit BizTalk Server ausgelieferten Standardschemas, oder er bestimmt den Namespace, der für ein benutzerdefiniertes Schema verwendet werden soll.

Auf der Seite Lokale Hosteinstellungen der Registerkarte "Unidirektionale Vereinbarung" des Dialogfelds Vereinbarungseigenschaften können Sie ein Raster mit Werten einrichten, um einen benutzerdefinierten Namespace zu bestimmen. Wenn in diesem Raster keine Übereinstimmung gefunden wird, verwendet der EDI Disassembler den Standardnamespace im Feld Zielnamespace , das für die Standardzeile markiert ist.

X12-Schemaerkennung

Für X12-codierte Nachrichten bestimmt BizTalk Server einen benutzerdefinierten Namespace mithilfe des Anwendungssenderbezeichners (GS02) und der Transaktionssatz-ID (ST01) aus dem Header des eingehenden Austauschs. Es wird versucht, eine Übereinstimmung zwischen diesen Werten und den Werten für die Eigenschaften GS02 und ST01 im Raster Zielnamespace anpassen auf der Seite Lokale Hosteinstellungen (unter Transaktionssatzeinstellungen) der Registerkarte bidirektionale Vereinbarung des Dialogfelds Vereinbarungseigenschaften zu finden. Wenn eine Übereinstimmung gefunden wird, wird der Zielnamespace verwendet, der in derselben Zeile des Rasters identifiziert wurde, um zu bestimmen, welches Schema für uns zum Überprüfen und Verarbeiten der Nachricht verwendet werden soll. Wenn der Zielnamespace nicht ermittelt werden kann, wird der Standardzielnamespace verwendet. Wenn im Feld Zielnamespace kein Namespace identifiziert wird, das für die Standardzeile markiert ist, verwendet BizTalk Server den Zielnamespace, der in den Eigenschaften der Fallbackvereinbarung für X12-codierte Nachrichten identifiziert wird. Dies ist http://schemas.microsoft.com/BizTalk/Edi/X12/2006standardmäßig .

Bei X12-Austauschvorgängen bestimmt BizTalk Server das Schema anhand der folgenden Informationen, nachdem der Zielnamespace erkannt wurde:

  • Der soeben erkannte Zielnamespace.

  • Die Version/Freigabe in den ersten fünf Zeichen von "ST03" (wenn "GS07" == X - Accredited Standards Committee X12). Wenn "ST03" nicht vorhanden bzw. ungültig ist oder nicht zur Schemaauflösung führt, wird die Version anhand der ersten fünf Zeichen von "GS08" oder "ISA12" ermittelt (wenn "GS07" != X ist).

  • Der "DocType" in "ST01".

    Der EDI-Disassembler verkettet den Codierungstyp, die Version/Freigabe und den Dokumenttyp, um den Schemanamen zu ermitteln, z. B. "X12_00401_864". Anschließend wird der Zielnamespace mit dem Schemanamen verkettet, http://schemas.microsoft.com/BizTalk/Edi/X12/2006/X12#X12_00401_864z. B. .

    Für einen eingehenden HIPAA 837-Austausch unterstützt BizTalk Server drei HIPAA 837-Schemas:

837 Schema GS08-Wert in Version 4010 GS08/ST03-Wert in Version 5010
Claim-Dental_837D 004010X097A1 005010X224A1
Claim-Institutional_837I 004010X096A1 005010X223A1
Claim-Professional_837P 004010X098A1 005010X222

Hinweis

In HIPAA-Versionen verwenden die Anforderungs-/Antwortpaare für den Transaktionssatz 278 (Health Care Services Review) den gleichen Wert für "GS08" und "ST01" gemeinsam. Abhängig von den Triggerwerten im Feld "BHT02" können Sie zwischen einer 278-Anforderung/Antwort in Version 5010 unterscheiden:

  1. Die Werte 01, 13 und 36 in "BHT02" zeigen eine Health Care Services Review Request an.
    2. 11 in BHT02 gibt Antwort auf die Überprüfung durch Gesundheitsdienste an

EDIFACT-Schemaerkennung

Für EDIFACT-codierte Nachrichten bestimmt BizTalk Server einen benutzerdefinierten Namespace mithilfe des Nachrichtentyps (UNH2.1), der Nachrichtenversionsnummer (UNH2.2), der Nachrichtenfreigabenummer (UNH2.3), des zugewiesenen Codes (UNH2.5), der Funktionsgruppen-ID (UNG2.1) und des Codequalifizierers der Anwendung (UNG2.2) aus dem Header des eingehenden Austauschs. Anschließend wird versucht, eine Übereinstimmung zwischen diesen Werten und den Werten für die Eigenschaften UNH2.1, UNH2.2, UNH2.3, UNH2.5, UNG2.1 und UNG2.2 im Raster Zielnamespace anpassen (unter Transaktionssatzeinstellungen) der Registerkarte bidirektionale Vereinbarung des Dialogfelds Vereinbarungseigenschaften zu finden. Wird eine Übereinstimmung gefunden, wird der in der gleichen Zeile des Rasters angegebene Zielnamespace zum Ermitteln des zum Überprüfen und Verarbeiten der Nachricht zu verwendenden Schemas verwendet. Wenn der Zielnamespace nicht ermittelt werden kann, wird der Standardzielnamespace verwendet. Wenn im Feld Zielnamespace kein Namespace identifiziert wird, das für die Standardzeile markiert ist, verwenden BizTalk Server den Zielnamespace, der in den Fallbackvereinbarungseigenschaften für EDIFACT-codierte Nachrichten angegeben ist, die standardmäßig lautethttp://schemas.microsoft.com/BizTalk/Edi/EDIFACT/2006.

Bei EDIFACT-Austauschvorgängen bestimmt BizTalk Server das Schema anhand der folgenden Informationen, sobald der Zielnamespace erkannt wurde:

  • Der gerade ermittelte Zielnamespace.

  • Die Nachrichtenversionsnummer in "UNH2.2".

  • Die Nachrichtenfreigabenummer in "UNH2.3".

  • Der Nachrichtentyp in "UNH2.1".

  • Der zugewiesene Code in "UNH2.5".

    Der EDI-Disassembler verkettet den Codierungstyp, die Version, die Freigabe und den Nachrichtentyp, um den Schemanamen zu ermitteln, z. B. "EFACT_D94A_CONTEN". Anschließend wird der Zielnamespace mit dem Schemanamen verkettet, http://schemas.microsoft.com/BizTalk/Edi/Edifact/2006/EFACT#EFACT_D94A_CONTENz. B. .

    Wenn "UNH2.5" in der Nachricht vorhanden ist, versucht der EDI-Disassembler zuerst, ein übereinstimmendes Schema mithilfe des Werts für "UNH2.5" als Teil des Schemanamens zu suchen, z. B. "EFACT_D94A_CONTEN_TEST". Wird kein übereinstimmendes Schema gefunden, versucht der EDI-Disassembler, das Schema ohne den Wert "UNH2.5" zu suchen.

Authorization

BizTalk Server überprüft die Werte der Autorisierungs- und Sicherheitsfelder, die für die Vereinbarung mit den Feldern in der Nachricht definiert sind. Wenn ein Konflikt besteht, setzt BizTalk Server den Austausch an. Für EDIFACT-codierte Nachrichten handelt es sich bei diesen Feldern um das Empfängerverweiskennwort ("UNB6.1" und "UNB6.2"). Für X12-codierte Nachrichten handelt es sich bei diesen Feldern um den Autorisierungsqualifizierer und die -informationen ("ISA1-2") und um den Sicherheitsqualifizierer und die -informationen ("ISA3-4").

Weitere Informationen

Empfangen von EDI-Nachrichten in BizTalk Server