Création d'un adaptateur SOAP personnalisé pour BizTalk Toolkit 2.0 ESB

Question

Utilisation de la boîte à outils BizTalk ESB 2.0

Nous travaillons sur un projet où nous avons besoin d'appeler un proxy pour un service Web qui est une DLL. Nous n'avons rencontrez des difficultés par une orchestration puisque vous pouvez utiliser un port statique et le configurer pour utiliser l'adaptateur SOAP avec le paramètre de service Web montrant l'ensemble dans l'interface d'administration BizTalk. Dans l'itinéraire mais il ne semble pas être un moyen évident de le faire puisque les ports dynamiques n'ont pas la possibilité d'utiliser l'adaptateur SOAP.

Il y a une bonne raison pour laquelle nous voulons faire, ne vous inquiétez pas.

À la suite de cela, nous avons implémenté un fournisseur d'adaptateur personnalisé, mais des difficultés vis à travailler.

Nous avons suivi un (ancien) exemple montré ici :

Le fournisseur d'adaptateur personnalisé hérite de BaseAdapterProvider et remplace la méthode SetEndPoint (Dictionnaire, IBaseMessageContext).

La méthode extrait le nom de l'assemblage, le nom du type et le nom de méthode qui sont passés via le dictionnaire résolveur, puis les écrit dans le contexte du pipeline:

pipelineContext.Write("TypeName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName", 
   "http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);

et définit le type de transport à savon:

pipelineContext.Write("TransportType",
    "http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");

Dans tous les autres égards, le fournisseur de l'adaptateur est presque identique à l'exemple montré dans le lien ci-dessus, à l'exception du changement évident de SMTP à SOAP.

L'ensemble de fournisseur de l'adaptateur est signé, GACed et ajouté au esb.config.

Le fournisseur de l'adaptateur est appelé à partir d'un itinéraire qui appelle seulement le service, puis renvoie la réponse. Nous testons l'itinéraire du client test Itinéraire qui est livré avec la boîte à outils. l'enregistrement des événements dans l'adaptateur personnalisé indique que le code de l'adaptateur est appelé. Le problème est que le message ne soit pas acheminé vers le proxy de service. L'Observateur d'événements donne l'erreur suivante:

  

Le moteur de messagerie n'a pas réussi à traiter   un message envoyé par l'adaptateur: SOAP   La source   URL: /ESB.ItineraryServices.Response/ProcessItinerary.asmx.   Détails: Le message publié pourrait   pas mis en déroute parce qu'aucun abonné   ont été trouvés. Cette erreur se produit si le   abonnant orchestration ou port d'envoi   n'a pas été engagé, ou si certains d'entre   les propriétés de message nécessaires pour   l'évaluation de l'abonnement n'a pas été   promu. S'il vous plaît utiliser le Biztalk   Console d'administration pour résoudre   cet échec.

Enquête sur les instamces de service en suspension dans le groupe Vue d'ensemble montre deux choses: Les valeurs pour le nom de l'assemblage, le nom du type et le nom de procédé sont correctement définis. Le corps du message est manquant. Nous avons essayé de configurer l'envoi et de réception des pipelines sur le port d'envoi à la fois XMLTransmit / XMLReceive et ItinerarySendPassthrough / PassthroughReceive et il ne fait aucune différence.

Y at-il quelque chose évident que nous aurions pu manquer? Avez-vous de transmettre explicitement le corps du message à travers? Si oui, comment?

EDIT:

Suite à une demande du forum Toolkit ESB BizTalk Je posterai des captures d'écran de l'itinéraire, le contexte et envoyer les filtres de port.

Itinéraire , Contexte , Port filtre .

Merci, Nigel.

Answer 1

D'abord tout ce que je vais dire que vous essayez de concevoir plus la solution. le développement de l'adaptateur n'est pas anodin et il y a différentes choses que vous devez prendre pour considération. Développement et déploiement de adaptateurs sont classés comme des changements de plate-forme, qui effets tout votre environnement, donc si vous n'êtes pas familier alors votre ne devrait pas le faire. Je vous recommande de prendre une autre route. À ce stade Personnellement, je n'ai pas assez aperçu ESB internes, donc ne pouvoir commenter. Dans le pire des cas, vous pouvez être mieux d'utiliser le proxy .NET dll directement dans votre orchestration (expression ou la forme du message) plutôt que la construction d'un adaptateur. Même si son approche déconseillés, je me sens encore mieux que son approche adaptateur personnalisé.

Answer 2

sémantiquement, je ne vois pas pourquoi une solution qui implique un adaptateur WCF-BasicHtpp ne fonctionnerait pas dans votre scénario. Dans tous les cas, je certainement essayer de voir ce qui se passe avec un adaptateur WCF-BasicHttp, et une fois que je suis une solution de travail, je passer à un adaptateur SOAP personnalisé si cela est vraiment nécessaire.

À l'heure actuelle, votre solution est bizarre - dans le sens que vous avez un On-Ramp directement connecté à une bretelle de sortie. Je ne l'ai jamais vu que dans aucun de mes itinéraires. Vous devrez peut-être créer une messagerie intermédiaire ou orchestration service Itinéraire à betweeen.

Dans le cas contraire, le message est effectivement publié à la boîte de message et, évidemment, il n'y a pas d'abonnés pour, d'où l'erreur que vous rencontrez.