CORRECTIF : Un correctif est disponible qui fournit des propriétés de Mode de livraison supplémentaires pour le protocole de couche inférieure minimale envoyer et recevoir des cartes de BizTalk Accelerator pour HL7 dans un environnement BizTalk Server 2010

Résumé

Cet article décrit un correctif qui fournit deux propriétés supplémentaires de la Mode de livraison pour Minimal inférieur couche protocole (MLLP), envoyer et recevoir des ports lorsque vous utilisez BizTalk Accelerator pour HL7 dans un environnement Microsoft BizTalk Server 2010 :
  • Utiliser l’accusé de réception de Transport MLLP
    Cette propriété est disponible dans unidirectionnelle reçoivent les ports et les ports d’envoi unidirectionnels.
  • Suspendre le Message de demande sur le Transport MLLP NAK
    Cette propriété est disponible uniquement dans le port d’envoi unidirectionnel.
Le MLLP de réception prend en charge de la carte les deux modes de réponse de demande unidirectionnelle et bidirectionnelle. Si l’adaptateur de réception est configuré, le traitement de HL7 utilise le paramètre de Livraison chronologique des messages . Cela garantit que l’ordre de remise du message. Lors de la réception de la MLLP carte fonctionne en mode bidirectionnel, la carte ne reçoit pas un message à partir du système en amont jusqu'à ce que la carte génère un accusé de réception de l’application (MSA) pour le message précédent dans le système en amont. L’accusé de réception/NON-RÉCEPTION générée est envoyée à la base de données de boîte de message (MessageBoxDB). MessageBoxDB attend que l’intervalle d’interrogation suivant avant d’envoyer l’accusé de réception/NON-RÉCEPTION dans le système en amont.

Le système en amont envoie un seul message à la fois, et uniquement après avoir reçu une accusé de réception/NON-RÉCEPTION. En outre, l’intervalle d’interrogation de BizTalk est configuré, et que le paramètre de Livraison chronologique des messages est défini sur True. Cela signifie que le nombre de messages traités par seconde est limité. Ce correctif fournit une configuration supplémentaire pour envoi unidirectionnel et ports de réception. Il n’affecte pas l’accusé de réception/NON-RÉCEPTION. Toutefois, elle augmente considérablement le nombre de documents traités par seconde.

Vous devez utiliser les compteurs de performance pour prendre une configuration de référence avant et après avoir appliqué ce correctif. Lorsque vous évaluez, vous devez les envoyer un nombre raisonnable de messages sur une période raisonnable. Par exemple, vous pouvez utiliser les éléments suivants :
  • Pour le BizTalk : messagerie catégorie, utilisez le compteur Documents traités/Sec .
  • Pour le BizTalk : latence de messagerie catégorie, utilisez tous les compteurs disponibles.

Permet d’augmenter le nombre de documents traités par seconde est de réduire le paramètre MaxReceiveInterval pour l’hôte BizTalk. En fonction de l’environnement global, sur le réglage de l’ordinateur qui exécute Biz Talk Server 2010 et réduisant le paramètre MaxReceiveInterval sur le volume de documents traités, peut avoir un effet néfaste sur les performances de l’instance de SQL Server. Pour le réglage de SQL Server et pour le réglage de BizTalk, reportez-vous à tous les articles techniques disponibles.

Plus d'informations

Remarque Ce hotfix résout également un problème dans Microsoft BizTalk Accelerator 2010 pour HL7. Pour plus d’informations sur ce problème, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
2454887 événements peuvent être incorrectement enregistrés pour un message MLLP en 2009 de BizTalk Accelerator pour HL7 sur un ordinateur qui exécute Microsoft BizTalk Server 2009 ou Microsoft BizTalk Server 2010

Informations sur le correctif

Un correctif pris en charge est disponible auprès de Microsoft. Toutefois, ce correctif vise à corriger uniquement le problème décrit dans cet article. Appliquez ce correctif uniquement aux systèmes qui rencontrent le problème décrit dans cet article. Ce correctif va peut-être subir des tests supplémentaires. Par conséquent, si vous n'êtes pas sérieusement concerné par ce problème, nous vous recommandons d'attendre la prochaine mise à jour logicielle qui contiendra ce correctif.

