Freigeben über

Funktionsweise des EDI-Disassemblers

  • Artikel

BizTalk Server führt die meiste Verarbeitung für empfangene EDI-codierte Austauschvorgänge in der EDI-Empfangspipeline (Microsoft.BizTalk.DefaultPipelines.EDIReceivePipeline) durch. Diese Pipeline enthält die Komponente EDI-Disassembler, die folgende Verarbeitungsaufgaben ausführt:

  • Teilt mehrere Austauschvorgänge in einer einzelnen Nachricht in separate Austauschvorgänge auf (wenn der Wert der Pipelineeigenschaft DetectMID für den Empfangsspeicherort auf True festgelegt wird). Dazu sucht der EDI-Disassembler nach einem Austauschkontrollheader (ISA, UNA oder UNB) – sogar nachdem ein Austauschkontrollnachspann (IEA oder UNZ) gefunden wurde.

  • Überprüft den Umschlag.

  • Disassemblieren des Austauschs

  • Verarbeitet Triggerfelder für HIPAA-Austauschvorgänge.

  • Überprüft EDI- und partnerspezifische Eigenschaften nach Bedarf. Dieser Vorgang umfasst EDI-Schemaüberprüfung, feldübergreifende Überprüfung auf X12-codierte Nachrichten (falls konfiguriert), strukturelle EDI-Überprüfung und erweiterte Schemaüberprüfung (sofern das Schema mit einem Knoten angepasst wurde, der einen Nicht-EDI-Datentyp aufweist). Weitere Informationen finden Sie unter Validierung empfangener EDI-Nachrichten.

  • Überprüft, ob die Kontrollnummern für Austausch-, Gruppen- und Transaktionssätze keine Duplikate sind, wenn die Überprüfungen auf der Seite Validierung (unter Austauscheinstellungen) der Registerkarte bidirektionale Vereinbarung des Dialogfelds Vereinbarungseigenschaften aktiviert sind. Gleicht die Austauschkontrollnummer mit zuvor empfangenen Austauschvorgängen ab. Überprüfen der Gruppenkontrollnummer in Bezug auf andere Gruppenkontrollnummern im Austausch Überprüfen der Transaktionssatz-Kontrollnummer in Bezug auf andere Transaktionssatz-Kontrollnummern in dieser Gruppe Wird ein Duplikat entdeckt, so wird im Statusbericht angegeben, dass ein doppelter Datensatz vorhanden ist.

  • Generieren eines XML-Dokuments für jeden Transaktionssatz Bei jeder XML-Datei wird die Kontexteigenschaft BTS.MessageType höher gestuft und dabei der Schemaname mit dem Namespace festgelegt.

  • Konvertiert den gesamten Austausch in XML, wenn die Eigenschaft der Batchverarbeitungsoption für eingehenden Datenverkehr auf einen der beiden Werte von Preserve Interchange festgelegt ist. Diese Eigenschaft kann auf der Seite Lokale Hosteinstellungen unter Austauscheinstellungen der Registerkarte bidirektionale Vereinbarung des Dialogfelds Vereinbarungseigenschaften festgelegt werden. Von der Empfangspipeline wird die Eigenschaft ReuseEnvelope höher gestuft, um den Austausch als „beibehalten“ zu kennzeichnen.

  • Generieren einer technischen Bestätigung und/oder einer Funktionsbestätigung (sofern konfiguriert) Dies kann die Batchverarbeitung der Bestätigungen (sofern konfiguriert) umfassen. Erhöht die Kontexteigenschaft von BTS. MessageType: Festlegen des Steuerelementschemas im http://schemas.microsoft.com/EDI/{X12 or EDIFACT} Namespace (z. B. X12_997_Root für eine 997-Bestätigung). Stuft außerdem die Kontexteigenschaft EDI.DestinationPartyName höher und stellt damit sicher, dass die Bestätigung zum Senden übernommen wird. Weitere Informationen finden Sie unter Senden einer EDI-Bestätigung.

  • Führt ggf. eine Aufteilung von HIPAA-Dokumenten vom Typ 276/277 (nur Version 5010) 834, 835 (nur Version 4010) und 837 aus.

  • Schreibt Eigenschaften in den Nachrichtenkontext oder stuft sie in den Kontext höher (siehe nächster Abschnitt).

