2009-11-05 10 views
2

Je ne sais pas si je pose la bonne question, mais c'est le scénario que je suis en train de courir:BizTalk adaptateur personnalisé

plusieurs fichiers (XML et quelques fichiers associés, « pièces jointes ») doivent entrer dans BizTalk comme un seul message. J'ai regardé dans les adaptateurs existants, et ne vois pas cela fait avec existant une fois. Pour être plus précis, les fichiers sont pris à partir du système de fichiers. Les fichiers ne sont pas trouvés en même temps, mais arrivent un à la fois, lorsque la commande n'est pas assurée. Le fichier XML (contenu) est celui qui sait quelles pièces jointes il doit avoir (quels autres fichiers).

Nous sommes à la recherche de BizTalk 2009 et je me demandais serait de cette responsabilité d'un adaptateur personnalisé, ou autre chose. Et étais-je pu chercher des échantillons.

Merci.

Répondre

7

Il est probablement possible de faire ce que vous voulez en utilisant un adaptateur personnalisé, même si je le déconseille. Vous pouvez réaliser ce dont vous avez besoin en utilisant l'orchestration.

Ce que vous cherchez est un convoi, ou au moins une utilisation de la corrélation.

Dans BizTalk, un convoi est un modèle de messagerie (par opposition à une fonctionnalité BizTalk) qui permet à des groupes de messages d'être traités par une seule orchestration.

Vous utilisez essentiellement la corrélation sur un port de réception pour regrouper les messages en mode parallèle (ce que vous voulez probablement) ou séquentiel.

