Instanciation et initialisation d'un adaptateur d'envoi

Par défaut, les adaptateurs d'envoi ne sont pas instanciés tant que le premier message ne leur est pas remis, processus appelé « création différée ». Cette approche de création différée par défaut permet de préserver les ressources système. Une fois l'adaptateur d'envoi créé, il est mis en cache et est actif jusqu'à ce que le service BizTalk Server soit arrêté.

Le membre InitTransmitterOnServiceStart de l’énumération Capabilities demande au moteur de messagerie de créer l’adaptateur d’envoi au démarrage du service, plutôt que d’utiliser la création lazy par défaut, si vous le souhaitez.

L'envoi d'un message diffère de la réception en ce qui concerne le traitement par lots des messages. Lors de la réception, l'adaptateur dispose de messages entrants à insérer dans un lot transmis par le moteur de messagerie. Dans le cas de l'envoi, le moteur de messagerie reçoit un lot de la part de l'adaptateur et envoie les messages à l'adaptateur pour transmission. Les deux processus utilisent le proxy de transport pour obtenir les objets du lot de messages.

Initialisation d'un adaptateur d'envoi

Pour permettre la configuration et la liaison vers le proxy de transport, les adaptateurs doivent implémenter les interfaces de configuration suivantes :

• IBTTransport

• IBaseComponent

• IBTTransportControl

• IPersistPropertyBag

  Les étapes suivantes décrivent la séquence d'événements impliqués dans l'initialisation d'un adaptateur d'envoi :

1. Lorsque le moteur de messagerie initialise une carte d’envoi, il effectue d’abord une requête QueryInterface pour IPersistPropertyBag, qui est une interface facultative. Si l’adaptateur implémente l’interface, la configuration du gestionnaire est passée à l’adaptateur dans l’appel de méthode Load . L'adaptateur utilise ces informations pour vérifier sa bonne configuration.

2. Le moteur de messagerie effectue une requête QueryInterface pour IBTTransportControl, qui est une interface obligatoire.

3. Le moteur appelle IBTTransportControl.Initialize, en passant le proxy de transport de l’adaptateur.

4. Le moteur de messagerie effectue une requête QueryInterface pour IBTTransmitter.

   Si le moteur de messagerie découvre cette interface, l'adaptateur est traité comme un émetteur ne dépendant pas des lots.

   Si le moteur de messagerie ne découvre pas cette interface, le moteur de messagerie effectue une requête QueryInterface pour IBTBatchTransmitter, dont la découverte indique que l’adaptateur est un émetteur prenant en charge les lots.

   Si le moteur de messagerie ne découvre aucune de ces interfaces, une erreur survient, qui entraîne l'échec de l'initialisation. L'initialisation échoue si les interfaces obligatoires ne sont pas découvertes.

   Le schéma ci-dessous illustre cette séquence d'appels d'API. Les interfaces en bleu sont implémentées par l'adaptateur.

   

   L'adaptateur peut envoyer des messages dès qu'il est initialisé et configuré.

   Le schéma ci-dessous indique les interactions d'objets impliquées dans l'initialisation d'un adaptateur d'envoi.

   
   Workflow d'initialisation d'un adaptateur d'envoi

Notes

Les adaptateurs ne doivent pas bloquer le moteur de messagerie dans les appels tels que IBTTransportControl.Initialize et IPersistPropertyBag.Load. Un traitement excessif dans ces appels peut avoir un impact négatif sur le délai de démarrage du service.