Funktionsweise des EDI-Assemblers
BizTalk Server führt die meisten Verarbeitung von EDI-codierten Austauschvorgängen durch, die in der EDI-Sendepipeline (Microsoft.BizTalk.DefaultPipelines.EDISendPipeline) gesendet werden sollen. Diese Pipeline enthält die Komponente EDI-Assembler, die folgende Verarbeitungsaufgaben ausführt:
Serialisierung des EDI-Austauschs mit Konvertierung von XML-codierten Nachrichten in EDI-Transaktionssätze im Austausch
Durchführen der EDI-Schemaüberprüfung, feldübergreifenden Überprüfung auf X12-codierte Nachrichten (falls konfiguriert), strukturellen EDI-Überprüfung und erweiterten Schemaüberprüfung (sofern das Schema mit einem Knoten angepasst wurde, der einen Nicht-EDI-Datentyp aufweist)
Hinzufügen eines Umschlags zur EDI-Nachricht
Verarbeiten der technischen und Funktionsbestätigungen, die als Antwort auf EDI-Nachrichten empfangen werden, wobei die Batchverarbeitung der Bestätigung aufgehoben wird (falls konfiguriert)
Hinzufügen eines Umschlags zu einer ausgehenden EDI-Nachricht
Wenn die EDI-Sendepipeline anhand einer XML-Datei im Zwischenformat eine ausgehende EDI-Nachricht erstellt, wird basierend auf den EDI-Eigenschaften, die für die Vereinbarung auf Empfangsseite festgelegt sind, der Nachricht ein Umschlag hinzugefügt, der Austausch- und Gruppenheader enthält. Falls die Sendepipeline die empfangende Vereinbarung nicht am Sendeport bestimmen konnte, verwendet sie die Ausweichvereinbarung zum Hinzufügen des Umschlags.
Wenn die EdiOverride.OverrideEdiHeader Kontexteigenschaft auf true festgelegt ist, verwendet die EDI-Sendepipeline werte, die in der EdiOverride-Eigenschaftsauflistung angegeben sind, um den Umschlag zu erstellen. Sollte in der Auflistung kein Wert vorhanden sein, wird der entsprechende EDI-Wert in den Vereinbarungseigenschaften gewählt. Wenn weder in der EdiOverride-Auflistung noch in den Vereinbarungseigenschaften ein Wert vorhanden ist, werden die Eigenschaften in der EDI-Ausweichvereinbarung verwendet.
Wenn die XML-Datei im Zwischenformat ein reserviertes Tag oder die ReuseEnvelope-Kontexteigenschaft enthält, ist die Nachricht ein beibehaltener Batch, sodass die Anwendungslogik des Umschlags nicht gilt.
Quellen für X12-Umschlagswerte
Die folgende Tabelle zeigt, wo die EDI-Sendepipeline die Informationen abruft, die sie für jeden Teil eines X12-Umschlags benötigt:
| Header | `Source` |
|---|---|
| Austauschkontrollheader (ISA) | – EdiOverride-Kontexteigenschaften (wenn EdiOverride.OverrideEdiHeader true ist).- Wenn eine Vereinbarung definiert ist, werden ISA-Segmentdefinitionen von verschiedenen Seiten im Abschnitt Austauscheinstellungen in den unidirektionale Vereinbarungseigenschaften im Dialogfeld Vereinbarungseigenschaften verwendet. - Wenn keine Vereinbarung definiert ist, werden ISA-Segmentdefinitionen von verschiedenen Seiten im Abschnitt Austauscheinstellungen im Dialogfeld EDIFACT-Fallbackeinstellungen verwendet. |
| Funktionsgruppenheader (GS) | – EdiOverride-Kontexteigenschaften (wenn EdiOverride.OverrideEdiHeader true ist)- Wenn eine Vereinbarung definiert ist, werden GS-Segmentdefinitionen auf der Seite "Umschläge " (im Abschnitt Transaktionssatzeinstellungen ) in den unidirektionalen Vereinbarungseigenschaften im Dialogfeld "Vereinbarungseigenschaften " definiert. - Wenn keine Vereinbarung definiert ist, werden GS-Segmentdefinitionen auf der Seite Umschläge (im Abschnitt Transaktionssatzeinstellungen ) im Dialogfeld X12-Fallbackeinstellungen verwendet. Wenn eine Vereinbarung definiert ist, werden die Werte der GS-Datenelemente basierend auf der Kombination aus Transaktionssatzbezeichner (ST1), Version und Zielnamespace bestimmt. Diese Werte werden mit dem Raster auf der Seite Umschläge (unter dem Abschnitt Transaktionssatzeinstellungen ) der Vertragseigenschaften (wenn eine Vereinbarung definiert ist) oder der Fallbackvertragseigenschaften (wenn keine Vereinbarung definiert ist) verglichen: - Wenn eine übereinstimmende Zeile vorhanden ist, werden die in der übereinstimmenden Zeile enthaltenen Werte für den GS-Header verwendet. - Wenn keine Übereinstimmung vorhanden ist, aber eine Standardzeile definiert ist, werden alle GS-Datenelemente mit Ausnahme von GS01 aus der Standardzeile aufgefüllt. GS01 wird basierend auf dem Wert von ST1 dynamisch bestimmt. – Wenn keine übereinstimmende Zeile und keine Standardzeile vorhanden ist, wird die Nachricht angehalten. Hinweis: Damit eine Gruppe von anderen Gruppen eindeutig ist, können nicht alle diese Werte mit denen für eine andere Gruppe identisch sein. Wenn keine Vereinbarung definiert ist, werden die GS-Datenelemente mithilfe der Ausweichvereinbarungseigenschaften aufgefüllt. |
Quellen für EDIFACT-Umschlagswerte
Die folgende Tabelle zeigt, wo die EDI-Sendepipeline die Informationen abruft, die sie für jeden Teil eines EDIFACT-Umschlags benötigt:
| Header | `Source` |
|---|---|
| Dienstmeldungszeichenfolge (UNA) | – EdiOverride-Kontexteigenschaften (wenn EdiOverride.OverrideEdiHeader true ist).- Wenn eine Vereinbarung definiert ist, werden UNA-Segmentdefinitionen von der Seite Charset und Trennzeichen in den unidirektionale Vereinbarungseigenschaften im Dialogfeld Vereinbarungseigenschaften verwendet. - Wenn keine Vereinbarung definiert ist, werden UNA-Segmentdefinitionen von der Seite Charset und Trennzeichen im Dialogfeld EDIFACT-Fallbackeinstellungen verwendet. |
| Austauschkontrollheader (UNB) | – EdiOverride-Kontexteigenschaften (wenn EdiOverride.OverrideEdiHeader true ist).- Wenn eine Vereinbarung definiert ist, werden UNB-Segmentdefinitionen aus verschiedenen Seiten im Abschnitt Austauscheinstellungen in den unidirektionellen Vereinbarungseigenschaften im Dialogfeld Vereinbarungseigenschaften verwendet. - Wenn keine Vereinbarung definiert ist, werden UNB-Segmentdefinitionen von verschiedenen Seiten im Abschnitt Austauscheinstellungen im Dialogfeld EDIFACT-Fallbackeinstellungen verwendet. |
| Funktionsgruppenheader (UNG) | – EdiOverride-Kontexteigenschaften (wenn EdiOverride.OverrideEdiHeader true ist).- Wenn eine Vereinbarung definiert ist, werden UNG- und UNH-Segmentdefinitionen auf der Seite Umschläge (unter dem Abschnitt Transaktionssatzeinstellungen) in den unidirektionalen Vereinbarungseigenschaften im Dialogfeld Vereinbarungseigenschaften verwendet. - Wenn keine Vereinbarung definiert ist, werden UNG- und UNH-Segmentdefinitionen auf der Seite Umschläge (unter dem Abschnitt Transaktionssatzeinstellungen ) in den unidirektionalen Vereinbarungseigenschaften im Dialogfeld Vereinbarungseigenschaften im Dialogfeld EDIFACT-Fallbackeinstellungen verwendet. Wenn eine Vereinbarung definiert ist, werden die Werte der UNG-Datenelemente basierend auf der Kombination aus Nachrichtentyp (UNH2.1), Nachrichtenfreigabenummer (UNH2.3), zugewiesenem Code (UNH2.5), Version und Zielnamespace bestimmt. Hinweis: Damit eine Gruppe von anderen Gruppen eindeutig ist, können nicht alle diese Werte mit denen für eine andere Gruppe identisch sein. |
Hinzufügen von Transaktionssatz-Header- und Nachspannsegmenten
Ein XML-Transaktionssatz, der in einen ausgehenden EDI-Austausch serialisiert wird, sollte einen Transaktionssatzheader und -nachspann besitzen. Der EDI-Assembler verarbeitet die Nachricht jedoch auch ohne einen Transaktionssatzheader und -nachspann. Transaktionssatz-Header- und -Nachspannsegmente in X12- und EDIFACT-Schemas sind für XML-Transaktionssätze optional. Wenn eine Transaktion keinen Header oder Nachspann besitzt, fügt der EDI-Assembler in der EDISend- oder AS2EDISend-Sendepipeline die Werte für einen Transaktionssatzheader und -nachspann hinzu. Diese Werte basieren auf Zuordnungen oder Berechnungen. Der EDI-Assembler führt diesen Vorgang für Austausch-XML (einen beibehaltenen Batch), Batchtransaktionssatz-XML und Transaktionssatz-XML aus.
Wenn bei der Zuordnung ein Überprüfungsfehler auftritt, wird der XML-Transaktionssatz oder die Austausch-XML mit einer entsprechenden Fehlermeldung in der Ereignisanzeige angehalten, z. B. ungültige Länge, ungültiger Datentyp oder ungültiger Code der Kontrollagentur.
X12-Transaktionssatz-Header- und Nachspannsegmente
Für X12-codierte Transaktionssätze ohne Header- und Nachspannsegmente legt der EDI-Assembler die ST- und SE-Segmente wie folgt fest:
| Kopfzeilen-/Fußzeilensegment | Wert |
|---|---|
| ST01 (Transaktionssatz-Bezeichnercode) | Die letzten drei Zeichen des RootNode-Namens des eingehenden XML-Transaktionssatzes. Beispiel: „855“ aus „X12_00401_855“. Für HIPAA-Ansprüche mit dem Transaktionssatz-Bezeichnercode 837P, 837D oder 837I wird „837“ verwendet. |
| ST02 (Transaktionssatz-Kontrollnummer) | Der Wert von EdiOverride.ST02 (wenn EdiOveride.OverrideEdiHeader true ist) oder dem Wert der Transaktionssatz-Kontrollnummer (ST02) auf der Seite Einstellungen für den lokalen Host (unter Austauscheinstellungen) der Registerkarte "Unidirektionale Vereinbarung" im Dialogfeld Vereinbarungseigenschaften zugeordnet ist.Eine neue oder inkrementierte Kontrollnummer wird unabhängig von der Einstellung der Eigenschaft Neue ID anwenden angewendet. |
| ST03 (Versionsbezeichner) | Wird dem Wert von ST03 aus dem eingehenden XML-Transaktionssatz zugeordnet. Beispiel: „005010X218“ für ein 5010 HIPAA 820-Dokument (Lohnabzug). ST03 wird im Abgleich mit dem Schema, das zur Überprüfung des Transaktionssatzes dient, auf Gültigkeit überprüft. Hinweis: ST03 ist für alle HIPAA-Transaktionen der Version 5010 mit Ausnahme von 835 obligatorisch. |
| SE01 (Anzahl einbezogener Segmente) | Legen Sie diese Einstellung auf die Gesamtanzahl der Segmente im Transaktionssatz einschließlich ST- und SE-Segmente fest. |
| SE02 (Transaktionssatz-Kontrollnummer) | Der Wert von ST02 im Transaktionssatz. |
Andere Datenelemente im Transaktionssatzheader, z. B. ST03, sind optional und werden deshalb nicht in den generierten Segmenten berücksichtigt.
EDIFACT-Transaktionssatz-Header- und Nachspannsegmente
Für EDIFACT-codierte Transaktionssätze ohne Header- und Nachspannsegmente legt der EDI-Assembler die UNH- und UNT-Segmente wie folgt fest:
| Kopfzeilen-/Fußzeilensegment | Wert |
|---|---|
| UNH01 (Nachrichtenverweis-Kontrollnummer) | Der Wert von EdiOverride.UNH1 (wenn EdiOverride.OverrideEdiHeader true ist) oder dem Wert der Referenznummer (UNH1) auf der Seite Einstellungen für den lokalen Host (unter Austauscheinstellungen) der Registerkarte "Unidirektionale Vereinbarung" im Dialogfeld "Vereinbarungseigenschaften " zugeordnet ist. Eine neue oder inkrementierte Kontrollnummer wird unabhängig von der Einstellung der Eigenschaft Neue ID anwenden angewendet. |
| UNH2.1 (Nachrichtentyp) | Die letzten sechs Zeichen des RootNode-Namens des eingehenden XML-Transaktionssatzes. Beispiel: „INVOIC“ aus „EFACT_D96A_INVOIC“. |
| UNH2.2 (Nachrichtenversionsnummer) | Das siebte Zeichen des RootNode-Namens des eingehenden XML-Transaktionssatzes. Beispiel: „D“ aus „EFACT_D96A_INVOIC“. |
| UNH2.3 (Nachrichtenfreigabenummer) | Das achte, neunte und zehnte Zeichen des RootNode-Namens des eingehenden XML-Transaktionssatzes. Beispiel: „96A“ aus „EFACT_D96A_INVOIC“. |
| UNH2.4 (Code der Kontrollagentur) | Stets die Zeichenfolge „UN“. |
| UNT01 (Anzahl einbezogener Segmente) | Legen Sie diese Einstellung auf die Gesamtanzahl der Segmente im Transaktionssatz einschließlich UNH- und UNT-Segmente fest. |
| UNT02 (Nachrichtenverweis-Kontrollnummer) | Zugeordnet dem Wert der Referenznummer (UNH1) auf der Seite Lokale Hosteinstellungen (unter Austauscheinstellungen) der Registerkarte "Unidirektionale Vereinbarung" im Dialogfeld "Vereinbarungseigenschaften " |
Andere Datenelemente im UNH-Transaktionssatzheader, z. B. UNH3 bis UNH6, sind optional und werden deshalb nicht in den generierten Segmenten berücksichtigt. Wenn beliebige dieser Felder verbindlich sind, müssen Sie sie auf einen Wert im eingehenden XML-Transaktionssatz festlegen.
Zusätzliche Verarbeitung für den Umschlag einer ausgehenden Nachricht
Die EDI-Sendepipeline wendet die folgende Verarbeitung auf den Umschlag einer ausgehenden Nachricht an.
Kontrollnummern
Die EDI-Sendepipeline gibt eine Austauschkontrollnummer, Gruppenkontrollnummer und Transaktionssatz- bzw. Verweisnummer in die Umschlagsegmente aller ausgehenden Austauschvorgänge ein. Diese Nummern finden Sie in der folgenden Tabelle:
| Kontrollnummer | X12-Feld | EDIFACT-Feld |
|---|---|---|
| Austauschkontrollnummer | ISA13 | UNB5 |
| Gruppenkontrollnummer | GS6 | UNG5 |
| Transaktionssatz-Kontrollnummer (X12) Transaktionssatz-Verweisnummer (EDIFACT) |
ST2 | UNH1 |
BizTalk Server legt die Austauschkontrollnummer für den nächsten gesendeten Austausch basierend auf dem Wertebereich fest, den Sie in der Eigenschaft Interchange Control Number (ISA13) auf der Seite Einstellungen des lokalen Hosts (unter Austauscheinstellungen) der Registerkarte "Unidirektionale Vereinbarung" im Dialogfeld Vereinbarungseigenschaften eingegeben haben. Diese Nummer wird bei jedem nachfolgenden Austausch erhöht, bis der Höchstwert erreicht ist.
Wenn die Austauschkontrollnummer mithilfe der EdiOverride-Kontexteigenschaften angegeben werden, wird der angegebene Wert für diesen Austausch verwendet, ohne sich auf die Austauschkontrollnummer auszuwirken, die in der Vereinbarung angegeben ist.
Hinweis
Die Gruppensteuerungsnummer in EDIFACT wird nur erhöht, wenn die Eigenschaft UNG-Segmente anwenden auf der Seite Envelopes der EDIFACT-Vereinbarungseigenschaften ausgewählt ist. Das zweite Feld (mit der Verweisnummer) wird inkrementiert, die Felder mit Präfix und Suffix werden nicht inkrementiert. Transaktionssatz-Kontrollnummern werden nur erhöht, wenn die Eigenschaft Neue ID anwenden ausgewählt ist.
Hinweis
Bei einem beibehaltenen Batchaustausch können Sie mithilfe des Beispiels „Message Enrichment“ eine benutzerdefinierte Austauschkontrollnummer erstellen. Weitere Informationen finden Sie unter Beispiel für die Nachrichtenanreicherung (BizTalk Server Beispiel).
Wenn keine Vereinbarung definiert ist, werden die Nummern den entsprechenden Seiten der Austauschvereinbarung entnommen. Die Sendepipeline speichert die zuletzt verwendete Kontrollnummer und gibt anschließend eine inkrementierte Nummer für den nächsten Austausch und Transaktionssatz sowie die nächste Gruppe ein.
Hinweis
Wenn eine Kontrollnummer den Maximalwert des angegebenen Bereichs erreicht, löst BizTalk Server einen Fehler aus und hält den Austausch an. Sie können die Steuernummer manuell zurücksetzen oder BizTalk Server so konfigurieren, dass er automatisch auf den unteren Grenzwert zurückgesetzt wird, und zwar auf der Seite Lokale Hosteinstellungen im Dialogfeld Vereinbarungseigenschaften für X12- und EDIFACT-Nachrichten.
Hinweis
Kontrollnummern werden in der Tabelle dbo.EdiSequenceNumbers der BizTalk MessageBox-Datenbank gespeichert. Sie verwalten diese Datenbanktabelle, indem Sie die Kontrollnummern aus der Tabelle löschen oder die Kontrollnummern archivieren.
In EDIFACT bestehen die Kontrollnummern aus alphanumerischen Werten. Die folgenden Formate werden unterstützt:
Zahlen (Beispiel: 1)
PräfixZahlenSuffix (Beispiel: WA1A)
PräfixZahlen (Beispiel: AA1)
ZahlenSuffix (Beispiel: 1AA)
Bei diesen Formaten können die Zahlen Werte von 0 bis 9 und die Präfix- und Suffixzeichen beliebige andere Zeichen sein, die keine Zahlen sind. Nur die Zahl wird bis zum Erreichen des Höchstwerts inkrementiert.
Anzahl der Segmente
Bei jedem Transaktionssatz in einem Austausch überprüft die EDI-Sendepipeline die Anzahl der Segmente im Transaktionssatz gemäß der Angabe im Datenelement SE01 für X12 und im Datenelement UNT01 für EDIFACT. Wenn der Wert des entsprechenden Datenelements nicht der tatsächlichen Anzahl entspricht, aktualisiert die Sendepipeline die Anzahl entsprechend der tatsächlichen Anzahl der Segmente. Der Transaktionssatz wird nicht aufgrund einer fehlerhaften Anzahl zurückgewiesen. Die Aktualisierung der Anzahl wird in der Ereignisanzeige in einer Warnung protokolliert. Dies gilt nicht für die Verarbeitung beibehaltener Batches.
Weitere Schritte beim Serialisieren eines EDI-Austauschs
Bei der Serialisierung führt die EDI-Sendepipeline außerdem die folgenden Schritte aus.
Serialisieren des Freigabeindikators
Bei der Serialisierung einer EDIFACT-Nachricht fügt die EDI-Sendepipeline erforderliche Freigabeindikatoren in den EDI-Austausch ein. Vorausgesetzt wird, dass der XML-Code im Zwischenformat, der an die Sendepipeline geleitet wird, keine Daten enthält, die mit Escapezeichen versehen sind. Wenn beispielsweise ein Freigabeindikator in den XML-Daten enthalten ist, die an die Sendepipeline geleitet werden, fügt die Sendepipeline einen weiteren Freigabeindikator vor dem vorhandenen Freigabeindikator ein, um ihn mit Escapezeichen zu versehen.
Der Freigabeindikator wird nicht in die EDI-Überprüfung einbezogen. Die EDI-Sendepipeline schließt den Freigabeindikator nicht in die Berechnung von Längeneinschränkungen ein.
Hinzufügen nachfolgende Nullen zum Erfüllen implizierter Dezimalanforderungen
Wenn der EDI-Assembler auf einen Wert trifft, der hinter der Dezimalstelle eine unzureichende Anzahl von Stellen aufweist, werden zum Erfüllen implizierter Dezimalanforderungen nachfolgende Nullen hinter dem Dezimalzeichen hinzugefügt. Wenn der EDI-Assembler beispielsweise auf den Wert „4.5“ trifft und die Zahl das N2-Format haben muss, ändert der Assembler den Wert in „4,50“.
Ersetzen von Trennzeichen in Nutzlastdaten
Wenn die Daten in der ausgehenden Nachricht Zeichen enthalten, die auch als Daten-, Segment oder Komponententrennzeichen konfiguriert sind, kann die EDI-Sendepipeline diese Zeichen ersetzen. Beispiel: Wenn die Nachricht den Wert „test*data“ enthält und als Datenelementtrennzeichen „*“ konfiguriert ist, kann dies im empfangenden System zu Analyseproblemen führen.
Die EDI-Sendepipeline kann so konfiguriert werden, dass dieses Zeichen ersetzt wird, indem die Trennzeichen ersetzen in Nutzlast durch die -Eigenschaft aktiviert und ein Ersatzzeichen angegeben wird. Diese Eigenschaft befindet sich auf der Seite Zeichensatz und Trennzeichen auf der Registerkarte Unidirektionale Vereinbarung des Dialogfelds Vereinbarungseigenschaften .
Transformieren von HIPAA-Datensätzen basierend auf Triggerfeldern
Wenn es sich bei dem ausgehenden Dokument um einen HIPAA-Transaktionssatz handelt, transformiert der EDI-Assembler jeden eindeutigen XML-Datensatz, der ein Triggerfeld enthält, in das entsprechende generische EDI-Segment (siehe HIPAA-Schematriggerfeldanmerkungen). Dies erfolgt durch Entfernen des Suffix des XML-Datensatznamens hinter dem Zeichen „_“.
Beispielsweise werden die Elemente <N1_PayerIdentification_TS835W1_1000A> und <N1_PayeeIdentification_TS835W1_1000B> zu N1-Segmenten.