Problèmes connus avec le traitement AS2

Cette section contient des rubriques qui décrivent les problèmes connus liés aux solutions AS2 BizTalk Server.

Le traitement AS2 n'est pas pris en charge sur les ordinateurs 64 bits

La solution AS2 BizTalk Server n’est pas prise en charge sur les ordinateurs 64 bits. Le traitement AS2 ne fonctionne que sur les ordinateurs 32 bits ou lorsqu'il est exécuté sous l'émulateur WOW64 sur des ordinateurs 64 bits.

Les pipelines de réception AS2 requièrent que le compte sous lequel le processus d'instance de l'hôte BizTalk isolé est exécuté fasse partie du groupe Utilisateurs d'applications BizTalk

Si vous utilisez le pipeline AS2EdiReceive ou AS2Receive, vous devez ajouter le compte d'utilisateur que le processus d'instance de l'hôte BizTalk isolé exécute sous le groupe Utilisateurs d'applications BizTalk. Les pipelines AS2EdiReceive et AS2Receive sont exécutés dans le processus d'instance de l'hôte BizTalk isolé.

Un en-tête Receipt-Delivery-Option vide provoque l'envoi d'un MDN de façon synchrone

Si le pipeline AS2Receive reçoit un message avec un en-tête Receipt-Delivery-Option vide et qu'un MDN asynchrone est demandé, le pipeline ignore la demande de MDN asynchrone. Il renvoie un MDN synchrone et consigne une erreur dans le journal des événements et le rapport d'état AS2 (le cas échéant). Ce problème survient si la propriété « Remplacer les propriétés du message entrant » n'est pas activée. Si cette propriété est activée, elle remplace l'en-tête Receipt-Delivery-Option dans le message avec la valeur de la propriété Receipt-Delivery-Option dans la page Tiers considéré comme expéditeur des messages AS2 de la boîte de dialogue Propriétés AS2.

Dans ce cas, comme l'en-tête Receipt-Delivery-Option est vide, le pipeline AS2Receive n'a pas d'adresse vers laquelle envoyer la réponse MDN via une connexion asynchrone. Toutefois, le pipeline dispose toujours d'une connexion synchrone ouverte, de sorte qu'il renvoie le MDN via cette connexion. S'il s'agit d'un port de réception unidirectionnel, BizTalk Server ferme la connexion après avoir envoyé le message HTTP 200OK.

Utilisation des en-têtes de ligne HTTP déroulés et non déroulés

Pour garantir une interopérabilité maximale, vous devez utiliser des en-têtes de ligne HTTP déroulés pour les messages AS2. Information Services (IIS) 7.0 ne prend en charge que les en-têtes HTTP déroulés. IIS 6.0 prend en charge les en-têtes déroulés et non déroulés. En revanche, certains systèmes ne prennent pas en charge les en-têtes incluant plus de 80 caractères par ligne, de sorte que des lignes non déroulées doivent être utilisées.

La valeur par défaut pour AS2 dans BizTalk Server est les en-têtes de ligne HTTP dépliés.

La résolution du tiers peut être affectée par un nom localisé

Lorsque BizTalk Server effectue une résolution de tiers sur un message AS2 sortant, cette opération peut être affectée par une valeur localisée dans les en-têtes de message. Si la propriété de tiers AS2-To dans la page Tiers considéré comme récepteur des messages AS2 de la boîte de dialogue Propriétés est définie par défaut sur un nom de tiers anglais et que la valeur dans l'en-tête AS2-To du message AS2 est définie sur un nom non anglais, la correspondance n'est pas trouvée.

Limitation de la taille des messages AS2

La taille des messages AS2 chiffrés doit être inférieure à 96 mégaoctets pour que ceux-ci soient traités. Cette limitation est imposée par le Décodeur AS2, qui fait partie des pipelines AS2Receive et AS2EdiReceive.

Pour contourner cette limitation, vous pouvez utiliser la compression car un message AS2 est compressé avant d'être chiffré.

L'application EDI BizTalk ne doit pas être modifiée

Les artefacts de l'application EDI BizTalk ne doivent pas être modifiés ou supprimés. Si cette application est modifiée, vous ne pouvez pas revenir à l'application d'origine en annulant la configuration et en reconfigurant les fonctionnalités EDI et AS2.

Le partenaire peut rejeter les messages à parties multiples

Symptôme

Lors de l'envoi de messages à parties multiples à l'aide du pipeline d'envoi AS2, votre partenaire peut rejeter le message en raison de l'absence d'un en-tête MIME de type de contenu.

Cause possible

Cet en-tête facultatif peut être présent pour chaque partie du corps dans un message à parties multiples. Certains partenaires requièrent que cet en-tête soit présent pour chaque partie du corps et défini sur un en-tête de type de contenu spécifique.

Résolution :

Si votre partenaire requiert la valeur de l'en-tête de type de contenu pour chaque corps, vous devez créer un composant de pipeline personnalisé qui définit cette propriété et utiliser le composant dans le pipeline d'envoi.

Dans le cadre de la réception de messages à parties multiples, la première partie est considérée comme étant le corps

Symptôme

Lors de la réception d’un message AS2 en plusieurs parties, BizTalk Server peut identifier incorrectement l’une des pièces jointes comme corps du message.

Cause possible

L'en-tête MIME d'un message à parties multiples/associé peut contenir un paramètre facultatif de début indiquant les parties devant être traitées comme corps du message en spécifiant l'ID de contenu de la partie. Si le paramètre de démarrage n’est pas présent, la première partie doit être considérée comme le corps du message. BizTalk Server n’honore pas le paramètre de début s’il est présent et traite toujours la première partie comme le corps du message.

Résolution :

Si votre partenaire ne peut pas envoyer le corps comme étant la première partie du message à parties multiples/associé, vous devez créer un composant de pipeline qui identifie correctement le corps du message.

Voir aussi

Dépannage des solutions EDI et AS2
Architecture de la solution AS2
Développement et configuration de solutions AS2 BizTalk Server