Partager via


Instanciation d'adaptateurs isolés

Comme indiqué précédemment, les adaptateurs ne sont pas instanciés par BizTalk Server. Au lieu de cela, ils sont instanciés et hébergés dans un autre processus. Il incombe à l’adaptateur de créer son proxy de transport , QueryInterface, pour IBTTransportProxy, puis d’appeler IBTTransportProxy. RegisterIsolatedReceiver pour s’inscrire auprès du moteur de messagerie.

Cette inscription implique que l'adaptateur envoie l'un de ses emplacements de réception configurés et activés au moteur de messagerie. Les informations d'identification du processus hôte de l'adaptateur doivent être membres du groupe Utilisateurs d'hôtes BizTalk isolés. La simple utilisation de l'emprunt d'identité est dans ce cas insuffisante, sauf si l'utilisateur est membre de ce groupe. En outre, l’adaptateur est interrogé pour s’assurer qu’il a le ClassID correct et s’exécute sur l’ordinateur qui a été configuré pour cette instance hôte. Une fois l’adaptateur inscrit avec succès auprès de son proxy de transport, sa configuration lui est envoyée en appelant la méthode Load de l’interface IPersistPropertyBag .

Le schéma ci-dessous illustre cette séquence d'appels d'API : l'adaptateur implémente les interfaces encadrées en bleu.

Image montrant le processus d’instanciation d’adaptateurs isolés.

L'extrait de code suivant illustre les appels d'API d'inscription :

using Microsoft.BizTalk.TransportProxy.Interop;  
using Microsoft.BizTalk.Component.Interop;  
using Microsoft.BizTalk.Message.Interop;  
  
public class MyAdapter : IBTTransport,   
 IBTTransportConfig,   
 IBTTransportControl,   
 IBaseComponent  
{  
...  
private IBTTransportProxy transportProxy;  
  
 public void Register(string uri)  
 {  
 // Create the Transport Proxy...  
 this.transportProxy =   
 (IBTTransportProxy)new BTTransportProxy();  
  
// Register on of the adapters uri’s with the TP  
 this.transportProxy.RegisterIsolatedReceiver(  
 uri,   
 (IBTTransportConfig)this );  
 }  
}  

Conseil d’implémentation : Nous recommandons à l’adaptateur de conserver le nombre de travaux en cours. L’adaptateur doit bloquer l’arrêt jusqu’à ce que le nombre de messages ait atteint zéro. Au niveau de la réception, cela inclut les demandes en suspens qui n'ont pas été publiées dans BizTalk Server. Les messages de réponse ne sont pas remis à un adaptateur de réception après l’appel de l’appel de l’arrêt .

Pour les adaptateurs d'envoi, les messages en cours de traitement doivent être traités de manière appropriée. Cela signifie que les messages correctement remis doivent être supprimés de la file d'attente de messages de l'application privée de l'adaptateur afin d'éviter qu'ils ne soient envoyés plusieurs fois.

Une fois l’arrêt terminé , le moteur de messagerie n’accepte pas les demandes de publication de nouveaux messages, à l’exception des messages de réponse pour les paires sollicitation-réponse.