Si le correctif est disponible pour le téléchargement, il existe une section « Téléchargement de correctif logiciel disponible » au début de cet article de la Base de connaissances. Si cette section n'apparaît pas, contactez le Service clientèle et Support de Microsoft pour obtenir le correctif.

Remarque Si des problèmes supplémentaires se produisent ou si des procédures de dépannage sont nécessaires, vous devrez peut-être formuler une demande de service distincte. Les coûts habituels du support technique s'appliqueront aux questions et problèmes qui ne relèvent pas de ce correctif logiciel. Pour une liste complète des numéros de téléphone du service clientèle de Microsoft ou pour créer une demande de service distincte, visitez le site Web Microsoft suivant :Remarque Le formulaire « Téléchargement de correctif logiciel disponible » affiche les langues pour lesquelles le correctif est disponible. Si vous ne voyez pas votre langue, c'est parce qu'il n'y a pas de correctif disponible pour cette langue.

Conditions préalables

Vous devez disposer de Microsoft BizTalk Accelerator pour HL7 (BTAHL7) est installé pour appliquer ce correctif.

Informations sur le redémarrage

Vous devrez peut-être redémarrer votre ordinateur après avoir appliqué ce correctif. Si vous n’êtes pas invité à redémarrer, vous devez redémarrer les services BizTalk. Pour plus d’informations sur cette procédure, consultez le fichier Readme.txt qui est inclus dans ce package de correctifs.

Informations sur le remplacement

Ce correctif ne remplace pas un correctif précédemment publié.

Informations sur les fichiers

La version anglaise de ce correctif dispose des attributs de fichier (ou version ultérieure) répertoriés dans le tableau suivant. Les dates et heures de ces fichiers sont répertoriées en temps universel coordonné (UTC). Lorsque vous affichez les informations de fichier, elles sont converties en heure locale. Pour trouver la différence entre l’UTC et l’heure locale, utilisez l’onglet fuseau horaire dans l’élément de Date et heure dans le panneau de configuration.

Nom de fichierVersion de fichierTaille du fichierDateHeurePlateforme
Microsoft.solutions.btahl7.mllp.dll3.9.526.2116,60807-Jun-201115:27x86
Microsoft.solutions.btahl7.shared.dll3.9.526.292,04007-Jun-201115:27x86
Mllpreceive.exe3.9.526.226,45607-Jun-201115:27x86
Mllpsend.exe3.9.526.226,44807-Jun-201115:27x86

À propos du correctif

Une fois que le correctif est installé et configuré le flux des messages

Après avoir appliqué et activer ce correctif, l’adaptateur MLLP envoie un message qui est reçu par l’adaptateur MLLP à MessageBoxDB. Le Gestionnaire de Point final (EPM) rappelle la carte ainsi que l’état de la soumission dans la méthode BatchComplete . Ainsi, la carte à envoyer l’accusé de réception/NON-RÉCEPTION de validation au système en amont. À son tour, le système en amont reçoit l’accusé de réception/NON-RÉCEPTION et envoie ensuite le message suivant. La méthode BatchComplete est indépendante du paramètre MaxReceiveInterval et est appelée immédiatement après que le message est envoyé à BizTalk.

Dès que le message est prêt à être envoyé, l’adaptateur d’envoi transmet le message au système en aval. L’accusé de réception/NON-RÉCEPTION est attendue si la propriété d’Accusé de réception de Transport utilisation MLLP est définie sur True. Si l’envoi est un accusé de réception, BizTalk a terminé le traitement avec succès. Si l’envoi est un NAK, et si la propriété de Suspendre le Message de demande sur un NAK de Transport MLLP est définie sur True, le message est suspendu directement sans nouvelle tentative en cours. Cependant, si la propriété de Suspendre le Message de demande sur un NAK de Transport MLLP est définie sur False, BizTalk tentera basé sur les paramètres d’intervalle send port réessayer. (Par défaut, la propriété de Suspendre le Message de demande sur un NAK de Transport MLLP est définie sur False).