Il y a un article [ici] (http://msdn.microsoft.com/en-us/library/ms942189(BTS.10).aspx) par Stephen W. Thomas sur les convois (c'est pour BT 2004 mais les concepts sont toujours valables) et il y a beaucoup d'informations supplémentaires sur le web et dans les livres (Serveur BizTalk professionnel 2006 a une sous-section sur eux)

Sans plus de détails sur votre scénario, il est difficile de savoir exactement comment le convoi serait construit, mais ci-dessous sont deux approches à regarder (aussi, je n'ai pas eu l'occasion d'utiliser correctement BT2009 donc il peut y avoir un support étendu pour les scénarios de corrélation qui vous aident)

Corrélation flexible

Si vous ne savez rien sur les fichiers répertoriés dans le contexte XML, vous aurez probablement besoin d'un modèle comme celui décrit par Charles Young en this post.

convoi séquentiel non uniforme

Si vous avez un peu d'information avant de la main d'une façon peut-être comme suit (essentiellement un convoi séquentiel non uniforme):

Cela rend l'hypothèse qu'il existe un moyen de relier tous les fichiers ensemble afin de pouvoir les corréler.

Créez une orchestration unique abonnée au port de réception entrant (qui contient l'emplacement de réception du fichier).

Cette orchestration aura une seule forme de réception d'activation configurée pour votre fichier de contenu. Une fois que l'orchestration est démarrée par un fichier de contenu, une seconde forme de réception corrélée commence à ramasser les messages correspondant à ce fichier de contenu.(cette seconde réception pourrait être en boucle pour permettre des nombres de fichiers variables)

Vous les regrouperez ensuite dans un seul fichier sortant de votre conception et les enverrez une fois le nombre de fichiers reçu.

+0

David, Merci pour cette information. Convoi a l'air intéressant, mais je ne sais pas comment cela fonctionnerait dans ce cas. Vous voyez, les pièces jointes sont des fichiers binaires, et ne savent rien sur le fichier XML de contenu. Il n'y a rien à promouvoir de ces pièces jointes. Peut-être qu'il me manque quelque chose, n'hésitez pas à le signaler. 10x Sean –

+0

C'est clairement la bonne réponse. Même si vous ne savez rien sur le contenu du fichier XML, vous connaissez sûrement son nom et son emplacement. De cela, vous pouvez utiliser la corrélation flexible comme ceci: –

1

Il me semble qu'une meilleure approche consisterait à implémenter les exigences ci-dessus avec une combinaison d'un composant de pipeline personnalisé et/ou d'un adaptateur personnalisé. Je suppose que vous n'avez pas vraiment besoin de manipuler les fichiers entrants - à l'exception du fichier XML de contenu - ou que vous ne pouvez pas les manipuler puisqu'ils sont au format binaire. Cela nécessite un composant de pipeline personnalisé.

Ce que vous pouvez faire est de développer un adaptateur BizTalk personnalisé pour interagir avec le système de fichiers et implémenter la logique d'écoute et de bouclage. Ensuite, vous pouvez développer un composant de pipeline personnalisé pour créer un seul message BizTalk avec peut-être un type de données base64 pour les données binaires. En outre, vous pouvez également promouvoir des messages directement dans ce composant pour activer les abonnements d'orchestration.

Les orchestrations sont plus adaptées à la mise en œuvre de scénarios de workflow métier dans lesquels les messages sont déjà au format XML. Cela ne semble pas être le cas. Dans tous les cas, je pense qu'au moins un composant de pipeline personnalisé serait nécessaire.

+0

Merci. Cela ressemble à ce que nous devrons faire. Nous devrons opérer sur le message/les pièces jointes impliquant l'orchestration/les services externes. –

1

La réponse de David est la bonne réponse.

Même dans les cas où vous ne savez absolument rien sur le contenu des pièces jointes attendues, vous connaissez sûrement leurs noms et emplacements. Par conséquent, vous pouvez utiliser la Corrélation flexible liée à la réponse de David comme ceci:

La clé de la solution est de corréler avec la propriété BTS.ReceivedFileName intégrée.

D'abord, créez un pipeline de réception personnalisé, avec un composant de pipeline personnalisé qui promeut la propriété de contexte BTS.ReceivedFileName des messages reçus. Ce composant personnalisé simple est assez facile à écrire, mais vous pouvez le rendre simple en utilisant des frameworks tiers tels que, (plug sans vergogne, ici) ma classe PipelineComponentBase ou l'excellent BizTalk Server Pipeline Component Wizard.

Maintenant, pour la partie facile:

  • Les pièces jointes sont reçus dans un endroit précis, désigné par son chemin sur le système de fichiers.
  • Créez un emplacement de réception qui écoute un autre emplacement, utilisé uniquement pour contrôler quand les fichiers sont réellement avalés par BizTalk.
  • Dans votre orchestration, créez un type de corrélation avec la propriété BTS.ReceivedFileName et une base de jeu de corrélations sur ce type de corrélation.
  • Lorsque vous souhaitez recevoir des pièces jointes binaires, envoyez un message factice avec la propriété de contexte BTS.ReceivedFileName définie sur le nom de fichier de la pièce jointe binaire mais avec le chemin correspondant à l'autre emplacement ; celui utilisé par l'emplacement de réception. Initialisez la corrélation sur la forme d'envoi.
  • Utilisez une forme d'expression pour copier le fichier binaire de son emplacement d'origine vers celui utilisé par l'emplacement de réception.
  • Enfin, utilisez une forme de réception liée au port de réception qui contient l'emplacement de réception dont le pipeline de réception personnalisé va promouvoir la propriété BTS.ReceivedFileName.

Notez que vous avez réellement besoin d'envoyer un message afin d'initialiser la corrélation. Peu importe le message que vous envoyez réellement. Ce que je ferais est d'envoyer le message à travers un pipeline d'envoi qui contient un vide composant pipeline. C'est un composant de pipeline qui lit le message mais retourne null (de sorte que le message disparaisse dans l'air avant qu'il n'atteigne l'adaptateur). Une solution plus élaborée consisterait à utiliser un adaptateur null. C'est un adaptateur qui lit le message mais ne fait rien à ce sujet.

Ces deux solutions évitent que de nombreux fichiers ne s'accumulent dans un emplacement temporaire quelque part, juste pour l'initialisation d'une corrélation!

Questions connexes