Bekannte Probleme bei der EDI-Empfangsverarbeitung
In diesem Thema werden einige bekannte Probleme bei Verarbeitungsvorgängen in der EDI-Empfangspipeline beschrieben.
Fehler bei der empfangsseitigen Verarbeitung nachfolgender Trennzeichen
Symptom
Bei einem Transaktionssatz mit einem nachfolgenden Trennzeichen tritt ein Fehler mit dem Fehlercode AK403= 6 (X12-codierte Nachricht) oder den Fehlercodes UCM3=4/UCD1=45 (EDIFACT-codierte Nachricht) auf.
Mögliche Ursache
Die Verarbeitung nachfolgender Trennzeichen ist nicht aktiviert.
Lösung
Öffnen Sie die EDI-Eigenschaften der Partei, die die Nachricht gesendet hat. Aktivieren Sie im Dialogfeld EDI-Eigenschaften (X12 oder EDIFACT) auf der Seite Einstellungen für Bestätigungsgenerierung und -überprüfung die Option Nachfolgende Trennzeichen zulassen. Nachdem Sie dieses Kontrollkästchen aktiviert haben, können Sie durch Klicken auf Leere XML-Tags für nachfolgende Trennzeichen erstellen festlegen, dass leere XML-Tags für nachfolgende Trennzeichen im XML-Zwischenformat erstellt werden.
CONTRL-Bestätigung ist aktiviert, wurde jedoch nicht generiert
Symptom
In den Einstellungen für die Bestätigungsgenerierung und -überprüfung für die sendende Partei ist das Kontrollkästchen Funktionsbestätigung generieren aktiviert, es wurde jedoch keine CONTRL-Bestätigung von der EDI-Empfangspipeline generiert.
Mögliche Ursache
In der CONTRL-Nachricht sind mehrere obligatorische Datenelemente enthalten, die aus dem Austausch kopiert werden müssen. Wenn das Datenelement im Austausch fehlt oder syntaktisch ungültig ist, kann von der Empfangspipeline keine syntaktisch gültige CONTRL-Nachricht generiert werden.
Auflösung
Melden Sie die Fehlerbedingung nicht mit einer CONTRL-Bestätigung, sondern auf andere Weise.
Fehlermeldung „Fehler beim Ausführen der Empfangspipeline“
Symptom
Beim Versuch, eine AS2-Empfangspipeline auszuführen, tritt der Fehler 80040154 auf.
Mögliche Ursache
Auf 64-Bit-Hostinstanzen werden Pipelines nicht unterstützt.
Lösung
Ordnen Sie die Pipeline einem 32-Bit-Host zu.
Eine X12-codierte Nachricht wird angehalten, wenn die portbasierte Authentifizierung aktiviert ist und BizTalk Server nicht auf Autorisierungs- und Sicherheitsinformationen zugreifen kann
Symptom
Wenn eine Nachricht über einen Empfangsport empfangen wird, für den die Authentifizierung aktiviert ist, und die Partei, die die Nachricht gesendet hat, nicht ermittelt werden kann, wird die Nachricht von BizTalk Server angehalten.
Mögliche Ursache
Wenn die Authentifizierung für einen Empfangsport aktiviert ist (die Eigenschaft Keine Authentifizierung ist für den Empfangsport deaktiviert), müssen in BizTalk Server Einstellungen für die Eigenschaften ISA1-2 (Autorisierungsqualifizierer und -informationen) und ISA3-4 (Sicherheitsqualifizierer und -informationen) festgelegt werden, damit der Austausch verarbeitet werden kann. Diese Eigenschaften werden auf der Seite X12-Austauschverarbeitungseigenschaften für die Partei als Austauschabsender festgelegt. Wenn BizTalk Server die Werte dieser Eigenschaften nicht ermitteln kann, wird die Nachricht angehalten.
Dies kann in zwei Varianten erfolgen. Im ersten Fall, wenn also die Partei, die die Nachricht gesendet hat, nicht von BizTalk Server ermittelt werden kann, werden die globalen EDI-Eigenschaften verwendet, und BizTalk Server kann nicht auf die Autorisierungs- und Sicherheitseinstellungen zugreifen. Folglich wird die Nachricht angehalten. Im zweiten Fall, wenn zwar die Partei von BizTalk Server ermittelt werden kann, die Eigenschaften ISA1-2 und ISA3-4 für die Partei jedoch nicht konfiguriert sind, kann BizTalk Server wieder nicht auf Autorisierungs- und Sicherheitsinformationen zugreifen, und die Nachricht wird angehalten.
Auflösung
Stellen Sie sicher, dass die Partei, von der die Nachricht gesendet wird, identifiziert werden kann und die Eigenschaften ISA1-2 und ISA3-4 in der Parteivereinbarung definiert sind.
Falscher SE01-Wert in einem aufgeteilten HIPAA-Unterdokument
Symptom
Im Transaktionssatz-Nachspann (Feld SE01) wird die Anzahl von Datensegmenten (einschließlich der Header- und Nachspannsegmente eines X12-/HIPAA-Dokuments) angegeben. Für ein aufgeteiltes HIPAA-Unterdokument übernimmt die EDI-Empfangspipeline jedoch den SE01-Wert des Originaldokuments, statt den Wert neu zu berechnen.
Ursache
Von der EDI-Empfangspipeline wird der Wert des Felds SE01 aus dem HIPAA-Originaldokument kopiert, um ein Unterdokument aufzuteilen.
Die Fehlermeldung über doppelte UNB5 oder UNH1 ist nicht aussagekräftig
Wenn BizTalk Server eine Nachricht mit einer doppelt vorhandenen UNB5 (Austauschkontrollnummer) oder UNH1 (Transaktionssatz-Verweisnummer) empfängt, wird die Ursache des Problems im bereitgestellten Fehlercode und in der zugehörigen Beschreibung nicht eindeutig angegeben.
In BizTalk Server wird ein sehr großer Austausch angehalten, wenn nicht genügend Arbeitsspeicher zur Verfügung steht
Beim Analysieren eines sehr großen Austauschs steht in BizTalk Server möglicherweise nicht genügend Arbeitsspeicher zur Verfügung. Wenn dieser Fall eintritt, wird eine Fehlermeldung ausgegeben, und der Austausch wird angehalten. Auf der Gruppenhubseite wird nicht der gesamte Inhalt eines angehaltenen sehr großen Austauschs angezeigt. Sie können den ersten Teil der Nachricht anzeigen. Ansonsten ist die anzeigbare Menge von Daten eines angehaltenen Austauschs in BizTalk Server jedoch begrenzt.
Koreanische Zeichen, die einer Auflistung in einem KEDIFACT-Schema hinzugefügt werden, müssen das UNICODE-Format aufweisen
Wenn BizTalk Server einen KEDIFACT-codierten Austausch mit koreanischen Zeichen empfängt, wird der im Feld UNB2 festgelegte Codepage-/Zeichensatzwert zum Verarbeiten des Austauschs verwendet. Wenn Sie jedoch ein KEDIFACT-Schema ändern, indem Sie einer Auflistung ein koreanisches Zeichen mit einem ID-Datentyp hinzufügen, müssen Sie den Wert wie oben im Schema angegeben im Unicode-Format (UTF-16) hinzufügen.
Das Ausführen einer EDI-Empfangspipeline in einer Orchestrierung wird nicht unterstützt
In BizTalk Server können Sie in der Regel Empfangspipelines innerhalb eines Ausdrucks-Shapes in einer Orchestrierung ausführen. Diese Funktion wurde für die EDIReceive- oder AS2EdiReceive-Pipeline noch nicht getestet und wird daher nicht unterstützt.
BizTalk-EDI-Anwendung darf nicht geändert werden
Elemente in der BizTalk-EDI-Anwendung dürfen weder geändert noch gelöscht werden. Wenn Änderungen an dieser Anwendung vorgenommen werden, haben Sie keine Möglichkeit mehr, die Originalanwendung durch Dekonfigurieren und Neukonfigurieren der EDI- und AS2-Funktionen wiederherzustellen.
Weitere Informationen
Bekannte Probleme bei der EDI-Verarbeitung
Empfangen von EDI-Nachrichten in BizTalk Server
Exemplarische Vorgehensweise (X12): Empfangen von EDI-Austauschvorgängen und Zurücksenden einer Bestätigung