Höherstufen oder Schreiben von Eigenschaften in den Kontext

Wenn der EDI-Disassembler eine empfangene Nachricht verarbeitet, stuft er die folgenden Eigenschaften höher oder schreibt sie in den Nachrichtenkontext:

  • Für eine X12-codierte unbatchierte Nachricht werden die folgenden Eigenschaften aus dem Umschlag hergeleitet: ISA06, ISA08, ISA15; GS01, GS02, GS03, GS08; ST03 und ST01.

    Hinweis

    Für einen eingehenden HIPAA 837-Austausch unterstützt BizTalk Server drei HIPAA 837-Schemas: Claim-Dental_837D, Claim-Institutional_837I und Claim-Professional_837P. Der ST01 ist für jede dieser Elemente "837". Diese drei Schemas weisen unterschiedliche Werte für GS08 in Version 5010 auf: "005010X223A1" für 837I, "005010X224A1" für 837D und "005010X222" für 837P. Die Schemas weisen unterschiedliche Werte für GS08 in Version 4010 auf: "004010X096A1" für 837I, "004010X097A1" für 837D und "004010X098A1" für 837P.

  • Für eine EDIFACT-codierte unbatchierte Nachricht werden die folgenden Eigenschaften aus dem Umschlag heraufgefördert: UNB2.1, UNB2.3, UNB3.1, UNB11; UNG1, UNG2.1, UNG3.1; UNH2.1, UNH2.2, UNH2.3.

  • Wenn ein im Batch verarbeiteter Austausch aufgeteilt wird, werden ISA_Segment und GS_Segment in den Kontext für X12-codierte Nachrichten oder aber UNA_Segment, UNB_Segment und UNG_Segment in den Kontext für EDIFACT-codierte Nachrichten geschrieben.

    Hinweis

    Die oben genannten Segmente werden in den Kontext geschrieben. Sie werden nicht in den Kontext höher gestuft. Sie können diese Segmente jedoch unter Verwendung des Beispiels „Message Enrichment“ an einen Transaktionssatz anfügen. Sie können auch den Code zum Anfügen der Beispiele verwenden und ihn einer benutzerdefinierten Pipelinekomponente hinzufügen. Weitere Informationen finden Sie unter Beispiel für die Nachrichtenanreicherung (BizTalk Server Beispiel).

    Hinweis

    Die höher gestufte Eigenschaft ISA_Segment enthält Sicherheits-/Autorisierungsinformationen – ISA02 (Autorisierungsinformationen) und ISA04 (Sicherheitsinformationen) – die zur Offenlegung von Informationen führen können. Sie können die Eigenschaft "Sicherheit/Autorisierung/Kennwortinformationen maskieren" im Kontext verwenden (auf der Seite Lokale Hosteinstellungen für die Eigenschaften für bidirektionale Vereinbarungen), um die einzelnen Zeichen in den Feldern ISA02 und ISA04 durch ein "#"-Zeichen zu ersetzen. Dies ist ein unidirektionales Verfahren: Die "#"-Zeichen können nicht in tatsächliche Zeichen konvertiert werden.

  • Bei X12- und EDIFACT-codierten Nachrichten wird ReuseEnvelope höher gestuft und dadurch angegeben, dass ein als Batch vorliegender Austausch aufgeteilt oder beibehalten wird.

  • Wenn ein als Batch vorliegender Austausch beibehalten wird, werden die folgenden Eigenschaften höher gestuft:

    • InboundTransportatLocation

    • InboundTransportType

    • ISA05

    • ISA07

    • ISA06

    • ISA08

    • ISA15

    • LastInterchangeMessage = {True|False}

    • MessageType

    • ReceivePortID

    • ReceivePortName

    • ReuseEnvelope

