Bekannte Probleme mit der AS2-Verarbeitung

Dieser Abschnitt enthält Themen, in denen bekannte Probleme mit BizTalk Server AS2-Lösungen beschrieben werden.

Die AS2-Verarbeitung wird auf 64-Bit-Computern nicht unterstützt

Die BizTalk Server AS2-Lösung wird auf 64-Bit-Computern nicht unterstützt. Die AS2-Verarbeitung funktioniert nur auf 32-Bit-Computern oder bei der Ausführung unter einem WOW64-Emulator auf 64-Bit-Computern.

Die AS2-Empfangspipelines erfordern, dass das Konto, unter dem der isolierte BizTalk-Hostinstanzprozess ausgeführt wird, Teil der Gruppe „BizTalk-Anwendungsbenutzer“ ist

Wenn Sie die AS2EdiReceive- oder AS2Receive-Pipeline verwenden, müssen Sie das Benutzerkonto hinzufügen, unter dem der isolierte BizTalk-Hostinstanzprozess ausgeführt wird, zur Gruppe BizTalk-Anwendungsbenutzer hinzufügen. Die AS2EdiReceive- und AS2Receive-Pipelines werden im isolierten BizTalk-Hostinstanzprozess ausgeführt.

Ein leerer Receipt-Delivery-Option-Header führt zum synchronen Senden einer MDN

Wenn die AS2Receive-Pipeline eine Nachricht mit einem leeren Receipt-Delivery-Option-Header empfängt und eine asynchrone MDN angefordert ist, ignoriert die Pipeline die asynchrone MDN-Anforderung. Stattdessen wird eine synchrone MDN zurückgesendet und ein Fehler in das Ereignisprotokoll und in den AS2-Statusbericht (sofern aktiviert) eingetragen. Dies tritt auf, wenn die Eigenschaft „Eigenschaften eingehender Nachrichten außer Kraft setzen“ nicht aktiviert ist. Wenn diese Eigenschaft aktiviert ist, setzt sie den Receipt-Delivery-Option-Header in der Nachricht mit dem Wert der Receipt-Delivery-Option-Eigenschaft in der Partei auf der Seite AS2-Nachrichtenabsender des Dialogfelds AS2-Eigenschaften außer Kraft.

In dieser Instanz besitzt die AS2Receive-Pipeline keine Adresse zum Senden der MDN-Antwort über eine asynchrone Verbindung, da der Receipt-Delivery-Option-Header leer ist. Die Pipeline verfügt jedoch weiterhin über eine geöffnete synchrone Verbindung, daher sendet sie die MDN über diese Verbindung zurück. Wenn dies ein unidirektionaler Empfangsport ist, schließt BizTalk Server die Verbindung, nachdem die HTTP 200OK-Nachricht gesendet wurde.

Verwendung erweiterter und reduzierter HTTP-Zeilenheader

Um eine maximale Interoperabilität zu erreichen, sollten Sie erweiterte HTTP-Zeilenheader für AS2-Nachrichten verwenden. Internetinformationsdienste 7.0 (IIS) unterstützt nur erweiterte HTTP-Header. IIS 6.0 unterstützt sowohl reduzierte als auch erweiterte Header. Es können jedoch nicht alle Systeme Header mit mehr als 80 Zeichen pro Zeile unterstützen, daher sollten für diese Systeme reduzierte Zeilen verwendet werden.

Die Standardeinstellung für AS2 in BizTalk Server sind aufgeklappte HTTP-Zeilenheader.

Lokalisierter Name kann sich auf Parteiauflösung auswirken

Wenn BizTalk Server eine Parteiauflösung für eine ausgehende AS2-Nachricht durchführt, kann sich ein lokalisierter Wert im Nachrichtenheader auf die Parteiauflösung auswirken. Wenn für die Parteieigenschaft AS2-To auf der Seite Partei als AS2-Nachrichtenempfänger des Dialogfelds AS2-Eigenschaften standardmäßig ein englischer Parteiname festgelegt ist und der Wert im AS2-To-Header der AS2-Nachricht auf einen nicht englischen Namen eingestellt ist, dann wird keine Übereinstimmung gefunden.

Größenbeschränkung für AS2-Nachrichten

Verschlüsselte AS2-Nachrichten sollten kleiner als 96 MB sein, damit sie verarbeitet werden können. Diese Beschränkung wird vom AS2-Decoder auferlegt, der Teil der AS2Receive- und AS2EdiReceive-Pipelines ist.

Eine Möglichkeit zur Problemumgehung für diese Größenbeschränkung ist die Verwendung der Komprimierung, da eine AS2-Nachricht vor der Verschlüsselung komprimiert wird.

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.

Partner lehnt möglicherweise mehrteilige Nachrichten ab

Symptom

Wenn Sie mehrteilige Nachrichten mithilfe der AS2-Sendepipeline senden, lehnt Ihr Partner die Nachricht möglicherweise aufgrund eines fehlenden Content-Type MIME-Headers ab.

Mögliche Ursache

Content-Type ist ein optionaler Header, der für jeden Nachrichtentextteil in einer mehrteiligen Nachricht vorhanden sein kann. Einige Partner erfordern, dass dieser Header für jeden Nachrichtentextteil vorhanden und auf einen bestimmten Inhaltstyp eingestellt ist.

Lösung

Wenn Ihr Partner den Content-Type-Headerwert für jeden Nachrichtentextteil erfordert, müssen Sie eine benutzerdefinierte Pipelinekomponente erstellen, die diese Eigenschaft festlegt und dann die Komponente in der Sendepipeline verwenden.

Beim Empfangen von mehrteiligen Nachrichten wird der erste Teil als Textteil betrachtet

Symptom

Beim Empfangen einer mehrteiligen AS2-Nachricht identifizieren BizTalk Server möglicherweise eine der Anlagen fälschlicherweise als Nachrichtentext.

Mögliche Ursache

Der MIME-Header einer mehrteiligen/zugehörigen Nachricht kann einen optionalen start-Parameter enthalten, der angibt, welche Teile als Nachrichtentextteil behandelt werden sollen, indem die Inhalts-ID des Teils angegeben wird. Wenn der Startparameter nicht vorhanden ist, sollte der erste Teil als Text der Nachricht betrachtet werden. BizTalk Server berücksichtigt den start-Parameter nicht, wenn er vorhanden ist, und behandelt den ersten Teil immer als Nachrichtentext.

Auflösung

Wenn Ihr Partner den Nachrichtentextteil nicht als ersten Teil der mehrteiligen/zugehörigen Nachricht senden kann, müssen Sie eine Pipelinekomponente erstellen, die den Nachrichtentextteil ordnungsgemäß erkennt.

Weitere Informationen

Problembehandlung bei EDI- und AS2-Lösungen
Architektur von AS2-Lösungen
Entwickeln und Konfigurieren von BizTalk Server-AS2-Lösungen