Il existe plusieurs façons d’implémenter un flux, ½ flux FIFO : une pile SQL, un select top, un lock……. via un convoy …. .et la performance !!!
Comment choisir le bon pattern ?
A cette adresse : http://www.microsoft.com/downloads/details.aspx?FamilyID=F4FF7AFC-81A2-4B89-AE0D-3746B39D9198&displaylang=en
Un excellent document écrit à l’époque pour BizTalk 2004 traite les différents patterns au sujet du traitement séquentiel FIFO.
Très bonne lecture
Affichage des articles dont le libellé est BizTalk. Afficher tous les articles
Affichage des articles dont le libellé est BizTalk. Afficher tous les articles
vendredi 25 septembre 2009
jeudi 11 décembre 2008
Déclencher un traitement BizTalk sans créer une dépendance à un autre système.
Imagions qu’une orchestration BizTalk doit appeler un Web Service [fournisseur d’informations]
Deux scenarios se présentent :
1 – l’appel du Web Service n’est pas la première tâche du traitement:
Aucun problème, l’orchestration se déclenche peut être sur réception de fichier, souscription à la message box,…. puis appel du web service
2 – l’appel du Web Service est la première tâche du traitement :
L’appel du web service requiert un message d’invocation, ce message est donc à construire dans l’orchestration. Il faut prévoir un mécanisme de déclenchement de cette orchestration.
Il est possible de suivre la démarche suivante :
Déclenchement sur réception de fichier physique. Ce fichier est déposé dans une receive location en utilisant un job Sql, un ordonnanceur… à réception du fichier l’orchestration se déclenche, le message d’invocation est construit et le web service sera appelé.
Cette solution fonctionne correctement mais présente des inconvénients :
Le traitement BizTalk dépend entièrement du système de dépôt du fichier de déclenchement. L’arrêt du système de déclenchement impacte directement le traitement BizTalk.
Cette solution peut être refusée dans certains contextes (traitement temps réel, Haute disponibilité, plate forme EAI autonome ……)
Une solution plus adaptée peut être la suivante :
Utilisation du ScheduledTaskAdapter développé par la communauté. Il s’agit d’un adapteur de type receive dont l’objectif est de planifier la création des messages à publier dans la message Box.
Une orchestration BizTalk peut donc démarrer suite à la publication d’un message attendu par un receive port en écoute sur la message Box. La plateforme BizTalk n’est donc plus dépendante d’un autre système.
La planification est très flexible. Par défaut, l’adapter fournit 3 tâches :
Génération d’un message BizTalk à partir d’une chaine de caractère représentant un flux XML.
Génération d’un message BizTalk à partir du contenu d’un fichier
Génération d’un message BizTalk à partir du contenu chargé depuis un lien http
L’adapteur et son code sources sont disponibles sur : http://www.codeplex.com/BizTalkScheduledTask
Deux scenarios se présentent :
1 – l’appel du Web Service n’est pas la première tâche du traitement:
Aucun problème, l’orchestration se déclenche peut être sur réception de fichier, souscription à la message box,…. puis appel du web service
2 – l’appel du Web Service est la première tâche du traitement :
L’appel du web service requiert un message d’invocation, ce message est donc à construire dans l’orchestration. Il faut prévoir un mécanisme de déclenchement de cette orchestration.
Il est possible de suivre la démarche suivante :
Déclenchement sur réception de fichier physique. Ce fichier est déposé dans une receive location en utilisant un job Sql, un ordonnanceur… à réception du fichier l’orchestration se déclenche, le message d’invocation est construit et le web service sera appelé.
Cette solution fonctionne correctement mais présente des inconvénients :
Le traitement BizTalk dépend entièrement du système de dépôt du fichier de déclenchement. L’arrêt du système de déclenchement impacte directement le traitement BizTalk.
Cette solution peut être refusée dans certains contextes (traitement temps réel, Haute disponibilité, plate forme EAI autonome ……)
Une solution plus adaptée peut être la suivante :
Utilisation du ScheduledTaskAdapter développé par la communauté. Il s’agit d’un adapteur de type receive dont l’objectif est de planifier la création des messages à publier dans la message Box.
Une orchestration BizTalk peut donc démarrer suite à la publication d’un message attendu par un receive port en écoute sur la message Box. La plateforme BizTalk n’est donc plus dépendante d’un autre système.
La planification est très flexible. Par défaut, l’adapter fournit 3 tâches :
Génération d’un message BizTalk à partir d’une chaine de caractère représentant un flux XML.
Génération d’un message BizTalk à partir du contenu d’un fichier
Génération d’un message BizTalk à partir du contenu chargé depuis un lien http
L’adapteur et son code sources sont disponibles sur : http://www.codeplex.com/BizTalkScheduledTask
jeudi 3 juillet 2008
Vers une BizTalk software factory
Un outil BizTalk Server Pattern Wizard est disponible sur codeplexe . Cela permet de partager, rendre générique des implémentations BizTalk sous forme de Template. Les exemples disponibles aujourd'hui sont les implémentassions de quelques pattern bien connus dans le monde de l'intégration (Entreprise Integration pattern) et d'autres spécifiques à BizTalk:
Async Aggregation
Inverse Direct Bound Port
First In First Out
Splitter
Interrupter Pattern
Terminate
Retry Pattern
Non-uniform Sequential Convoy
Calling Pipelines
Parallel Convoy
Filter
Uniform Sequential Convoy
Message Broker
Suspend With Retry
Error Handling
Inscription à :
Articles (Atom)