Analysieren des Umschlags

Die EDI-Empfangspipeline verwendet das Headerkontrollschema zum Analysieren des Umschlags einer empfangenen EDI-Nachricht und das EDI-Dokumentschema zum Analysieren der Transaktionssätze/Nachrichten im Austausch.

Wenn eine EDIINT/AS2-codierte Nachricht per HTTP/HTTPS-Transport empfangen wurde, überprüft der EDI-Disassembler die Kontexteigenschaft BTS. MessageDestination. Falls diese Eigenschaft auf SuspendQueue festgelegt ist und damit angegeben wird, dass ein Fehler bei der AS2-Verarbeitung aufgetreten ist und die Nachricht angehalten werden muss, fungiert der EDI-Disassembler als Pass-Through-Pipelinekomponente und hält die Nachricht für die MessageBox an.

Während der Analyse von EDIFACT-Austauschvorgängen entfernt die EDI-Empfangspipeline den als Escapezeichen verwendeten Freigabeindikator. Der Releaseindikator ist nicht in der EDI-Validierung enthalten. Die EDI-Empfangspipeline schließt den Freigabeindikator nicht in die Berechnung von Längeneinschränkungen ein.

Zeichensatz

Bei X12-Austauschvorgängen bestimmen die Eigenschaften der Pipelinekomponente den Zeichensatz, den der EDI-Disassembler bei der Verarbeitung des Austauschs verwendet. Es stehen die Werte Standard, Erweitert und UTF8/Unicode zur Auswahl. Der Standardwert für EDIFACT-Austauschvorgänge ist UTF8; das Feld UNB1.1 bestimmt den Zeichensatz.

Ermittlung dynamischer Trennzeichen

Wenn BizTalk Server einen EDI-Austausch empfängt, geben keine Vereinbarungseigenschaften an, was die Trennzeichen im Austausch sein sollen. Stattdessen ermittelt der EDI-Disassembler, welche Trennzeichen (für X12 oder EDIFACT) zur Laufzeit vorliegen.

Bei X12-Nachrichten verwendet der EDI-Disassembler die folgenden Zeichen aus dem Austausch:

Trennzeichen Zeichen
Datenelementtrennzeichen 4. Zeichen von ISA
Komponentenelementtrennzeichen ISA16
Segmenttrennzeichen 106. Zeichen von ISA
Segmentabschlusszeichensuffix Ein Zeichen zwischen dem ISA-Segment und dem GS-Segment.

Werte: None, CR, LF oder CRLF Hinweis: Das Trennzeichen kann nur die oben genannten Werte annehmen.
Wiederholungstrennzeichen oder Standardbezeichner

(abhängig von der Vereinbarungseigenschaft "ISA11-Nutzung" auf der Seite Envelopes der Registerkarte bidirektionale Vereinbarung)		 ISA11

Bei EDIFACT-Austauschvorgängen überprüft der EDI-Disassembler das UNA-Segment, mit dem die Trennzeichen im Austausch definiert werden. Wenn der Austausch kein (optionales) UNA-Segment aufweist, werden vom Disassembler die in den Eigenschaften von Pipelinekomponenten definierten Standardwerte verwendet.

Trennzeichen Zeichen von UNA
Komponentenelementtrennzeichen 4.
Datenelementtrennzeichen 5.
Dezimalschreibweise 6.
Zeichen freigeben 7.
Wiederholungszeichen 8.
Segmenttrennzeichen 9.
Segmenttrennzeichensuffix Ein Zeichen zwischen dem UNA-Segment und dem UNB-Segment.

Werte: None, CR, LF oder CRLF Hinweis: Das Trennzeichen kann nur die oben genannten Werte annehmen.