Le diagramme suivant illustre le flux des messages :
Message flow
  1. Adaptateur de réception du message qui est envoyé par l’application émettrice est traitée par le MLLP de système en amont.
  2. L’adaptateur MLLP envoie le message vers BizTalk/EPM.
  3. EPM rappelle la carte sur l’état d’envoi de message. EPM pour cela dans la méthode Complète du traitement par lots .
  4. Une validation accusé de réception/NON-RÉCEPTION est générée par l’adaptateur MLLP et est basée sur l’état d’envoi de lot. L’accusé de réception/NON-RÉCEPTION est envoyée à l’application émettrice.

    Remarque Si l’état d’envoi de lot est la Réussite, l’adaptateur retourne l’accusé de réception. Toutefois, s’il y a une défaillance, ou si l’expiration de la soumission (par exemple, si l’appel de méthode Lot complet ), l’adaptateur retourne la NAK à l’application émettrice.

  5. EPM cède le message pour l’envoi adaptateur MLLP pour la transmission.
  6. Le MLLP envoyer carte envoie le message traité au système en aval.
  7. L’accusé de réception/NON-RÉCEPTION de niveau transport attendu par l’adaptateur MLLP envoyer pour terminer la communication.
  8. Si le message à l’étape 7 est un accusé de réception, la carte demande EPM pour supprimer le message. Dans le cas contraire, l’adaptateur doit demander l’EPM pour une nouvelle tentative qui est basée sur le paramètre d’intervalle de nouvelle tentative. Une nouvelle option est fournie dans le paramètre de configuration de port envoyer pour suspendre le message directement, sans une nouvelle tentative, si la réception d’un NAK MLLP. Par défaut, cette option a la valeur False. Si cette option est définie sur True, le message sera suspendu directement, sans une nouvelle tentative, si la réception d’un NAK MLLP.

Format de transport niveau ACK/NACK

Le site Web contient les informations suivantes :
  • Exemple d’un accusé de réception de validation MLLP :
    <SB><ACK><EB><CR>
  • Exemple d’un négatif MLLP valider l’accusé de réception :
    <SB><NAK><EB><CR>
Remarques
  • Dans ces exemples, < SB > fait référence au caractère de début de bloc (1 octet). Cela correspond à un caractère ASCII de < VT > ou < 0x0B >.

    Cela est différent avec les SOH STX ASCII caractères.
  • Dans ces exemples, < ACK > ou < NAK > reportez-vous au caractère d’accusé de réception (à 1 octet. Correspond à un caractère ASCII de < ACK > ou < 0 x 06 >) ou le caractère accusé de réception négatif (à 1 octet. Correspond à un caractère ASCII de < NAK > ou < 0x15 >).
  • Dans ces exemples, < EB > fait référence au caractère de fin de bloc (1 octet). Cela correspond à un caractère ASCII de < FS > ou < 0x1C >.
  • Dans ces exemples, < CR > fait référence au caractère de retour chariot (1 octet). Cela correspond à un caractère ASCII de < CR > ou < 0x0D >.
  • Microsoft fournit des informations pour contacter des sociétés tierces afin de vous aider à obtenir une aide technique. Ces coordonnées peuvent changer sans préavis. Microsoft ne garantit pas l'exactitude des informations de contact de ces tiers.

Comment faire pour configurer la réception et à utiliser les nouvelles propriétés de ports d’envoi

Configurer la réception et les ports d’envoi comme suit.

Remarque Les paramètres de port de réception et d’envoi peuvent être utilisées indépendamment ou ensemble.

Configuration du port de réception
  • Le port doit être un port unidirectionnel.
  • Le paramètre de Livraison chronologique des messages doit être activé.
  • Vous devez définir la propriété d’Accusé de réception de Transport utilisation MLLP à True pour activer l’accusé de réception au niveau transport. Par défaut, cette propriété a la valeur false pour les ports existants ou de nouveaux ports.
