Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Thema werden bekannte Überprüfungsprobleme beschrieben.
Die Nachricht wird ausgesetzt, wenn die EDI-Überprüfung deaktiviert ist.
Symptom
Eine gekoppelte Regel wird verletzt, und die Validierung ist deaktiviert, aber die Nachricht wird angehalten (erwartete Ergebnisse sind, dass die Nachricht serialisiert sein wird).
Mögliche Ursache
Die Kreuzfeld-/Segmentüberprüfung wird ausgeführt, auch wenn die EDI-Typeigenschaft im Knoten "Validierung" und "Einstellungen für die ACK-Generation " des Dialogfelds " EDI-Eigenschaften " deaktiviert ist. Die Überprüfung erfolgt, da sie in der Schemaanmerkung aktiviert ist.
Lösung
Deaktivieren Sie die Überprüfung in der Schemaanmerkung.
Der BizTalk-Dienst muss neu gestartet werden, nachdem ein Schema bearbeitet und erneut bereitgestellt wurde.
Symptom
BizTalk Server verarbeitet keine gültige Nachricht, nachdem ein Schema bearbeitet und erneut bereitgestellt wurde.
Mögliche Ursache
BizTalk Server speichert Schemas mit unbegrenzter Timeout-Dauer im Cache.
Lösung
Starten Sie nach dem Bearbeiten und erneuten Bereitstellen eines Schemas den BizTalk Server-Anwendungsdienst neu. Sie müssen auch die Hostinstanz neu starten, die die Pipeline hostet, die das neu bereitgestellte Schema verwendet.
Die Verarbeitung von Nachrichten eines einzelnen Codierungstyps für eine einzelne Partei wurde abgebrochen.
Symptom
Die Verarbeitung aller Nachrichten eines einzelnen Codierungstyps (z. B. X12 oder EDIFACT) für einen einzelnen Anbieter wurde abgebrochen. Die Verarbeitung von Nachrichten eines anderen Codierungstyps für dieselbe Partei oder Nachrichten für eine andere Partei ist nicht betroffen.
Mögliche Ursache
Die Länge der Austausch-, Gruppen- oder Transaktionssatz-Kontrollnummer hat die maximal zulässige Länge überschritten.
Bei X12-Nachrichten beträgt die maximale Länge einer Steuerelementnummer neun Ziffern. Bei EDIFACT-Nachrichten beträgt die maximale Länge einer Steuernummer 14 Ziffern über drei Felder.
Lösung
Setzen Sie die Kontrollnummer auf der entsprechenden Eigenschaften-Seite des Dialogfelds "EDI-Eigenschaften" für die betroffene Partei zurück. Sie können die Steuerelementnummern auf den folgenden Eigenschaftenseiten bearbeiten:
X12-Austauschsteuerungsnummer: ISA-Segmentdefinitionsseite (im Knoten "Partei als Austauschempfänger") für X12-Eigenschaften
X12-Gruppe oder Transaktionssatz-Kontrollnummer: GS- und ST-Segmentdefinition-Seite (im Knoten "Partei als Austausch-Empfänger" für X12-Eigenschaften)
EDIFACT-Austauschsteuerungsnummer: UNB-Segmentdefinitionsseite (im Knoten Party als Austausch-Empfänger für EDIFACT-Eigenschaften)
EDIFACT-Gruppe oder Transaktionssatz-Kontrollnummer: UNG- und UNH-Segmentdefinitionsseite (im Knoten "Partei als Austausch-Empfänger" für EDIFACT-Eigenschaften)
BizTalk Server validiert anhand von Schemas, die UNH-Segmente mit sieben Datenelementen enthalten.
In früheren Versionen von EDIFACT verfügt das UNH-Segment über vier Elemente und nicht über die sieben Elemente (drei davon optional), über die das UNH-Segment in späteren Versionen verfügt. BizTalk Server verwendet die spätere Version mit sieben Elementen zur Überprüfung.
Fehlermeldungen, die für mehrere feldübergreifende Gültigkeitsprüfungsregeln generiert werden, sind nicht spezifisch für die Regel.
Wenn ein Schema mehrere feldübergreifende Gültigkeitsprüfungsregeln für ein Datenelement in einer Nachricht enthält und ein Fehler mit dem Datenelement auftritt, wird für jede Gültigkeitsprüfungsregel ein separater Fehler generiert. Jeder dieser Fehler hat jedoch denselben Fehlercode und dieselbe Beschreibung; die Fehler sind nicht spezifisch für die Gültigkeitsprüfungsregel.
Wenn die EDI-Typüberprüfung beim Empfang deaktiviert und beim Senden aktiviert ist, kann die Sendepipeline die Nachricht nicht serialisieren.
Wenn Sie die EDI-Typüberprüfung auf der Empfangsseite deaktivieren, generiert die EDI-Empfangspipeline eine XML-Nachricht aus einer empfangenen EDI-Nachricht, unabhängig davon, ob die Nachricht gültig ist. Wenn die EDI-Validierung auf der Sendeseite aktiviert ist, kann die EDI-Sendepipeline den XML-Code nicht in einer gültigen EDI-Datei erneut verarbeiten, wenn die XML-Datei Fehler enthält, und dadurch wird ein Fehler generiert.
Von EDI heraufgestufte Eigenschaften sind nur verfügbar, wenn Ihre Anwendung über einen Verweis auf die BizTalk EDI-Anwendung verfügt.
Symptom
Höhergestufte Eigenschaften unter dem EDI-Namespace werden nicht in der Liste der höhergestuften Eigenschaften angezeigt, die Sie verwenden möchten, z. B. in einer Orchestrierung oder in den Filterbedingungen für einen Sendeport.
Mögliche Ursache
Die von Ihnen verwendete BizTalk-Anwendung enthält keinen Verweis auf die BizTalk EDI-Anwendung. Die Eigenschaftenschemas für die heraufgestuften EDI-Eigenschaften befinden sich in Microsoft.BizTalk.Edi.BaseArtifacts.dll, das im Ordner "Ressourcen" von BizTalk EDI Application enthalten ist.
Lösung
Fügen Sie der BizTalk-Anwendung, in der Sie arbeiten, einen Verweis auf die BizTalk EDI-Anwendung hinzu.
Der Name des Datenelements in einem Kontexteigenschaftsnamen enthält einen Unterstrich, kein Punkt
Der Name eines Datenelements innerhalb eines EDI-Segments enthält einen Punkt, z. B. UNB2.1, welches das Identifikationsfeld für das UNB2-Sendersegment darstellt. Wenn der Name des Datenelements jedoch als Teil einer EDI-Kontexteigenschaft enthalten ist, wird der Punkt durch einen Unterstrich ersetzt. Die Kontexteigenschaft für das Datenelement "Sender Identification" lautet z. B. EDI. UNB2_1, nicht EDI. UNB2.1. Der Grund dafür ist, dass ein Punkt in einem Kontexteigenschaftsnamen nicht unterstützt wird.
Irrelevante Zeichenfolge wird an die Instanzüberprüfungsfehlermeldung angefügt.
Wenn während der Instanzüberprüfung ein Fehler angezeigt wird, wird die Zeichenfolge "BEC 2004" an die Fehlermeldung angefügt. Sie können diese Zeichenfolge ignorieren.
Der Wert der EDIFACT-Schemanamen ist Case-Sensitive.
Bei dem Schemanamen eines EDIFACT-Schemas, wie im root_reference Datenelement des Schemas dargestellt, wird die Groß-/Kleinschreibung beachtet. Beispielsweise wären EFACT_D98B_ORDERS und EFACT_d98B_Orders zwei verschiedene Schemas.
Ungültige EDI-Nachrichten können angehalten werden, auch wenn die EDI-Typüberprüfung deaktiviert ist.
Die EDI-Strukturüberprüfung wird auch dann durchgeführt, wenn die EDI-Typüberprüfung deaktiviert ist. Ein Datenaustausch, bei dem grundlegende strukturelle Validierungen fehlschlagen, wird ausgesetzt, auch wenn die EDI-Typvalidierung deaktiviert ist.
Der EDI-Assembler serialisiert einen ungruppierten Austausch, selbst wenn ein Trennzeichen im Kopfbereich des Umschlags verwendet wird.
Die als Trennzeichen verwendeten Zeichen, die zum Trennen von Kopfzeilen- und Trailerfeldern verwendet werden, dürfen nicht in der Definition der Kopf- oder Trailerfelder eines Austausch-, Gruppen- oder Transaktionssatzes verwendet werden, wie es für die Partei als Austauschempfänger festgelegt ist. Wenn dies der Fall ist, schlägt der Austausch entweder im EDI-Assembler des sendenden BizTalk Servers oder im Disassembler der empfangenden Partei fehl. Der Austausch wird im EDI-Assembler fehlschlagen, wenn es sich um einen ausgehenden Batch handelt, da der Assembler den Umschlag gegen das Headerkontrollschema (Dienst) überprüft. Wenn der Austausch nicht gruppiert ist, wird er vom EDI Assembler serialisiert, aber die Verarbeitung schlägt beim Disassemblierer beim Empfänger fehl.
Nicht kompatible Zeichensätze können zu unterbrochenen Austausch führen
Der für einen ausgehenden Austausch verwendete Zeichensatz sollte mit dem Zeichensatz übereinstimmen, der zum Erstellen der in den Austausch eingefügten Transaktionssätze verwendet wird. Andernfalls wird der Austausch wahrscheinlich mit einer Fehlermeldung angehalten, die angibt, dass ungültige Zeichen vorhanden sind.
Wenn Sie z. B. einen EDIFACT-Batch mit dem UNOA-Zeichensatz erstellen, aber ein Transaktionssatz, der dem Batch hinzugefügt wurde, Kleinbuchstaben enthält, wird die Nachricht durch die Batch-Orchestrierung angehalten, da UNOA keine Kleinbuchstaben zulässt.
Ein weiteres Beispiel: Wenn Sie die EDI-Sendepipeline für X12-Austausche mit dem Zeichensatz "Basic" konfigurieren, aber ein X12-gebündelter Austausch Kleinbuchstaben enthält, weil der X12-Zeichensatz auf der Seite "X12 Interchange Envelop Generation" für die Partei als Austauschempfänger auf "Erweitert" oder "UTF8/Unicode" festgelegt ist, wird die gebündelte Nachricht angehalten, sobald Umschlageinstellungen angewendet werden.
Für die Verwendung von UNH2.5 für die Schemaauflösung ist eine Aktualisierung des Schemas erforderlich.
Wenn Sie UNH2.5 (vom Verband zugewiesener Code) für die Auflösung des Schemas eines eingehenden EDIFACT-Austauschs verwenden, müssen Sie das Schema des relevanten Dokuments im Ordner [Programme\Microsoft BizTalk Server 20xx\Schema] aktualisieren. Sie müssen den Wert von UNH2.5 an die bestehenden Werte für den root_reference, display_reference und xs:element Namen hinzufügen. Wenn UNH2.5 beispielsweise "EAN008" ist und Sie das EFACT_D96A_INVOIC Schema verwenden, würden Sie root_reference, display_reference und xs:element name auf "EFACT_D96A_INVOIC_EAN008" festlegen.
Die komprimierte Datei von Schemas wird ersetzt, wenn ein Upgrade ausgeführt wird.
Wenn Sie Microsoft BizTalk Server auf einen späteren Build aktualisieren, wird die MicrosoftEdiXSDTemplates.exe Datei in Ihrer Installation durch die MicrosoftEdiXSDTemplates.exe Datei ersetzt, die dem Upgrade zugeordnet ist. Wenn Sie beabsichtigen, die Schemas aus der alten komprimierten Datei weiterhin zu verwenden, haben Sie nach dem Upgrade keinen Zugriff mehr auf die komprimierte Datei, es sei denn, Sie sichern die alte komprimierte Datei.
Wenn eine Gruppe mehrere X12-Transaktionssätze enthält, müssen alle denselben Typ aufweisen.
BizTalk Server unterstützt das Mischen verschiedener Transaktionssätze innerhalb derselben Gruppe nicht. Wenn eine Gruppe mehrere Transaktionen enthält, muss der Wert von ST01 für alle Transaktionen identisch sein.
Das Empfangen von X12-Übertragungen, die Nicht-ASCII-Trennzeichen enthalten, kann dazu führen, dass die Nachricht ausgesetzt wird.
Symptom
Beim Empfang eines X12-Austauschs, der Trennzeichen im Nicht-ASCII-Format verwendet, kann die Nachricht unterbrochen werden und ein Fehler wird im Anwendungsereignisprotokoll protokolliert.
Mögliche Ursache
Dieses Problem kann auftreten, wenn der Austausch nicht als UTF-8 codiert ist.
Lösung
Stellen Sie sicher, dass alle eingehenden X12-Austauschelemente, die Nicht-ASCII-Trennzeichen enthalten, als UTF-8 codiert sind.
Siehe auch
Bekannte Probleme bei der EDI-Verarbeitung
EDI Messaging
EDI-Nachrichtenüberprüfung
EDI-Schemas
Entwickeln von EDI-Schemas