Détermination de l'ensemble des destinations de message au moment de l'exécution dans l'application BizTalk

Question

Je suis un débutant complet chez BizTalk et j'ai besoin de créer une application BizTalk 2006 qui diffuse des messages d'une manière spécifique. Je ne demande pas une solution complète, mais pour des conseils et des directives, les capacités de BizTalk que je devrais utiliser.

Il existe une source de message, pour simplifier, par exemple, un répertoire dans lequel l'utilisateur ajoute des fichiers pour les publier. Il y a plusieurs abonnés, chacun ayant un répertoire pour recevoir les fichiers publiés. Le nombre d'abonnés peut varier au cours de l'exploitation du programme. Il existe également certaines règles qui déterminent si un abonné particulier doit recevoir un fichier particulier, en fonction du nom de fichier. Par exemple, chaque abonné a un motif ou un masque de nom de fichier que les fichiers qu'ils reçoivent doivent correspondre. Ces règles (par exemple, les modèles) peuvent également changer dans le temps.

Je ne sais pas comment faire. Créer un ensemble de ports d'envoi à l'exécution, chacun pour chaque destination? C'est possible? Utilisez un port en changeant sa liaison? Cela fonctionnerait-il correctement avec les envois simultanés? Y a-t-il d'autres moyens?

EDIT

Je réalise ma question peut être d'obscurcir et générale de préférer une réponse sur une autre à accepter. Donc je les ai juste mis en favoris.

Answer 1

Si les changements de destination vont être fréquents, vous avez raison de chercher une solution plus dynamique. Une bonne solution utilise les ports d'envoi dynamiques et le moteur de règles métier. Vous créez un jeu de règles pour les messages que vous recevez. Cela peut être basé sur une propriété de destination ou un ID client dans le message. En utilisant ces faits, le moteur de règles peut renvoyer un tas d'informations comme le masque de fichier, le nom du serveur, l'adresse IP du serveur deleiver, etc. Vous pouvez ensuite utiliser ces informations pour configurer l'envoi dynamique dans l'orchestration. La bonne chose ici est que vous pouvez mettre à jour le jeu de règles dans le moteur de règles sans redéployer la solution entière. En tant que newb, ce sont quelques concepts avancés, mais pas aussi difficile que vous pouvez le penser. Pour une solution plus simple, vous pouvez envisager de définir les propriétés des adaptateurs Send FILE via son Propery Schema (par exemple, nom de fichier, répertoire, etc.). Vous pouvez extraire ces valeurs d'une base de données avec une classe d'aide à l'intérieur d'une forme d'expression. A chaque sortie de message, utilisez la propriété shcema pour définir où le message sera envoyé et nommé. De cette façon, vous venez de mettre à jour la base de données lorsque les choses changent.

Bonne chance!

Answer 2

Vous pourriez envisager d'utiliser des ports d'envoi dynamiques pour y parvenir - si vos abonnés sont vraiment dynamiques. Cela introduit un peu de complexité, car vous devrez utiliser une orchestration pour configurer les propriétés du port d'envoi en fonction de vos règles.

Si vous le pouvez, essayez d'éliminer la complexité. Si vous savez que vous n'avez pas besoin d'être vraiment dynamique lors de l'ajout d'abonnés (un abonné et ses règles peuvent être configurés une seule fois) et que vous avez un nombre d'abonnés gérable, je vous suggère de configurer chaque abonné en utilisant son propre port d'envoi et utilisez un filtre pour créer des abonnements en fonction des propriétés du contexte de message. La beauté de cette approche est que vous n'avez pas besoin de créer et de déployer une orchestration et que cela devient une solution hautement performante et évolutive.