Receive port
Envoyer la configuration de port
  • Le port doit être un port unidirectionnel.
  • Le mode de sollicitation-réponse doit être défini sur non.
  • Le paramètre de Livraison chronologique des messages doit être activé.
  • Vous devez définir la propriété d’Accusé de réception de Transport utilisation MLLP à True pour activer l’accusé de réception au niveau transport. Par défaut, cette propriété a la valeur false pour les ports existants ou de nouveaux ports.
  • Vous devez définir la propriété de Suspendre le Message de demande sur MLLP Transport NAK true si les messages doivent être suspendus directement sans être tentée à nouveau lors de la réception d’un NAK de Transport à partir d’un système en aval. Dans le cas contraire, le message sera tentée à nouveau pour le nombre de fois défini dans le transport avancé des options d’envoi du port. Par défaut, cette propriété a la valeur false pour les ports existants ou de nouveaux ports.
Send port

À propos de la propriété « Accusé de Transport MLLP utilisation »

Le tableau suivant décrit le comportement attendu des ports unidirectionnels ou bidirectionnels qui utilisent la propriété d’Accusé de réception de Transport MLLP utiliser . La combinaison nécessaire de paramètres doit être appliquée comme décrit dans la section « Comment faire activer le correctif logiciel ».

Remarques
  • « Système en amont » fait référence à l’application émettrice. Il envoie des messages à BizTalk Server. Ces messages sont entrants pour BizTalk.
  • « Système en aval » fait référence à l’application de réception. Il reçoit les messages à partir de BizTalk. Ces messages sont sortant vers BizTalk.


Type de portOption MLLP V2Option de MLLP V2
À sens unique de réceptionEnvoyer l’accusé de réception/NON-RÉCEPTION de MLLP au système en amont dans la méthode BatchComplete .Aucun changement dans le comportement. Dans ce cas, aucun accusé de réception/NON-RÉCEPTION n’est envoyée au système en amont.
Bidirectionnelle de réceptionAucun changement dans le comportement. Dans ce cas, l’accusé de réception/NON-RÉCEPTION HL7 dans la méthode TransmitMessage est envoyée au système en amont.

Remarque : Cette option n’est pas pris en charge. Par exemple, ignorer même si la valeur est définie sur True.
Aucun changement dans le comportement. Dans ce cas, l’accusé de réception/NON-RÉCEPTION HL7 dans la méthode TransmitMessage est envoyée au système en amont.
Envoi unidirectionnelL’accusé de réception/NON-RÉCEPTION MLLP à partir du système en aval est attendue pour une fois que le message est transmis.Aucun changement dans le comportement. Dans ce cas, l’accusé de réception/NON-RÉCEPTION du système en aval n’est pas attendue pour une fois que le message est transmis.
Envoi bidirectionnel ou envoi unidirectionnel en mode sollicitation-réponseAucun changement dans le comportement. Dans ce cas, l’accusé de réception/NON-RÉCEPTION HL7 du système en aval est attendue pour une fois que le message est transmis.

Remarque : Cette option n’est pas pris en charge. Par exemple, ignorer même si la valeur est définie sur True.
Aucun changement dans le comportement. Dans ce cas, l’accusé de réception/NON-RÉCEPTION HL7 du système en aval est attendue pour une fois que le message est transmis.


Bidirectionnelle recevoir et envoyer de comportement du port n’est pas modifié. Unidirectionnelle recevoir et envoyer de comportement du port n’est également pas modifié, à moins que la propriété Utilisation MLLP Transport accusé de réception est définie sur true.

Pour plus d’informations, reportez-vous à la documentation de la carte MLLP. Si elle est à sens unique de réception et les ports d’envoi ont la configuration appropriée, les performances s’améliorent. Si la propriété Accusé de Transport MLLP utilisation de bidirectionnel ou un port à sens unique est définie sur false, le type d’accusé de réception qui est généré se poursuit sans modifications. Dans ce cas, le type d’accusé de réception généré dépend des paramètres de l’application qui envoie le message BTAHL7 Configuration Explorateur. La valeur des champs MSH 15 et 16 de MSH d’un message spécifique peut remplacer ce paramètre. Toutefois, si la propriété Accusé de Transport MLLP utilisation de bidirectionnel ou un port à sens unique est définie sur false, vous pouvez définir la configuration pour les applications qui attendent que les accusés de réception statiques uniquement à l’aide de l’Explorateur de Configuration BTAHL7. Comportement de délai d’attente pour le port reste inchangé...

