Résolution d’autres problèmes
Résout d’autres problèmes liés à Microsoft BizTalk Accelerator pour HL7 (BTAHL7).
Message rejeté par le moteur BTAHL7
Symptôme
Les messages sont rejetés de manière aléatoire par le moteur de message.
Cause possible : selon la norme HL7, les valeurs d’énumération de la table 0338 contiennent la valeur « L&I ». Le champ 6 du segment PRA peut contenir cette valeur. Étant donné que BTAHL7 traite le caractère « & » comme un délimiteur, le message est rejeté.
Résolution : il existe trois solutions potentielles pour ce problème :
Dans le instance du message, gérez le caractère « & » via une séquence d’échappement, par exemple à l’aide de la combinaison de caractères L\T\I.
Ajoutez une valeur d’énumération « LI » à PRA 6 dans le schéma et utilisez cette valeur à la place dans le message instance.
Utilisez un séparateur de sous-composant complètement différent dans MSH2 ; toutefois, cette solution particulière peut ne pas être pratique en fonction de votre environnement.
Impossible de modifier le schéma HL7 à l’aide de Visual Studio
Symptôme
Impossible de modifier le schéma HL7 à l’aide de Microsoft Visual Studio.
Cause possible : Visual Studio ne prend pas en charge certains schémas HL7.
Résolution : utilisez d’autres éditeurs, tels que le Bloc-notes Microsoft, pour modifier des schémas HL7.
Échec de la gestion des messages sans journalisation d’erreurs
Symptôme
Le système traite les messages sans journaliser les messages d’erreur ni placer les messages dans la file d’attente des messages suspendus.
Cause possible : Les valeurs de propriété HeaderSpecType et DocumentSpecType respectent la casse. Lorsque vous déployez vos pipelines, une erreur typographique dans ces noms peut entraîner une mauvaise gestion et une suppression des messages sans qu’aucune erreur ne soit enregistrée.
Résolution : respectez la casse lors de l’utilisation des noms de valeurs de propriété HeaderSpecType et DocumentSpecType .
Les champs d’en-tête de message ne sont pas validés correctement
Symptôme
Échec de la validation d’un champ d’en-tête.
Raison : le sérialiseur BTAHL7 a validé une propriété promue, pas la propriété de contexte de champ d’en-tête réelle.
Cause possible : une modification s’est produite à la propriété promue correspondant à l’en-tête par le biais d’une orchestration ou d’une carte.
Résolution : les propriétés de contexte des en-têtes de message MSH1, MSH2 et MSH5{1-3} doivent être mises à jour afin qu’elles soient synchronisées avec les données.
L’adaptateur MLLP n’est pas supprimé pendant la désinstallation
Symptôme
Le programme d’installation BTAHL7 n’a pas supprimé l’adaptateur MLLP pendant la désinstallation de BTAHL7.
Cause possible : il existait un emplacement de réception ou un port d’envoi avec un type de transport MLLP. Le programme d’installation de BTAHL7 ne peut pas supprimer l’adaptateur MLLP s’il est référencé dans l’un des projets BizTalk Server.
Résolution : Une fois la désinstallation de BTAHL7 terminée, procédez comme suit :
Dans la console d’administration BizTalk Server, supprimez tous les emplacements de réception et les ports d’envoi qui ont un type de transport MLLP, ou modifiez le type de transport des emplacements de réception ou des ports d’envoi vers un autre type.
Dans la console d’administration, supprimez l’adaptateur MLLP.
Redémarrez le instance hôte.
Impossible de désinstaller BTAHL7 si BizTalk Server a déjà été désinstallé
Symptôme
La désinstallation de BTAHL7 entraîne l’erreur suivante :
A network error while attempting to read from file C:\Windows\Installer\Microsoft BizTalk <version\> Accelerator for HL7.msi
Cause possible : BizTalk Server a été désinstallé avant la tentative de désinstallation de BTAHL7. Vous devez désinstaller BTAHL7 avant de désinstaller BizTalk Server.
Résolution : réinstallez BizTalk Server, désinstallez BTAHL7, puis désinstallez BizTalk Server.
Les messages sont toujours envoyés après l’arrêt du port d’envoi MLLP applicable
Symptôme
Une fois que vous avez arrêté un port d’envoi MLLP, les messages envoyés via ce port d’envoi ne s’arrêtent pas, mais continuent d’être envoyés.
Cause possible : lorsque vous arrêtez un port d’envoi, la connexion reste établie jusqu’à ce qu’elle soit supprimée en arrêtant l’hôte BizTalk. Par conséquent, les messages sont toujours envoyés une fois que le port d’envoi a été arrêté. Cela se produit parce que Biztalk Server n’appelle pas l’adaptateur MLLP au démarrage ou à l’arrêt du port d’envoi. BizTalk Server appelle l’adaptateur MLLP uniquement pendant le démarrage et l’arrêt du service hôte.
Résolution : vous pouvez supprimer la connexion et arrêter la transmission de messages en arrêtant le instance hôte qui est le gestionnaire d’envoi pour le port d’envoi que vous avez arrêté. Toutefois, l’arrêt de cette instance hôte peut affecter d’autres messages que vous ne souhaitez pas arrêter. Si vous savez que c’est le cas, vous devez configurer le port d’envoi différemment lorsque vous le créez. Vous devez créer un autre instance hôte pour servir de gestionnaire d’envoi uniquement pour ce port d’envoi MLLP (ou un sous-ensemble de vos ports d’envoi). Vous pouvez ensuite arrêter la transmission de messages à partir de ce port d’envoi en arrêtant cette instance hôte. Cela n’affectera pas la transmission d’autres messages sur d’autres ports d’envoi qui utilisent d’autres gestionnaires d’envoi.