Traitement de l’adaptateur de réception MLLP
L’adaptateur de réception MLLP (Minimal Lower Layer Protocol) prend en charge les modes de réponse de requête unidirectionnel et bidirectionnel. L’adaptateur écoute et accepte les connexions.
Lorsque l’adaptateur de réception MLLP fonctionne en mode bidirectionnel, l’adaptateur ne reçoit pas de nouveau message de la connexion tant que le pipeline n’a pas généré l’accusé de réception (ACK) pour le message précédent.
Paramètres de configuration
Les paramètres d’un gestionnaire de réception sont configurés au niveau de l’hôte BizTalk et s’appliquent à tous les emplacements de réception MLLP qui lui sont associés.
| Paramètre | Utilisation |
|---|---|
| Limite maximale d’acceptation des connexions | Limite le nombre de connexions ouvertes simultanées que l’adaptateur de réception acceptera. |
Accusés de réception avec l’adaptateur de réception MLLP bidirectionnel
Lorsqu’un adaptateur de réception MLLP bidirectionnel reçoit un message, Microsoft BizTalk Accelerator pour HL7 (BTAHL7) peut générer les types suivants de clés ACK :
HL7 Enhanced Commit ACK : dans ce scénario, BTAHL7 envoie un commit ACK sur la même connexion. Il envoie une ACK d’acceptation d’application sur un port d’envoi différent.
ACK d’acceptation d’application : dans ce scénario, BTAHL7 envoie un ACK d’acceptation d’application sur la même connexion.
ACK statique : dans ce scénario, BTAHL7 envoie un ACK sur la même connexion.
Le type d’ACK généré dépend des paramètres de configuration BTAHL7 Explorer pour la partie qui envoie le message. La valeur dans les champs MSH 15 et 16 d’un message individuel peut remplacer ce paramètre. Toutefois, pour les applications qui attendent des AK statiques, la configuration ne peut être définie que par le biais de Explorer de configuration BTAHL7.
Conditions d'erreur
Les événements suivants se produisent en cas de condition d’erreur ou d’inactivité :
Si l’emplacement de réception est désactivé ou BizTalk Server s’arrête, les opérations suivantes se produisent :
L’emplacement de réception n’accepte plus les nouvelles connexions.
Pour les connexions existantes, BizTalk Server reçoit complètement le message actuel, puis ferme la connexion.
Lorsque l’inactivité est détectée (aucune donnée de charge utile reçue sur l’emplacement de réception dans le délai d’expiration spécifié), l’adaptateur ferme la connexion.
Si BizTalk Server reçoit un message incomplet, la partie reçue est suspendue. Tous les octets reçus en dehors d’un message (avant le premier SB sur une nouvelle connexion, entre EB/CR et SB du message suivant) sont ignorés.
Si le pipeline ne parvient pas à analyser le message, le message est toujours remis à la base de données MessageBox, avec une propriété promue ParseError=true.
Si un message échoue en raison de l’absence d’un abonnement, ou en raison d’erreurs structurelles dans l’en-tête, BizTalk Server suspend le message dans sa forme « filaire » d’origine (avant analyse). Une raison fréquente de l’échec de l’absence d’abonnement est l’absence de propriétés promues. Depuis BizTalk Server suspend le message non traité, le BTS. MessageType est vide.
Le tableau suivant répertorie les erreurs retournées par l’adaptateur de réception MLLP.
| Événement | id | Condition d'erreur |
|---|---|---|
| ErrorListening | 8448 | Impossible de lier à un socket local (très probablement, une autre application locale utilise la même combinaison adresse IP/ID de port). |
| ErrorAcceptingConnection | 8449 | Impossible d’établir une connexion TCP avec le tiers distant. Soit BizTalk Server atteint la limite de connexion maximale, soit les ressources étaient insuffisantes. |
| ErrorSubmittingMessage | 8452 | La base de données MessageBox n’a pas pu accepter le message. Soit SQL Server n’était pas disponible, soit les ressources étaient insuffisantes. |
| ErrorSendingAck | 8454 | BizTalk Server n’a pas pu retourner l’accusé de réception, car la connexion n’était pas disponible. |
Compteurs de performances
Le tableau suivant répertorie les compteurs de performances que l’adaptateur MLLP utilise.
| Compteur | Signification |
|---|---|
| Octets | Taille de la charge utile de tous les documents reçus ou envoyés. |
| Octets/s | Débit actuel de la charge utile reçue ou envoyée. |
| Documents traités | Réception MLLP : Nombre de documents remis à la base de données MessageBox. Envoi MLLP : Nombre de documents remis à l’application distante. |
| Échec des documents | Réception MLLP : Nombre de documents qui n’ont pas été remis à la base de données MessageBox. Envoi MLLP : Nombre de documents qui n’ont pas été remis à l’application distante. |
| État de la connexion | Status de la connexion de l’adaptateur, 1 ou 0 (1=connecté). |
Les instances de compteur de performances utilisent le schéma d’affectation de noms suivant :
{recv|trans} : connection name : remote IP address : remote port ID
Où l’adaptateur de réception MLLP utilise le préfixe « recv » et l’adaptateur d’envoi MLLP utilise « trans ».
Notes
Les kits ACL envoyés par les ports de réception (par exemple, un adaptateur fonctionnant en mode bidirectionnel) et les ports d’envoi (qui fonctionnent pour recevoir des kits ACL sur la même connexion de socket) ne sont pas pris en compte.
Voir aussi
Traitement des messages encodés avec MLLP
Paramètres de configuration pour les adaptateurs d’envoi et de réception
Traitement de l’adaptateur d’envoi MLLP
Configuration d’un port d’envoi pour recevoir les accusés de réception