Le comportement attendu dans les cas lorsque les propriétés sont utilisées est la suivante :

RECEIVE
  • WrongMLLPFormat : le message n’est pas soumis à BizTalk Server.
  • WrongHL7Format : le message est soumis à BizTalk Server, et une accusé de réception/NON-RÉCEPTION de MLLP est transmise qui est basé sur l’état d’avancement du traitement par lots.
  • TransmittingSocketIssue : l’accusé de réception/NON-RÉCEPTION de MLLP n’est pas transmise, bien que le message est soumis à BizTalk Server.
  • ReceivingSocketIssue : le message n’est pas reçu et par conséquent n’est pas envoyé et aucune transmission de l’accusé de réception/NON-RÉCEPTION de MLLP n’est envoyée.
  • En cas d’échec de l’envoi à BizTalk, un NAK est transmis.
  • Si un état négatif de lot complet est reçu, un NAK est transmis.
Envoyer et le port d’envoi propriété « arrêter d’envoyer des messages supplémentaires en cas d’échec de message en cours » = True
  • WrongMLLPFormat : le message est interrompu car l’ACK/NACK de MLLP ne peut pas être lu. Le traitement continuera pas tant que les messages d’interruption sont désactivées.
  • WrongHL7Format : le message échoue avant qu’il atteigne la carte. Le traitement continuera pas tant que les messages d’interruption sont désactivées.
  • TransmittingSocketIssue : le message est interrompu. Le traitement continuera pas tant que les messages d’interruption sont désactivées.
  • ReceivingSocketIssue : le message est interrompu. Le traitement continuera pas tant que les messages d’interruption sont désactivées.

Le comportement attendu lorsque la propriété de Suspendre le Message de demande sur un NAK de Transport MLLP a la valeur True ou False est comme suit :
  • Lorsque la propriété de Suspendre le Message de demande sur un NAK de Transport MLLP a la valeur True et la réception d’un NAK, le message est interrompu sans une nouvelle tentative pour l’envoyer.
  • Lorsque la propriété de Suspendre le Message de demande sur un NAK de Transport MLLP est définie à la valeur par défaut False, une nouvelle tentative pour envoyer que le message est démarré, selon les paramètres d’intervalle send port réessayer.

Modifications apportées à l’utilitaire du Kit de développement logiciel MLLP

L’utilitaire de kit de développement logiciel MLLP comprend les nouveaux paramètres suivants. Tous les autres paramètres restent inchangés. Pour plus d’informations, reportez-vous à la documentation du produit.
  • Pour MLLPReceive.exe, utiliser le nouveau paramètre à renvoyer l’accusé de réception/NON-RÉCEPTION de MLLP après la réception du message. Par exemple :
    MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransACK
    MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransNAK
  • Pour MLLPSend.exe, utiliser le nouveau paramètre d’attente pour le MLLP accusé de réception/NON-RÉCEPTION. Par exemple :
    MLLPSend /sb 11 /eb 28 /cr 13 /f « C:\HL7\ls.txt » /I 127.0.0.1 /p 11000 /UseMLLPTransACK

Références

Pour plus d’informations sur la façon de gérer les paramètres de performances dans BizTalk server, visitez le site Web Microsoft Developer Network (MSDN) suivant :Pour plus d’informations sur les compteurs de performance de la messagerie, visitez le site Web MSDN suivant :Pour plus d’informations sur commandé la remise de Messages, visitez le site Web MSDN suivant :Pour plus d’informations sur BizTalk Accelerator de 2010 pour HL7 (BTAHL7), visitez le site Web de Microsoft suivant :Pour plus d’informations sur la méthode IBTBatchCallBack.BatchComplete , reportez-vous au site Web MSDN suivant :Pour plus d’informations sur les correctifs de BizTalk Server, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
2003907 des informations sur les correctifs de BizTalk Server
Propriétés

ID d'article : 2564013 - Dernière mise à jour : 26 janv. 2017 - Révision : 1

Commentaires