Die UNA-Zeichenfolge ist optional. Wenn sie vorhanden ist, definiert sie alle Trennzeichen für die Datei. Ist sie nicht vorhanden, verwendet der EDI-Disassembler die Eigenschaft EfactDelimiters der Pipelinekomponente zum Bestimmen der Trennzeichen. Weitere Informationen finden Sie unter Konfigurieren von EDI-Pipelineeigenschaften.

Anzeigen von Fehlern

Wenn beim EDI-Disassembler ein EDI-Verarbeitungsfehler auftritt, postet BizTalk Server die folgenden beiden Fehler im Ereignisanzeige (wenn diese Veröffentlichung aktiviert ist):

  • Ein Fehler, der von der Quelle BizTalk Server protokolliert wird, während die Nachricht angehalten wird. Dies ist ein erforderlicher Fehler im Zusammenhang mit BizTalk Server Verarbeitung.

  • Ein Fehler, der Probleme im Transaktionssatz meldet, wie er von der Quelle BizTalk Server EDI protokolliert wird. Dieser Fehler ist EDI-spezifisch.

Verwenden von Vereinbarungseigenschaften

Der EDI-Disassembler verwendet Vertragseigenschaften, wenn er die Vereinbarung identifizieren kann (siehe Vertragsauflösung, Schemaermittlung und Autorisierung für empfangene EDI-Nachrichten). Wenn eine übereinstimmende Vereinbarung nicht gefunden werden kann und die entsprechenden Werte nicht auch in der Fallbackvereinbarung verfügbar sind, werden die edi Disassembler-Eigenschaften verwendet, die im Fenster Eigenschaften von Visual Studio festgelegt sind. Dieses Fallback tritt jedoch nicht auf, wenn die Authentifizierung in den Empfangsporteigenschaften erforderlich ist (wenn entweder Nachrichten löschen, wenn die Authentifizierung fehlschlägt , oder Nachrichten beibehalten, wenn Authentifizierungsfehler ausgewählt sind). In einem solchen Fall muss eine Vereinbarung konfiguriert werden; andernfalls wird der Austausch angehalten.

Wenn der EDI-Disassembler Vereinbarungseigenschaften verwendet, müssen die folgenden Eigenschaften festgelegt werden:

Eigenschaft Seite mit Vereinbarungseigenschaften
Wiederholungstrennzeichen Seite "Umschläge " (unter Austauscheinstellungen) auf der Registerkarte "Bidirektionale Vereinbarung"
EDI-Datentypüberprüfung durchführen Validierungsseite unter Transaktionssatzeinstellungen auf der Registerkarte bidirektionale Vereinbarung (sowohl für X12- als auch für EDIFACT-Vereinbarungen)
Erweiterte Überprüfung Validierungsseite unter Transaktionssatzeinstellungen auf der Registerkarte bidirektionale Vereinbarung (sowohl für X12- als auch für EDIFACT-Vereinbarungen)
Führende und nachfolgende Nullen und Leerzeichen zulassen Validierungsseite unter Transaktionssatzeinstellungen auf der Registerkarte bidirektionale Vereinbarung (sowohl für X12- als auch für EDIFACT-Vereinbarungen)
Leere XML-Tags erstellen, wenn nachfolgende Trennzeichen zulässig sind Seite Lokale Hosteinstellungen unter Transaktionssatzeinstellungen auf der Registerkarte bidirektionale Vereinbarung (sowohl für X12- als auch für EDIFACT-Vereinbarungen)
Option zu Verarbeitung eingehender Batches Seite "Lokale Hosteinstellungen" (unter Austauscheinstellungen) auf der Registerkarte "Bidirektionale Vereinbarung" (sowohl für X12- als auch für EDIFACT-Vereinbarungen)
EDIFACT-Standardtrennzeichen -
Sicherheits-/Autorisierungs-/Kennwortinformationen maskieren Seite "Lokale Hosteinstellungen" (unter Austauscheinstellungen) auf der Registerkarte "Bidirektionale Vereinbarung" (sowohl für X12- als auch für EDIFACT-Vereinbarungen)
Implizite Dezimalzahlen im Nn-Format in Zehnerlogarithmuswerte einer Zahl konvertieren Seite Lokale Hosteinstellungen unter Transaktionssatzeinstellungen auf der Registerkarte bidirektionale Vereinbarung (für X12-Vereinbarungen)
Weiterleiten der Bestätigung an Sendepipeline am Anforderung-Antwort-Empfangsport Seite "Lokale Hosteinstellungen" (Abschnitt "Einstellungen des Empfängers") unter Austauscheinstellungen auf der Registerkarte "Bidirektionale Vereinbarung" (sowohl für X12- als auch für EDIFACT-Vereinbarungen)
X12-Zeichensatz Hinweis zur X12-Austauschumschlaggenerierung: Diese Einstellung wird nur verwendet, um die für die Vereinbarungseigenschaften eingegebenen Werte zu überprüfen. Der für die Verarbeitung zur Laufzeit verwendete X12-Zeichensatz wird in den Pipelineeigenschaften ausgewählt. Weitere Informationen finden Sie unter EDI-Zeichensätze.

Verwenden von HIPAA-Triggerfeldern

EDI-Segmente enthalten oft Qualifiziererwerte, mit denen die Bedeutung des Segments geändert wird. So kann ein N1-Segment beispielsweise das qualifizierende Element BT zur Kennzeichnung eines Namens für „Bill-to“ (Rechnungsadresse) oder das qualifizierende Element ST zur Angabe eines Namens für „Ship-to“ (Lieferadresse) enthalten. Normalerweise bleibt es der Geschäftslogik überlassen, zu bestimmen, wie diese Felder interpretiert werden sollen, und der Disassembler löst alle Instanzen des N1-Segments in denselben XML-Datensatznamen auf. Die mit BizTalk Server ausgelieferten HIPAA-Schemas enthalten jedoch Anmerkungen, die es dem EDI-Disassembler ermöglichen, eindeutige XML-Datensätze basierend auf dem Vorhandensein eines qualifizierenden Werts zu erstellen (siehe HIPAA-Schematriggerfeldanmerkungen).

Wenn der EDI-Disassembler beim Empfang eines HIPAA-Transaktionssatzes ein Segment mit einem Triggerfeld erkennt, generiert er anhand der Triggerinformationen einen für das Segment und die Triggerkombination spezifischen XML-Datensatz.

In der nachstehenden Tabelle wird gezeigt, wie ein N1-Segment auf der Grundlage des Werts von N101 in einen XML-Datensatz konvertiert wird:

N1-Segment Resultierende XML-Daten
N1*PR*Contoso*XV*0000000~ <ns0:TS835W1_1000A_Loop> <N1_PayerIdentification_TS835W1_1000A> <N101__EntityIdentifierCode>PR</N101__EntityIdentifierCode> <N102__PayerName>Contoso</N102__PayerName> <N103__IdentificationCodeQualifier>XV</N103__IdentificationCodeQualifier> <N104__PayerIdentifier>0000000</N104__PayerIdentifier> </N1_PayerIdentification_TS835W1_1000A>
N1*PE*Fabrikam*FI*9999999~ <TS835W1_1000B_Loop> <N1_PayeeIdentification_TS835W1_1000B> <N101__EntityIdentifierCode>PE</N101__EntityIdentifierCode> <N102__PayeeName>Fabrikam</N102__PayeeName> <N103__IdentificationCodeQualifier>FI</N103__IdentificationCodeQualifier> <N104__PayeeIdentificationCode>9999999</N104__PayeeIdentificationCode> </N1_PayeeIdentification_TS835W1_1000B>

Weitere Informationen

Empfangen von EDI-Nachrichten in BizTalk Server