Introduction

Il y a quelques semaines en Novembre 2013, le BizTalk Integration Summit a révélé des indications sur la stratégie Microsoft vis à vis de BizTalk Server et en général de la plateforme middleware de l’éditeur. En dehors des annonces concernant la roadmap de BizTalk Server, plusieurs annonces ont été faites concernant le BPM (Business Process Management).

Il m’a semblé utile de revenir sur ces annonces et d’imaginer le futur de la plateforme applicative Microsoft vis à vis du BPM. Le but de cet article est donc de faire un état des lieux rapide du BPM sur la plateforme applicative Microsoft, de résumer les annonces du BizTalk Integration Summit, d’envisager le positionnement de BizTalk Server dans ce nouveau paysage et finalement d’envisager comment il faut procéder en attendant la concrétisation des annonces.

Le BPM et la plateforme Microsoft

Nous n’allons pas définir ce qu’est le BPM mais si nous pouvons le résumer en quelques mots nous pouvons dire qu’il s’agit de l’ensemble des outils et procédés qui permettent de modéliser, motoriser et superviser les processus métiers transverses de l’entreprise.

Implémenter du BPM dans le système d’information d’une entreprise suppose donc de savoir:

  • Modéliser les processus (qu’il s’agisse de processus humains ou de processus d’intégration avec des applications ou partenaires)
  • Héberger et exécuter ces processus
  • Superviser et suivre l’exécution de ces processus.

Les technologies et produits Microsoft permettent de réaliser ces différentes disciplines du BPM comme cela est décrit dans l’article MSDN ci-après : http://bpm-integration.archims.fr/

En revanche, il est vrai, comme vous pouvez le constater dans l’un des schémas de cette page MSDN, que le BPM dans la plateforme Microsoft, n’est possible qu’en intégrant plusieurs technologies/produits. Certes l’intégration de ces produits est facilitée du fait que ces produits sont édités par la même société, il n’empêche que cette apparente dispersion des fonctionnalités ne facilite pas la compréhension par les clients et peut être un frein à l’adoption de la plateforme applicative Microsoft.

Si l’on reprends les disciplines que nous avons cités préalablement, voici comment nous pouvons synthétiser le positionnement des produits Microsoft:

  • Modéliser les processus :
  • BizTalk Server (et Visual Studio + Excel) pour la modélisation des processus d’intégration et les KPIs associées (processus permettant la connectivité entre les applications du SI et avec les partenaires)
  • .Net Workflow Foundation (et Visual Studio ou SharePoint Designer) pour la modélisation des processus humains
  • Le moteur de règles de BizTalk (BRE) ou le moteur de règles de WF pour l’implémentation de la logique business
  • Motoriser les processus :
    • BizTalk Server et BizTalk Services pour les processus d’intégration
    • Un host Workflow Foundation pour les processus humains (soit AppFabric Server, soit WF Manager ou SharePoint)
    • AppFabric Server et IIS pour l’hébergement des services Web
  • Superviser les processus :
    • Le BAM de BizTalk Server pour les processus d’intégration
    • AppFabric Server pour le suivi de l’exécution des services Web et des worflows humains.

    Limitations et améliorations attendues

    Quand on dispose de l’expérience autour de cette plateforme applicative, ce qui est notre cas chez MiddleWay, le positionnement de chaque produit prend tout son sens et s’imbrique correctement.

    En revanche il est vrai que la plateforme pourrait bénéficier d’une approche plus intégrée, qui faciliterait sa compréhension et sa mise en oeuvre. Quelques explications:

    • Visual Studio est l’outil phare pour la modélisation des processus. Il permet de modéliser des workflows humains (avec le Workflow Designer) et des processus d’intégration (avec l’Orchestration Designer). En revanche, ces deux designers intégrés à Visual Studio ne partagent ni les mêmes surfaces de dessin ni la même toolbox. Il n’est donc pas possible de designer en une seule fois un processus global (humain et d’intégration) ;
    • L’hébergement et la motorisation des processus suppose là aussi de différencier les processus humains (qui seront hébergés dans AppFabric ou WF Manager) et les processus d’intégration (qui seront hébergés dans BizTalk Server et BizTalk Services).
    • La supervision, pour terminer, est elle aussi fragmentée puisqu’il faut utiliser les outils d’AppFabric pour suivre les processus humains et les services Web, et les outils de BizTalk Server/Services pour le suivi des processus d’intégration.

    D’un point de vue technique, il est donc nécessaire de comprendre cette fragmentation et de s’adapter en sélectionnant l’outil correspondant à chaque besoin. Chose qui n’est pas aisée pour toute entreprise qui débute avec la plateforme Microsoft et qui parfois s’avère difficile à vendre lorsque l’on est confrontés à la concurrence qui parait, en apparence en tout cas, plus intégrée et plus cohérente.

    Les annonces dans le domaine du BPM

    Lors du BizTalk Integration Summit de Novembre 2013, des annonces intéressantes et structurantes ont été faites par Microsoft vis à vis de BizTalk Server et de son positionnement BPM.

    Microsoft semble visiblement avoir pris en compte les retours des clients et partenaires et oriente donc son produit BizTalk Server pour répondre le mieux possible à ces attentes. Vous pouvez retrouver intégralement la session ici : http://channel9.msdn.com/Events/BizTalk-Integration-Summit/2013/BTIS02

    Modélisation des processus

    Microsoft annonce qu’un outil unique permettra de modéliser à la fois les processus humains et les processus d’intégration. Cet outil offrira aussi les fonctionnalités permettant de définir les indicateurs sur ces processus (KPI) et la mesure de qualités de services (SLA).

    L’outil sera probablement un designer intégré dans Visual Studio et se déclinera peut être sous forme d’un outil dédié aux utilisateurs moins techniques (comme l’est aujourd’hui le SharePoint Designer pour les workflows).

    Cet outil fusionnera donc le designer d’orchestrations, le designer de workflows ainsi que l’add-in Excel BAM de BizTalk.

    Il sera possible d’étendre la boîte à outils des activités utilisables dans les processus (comme il est possible de le faire aujourd’hui pour les WF mais qui n’a jamais été possible pour les orchestrations BizTalk).

    Pour les partenaires, des opportunités business sont annoncées puisqu’il sera possible de publier dans un store les activités ainsi développées mais également des modèles de processus métiers (par exemple, des modèles qui correspondent à des domaines métiers bien particuliers).

    Pour que la modélisation dans un seul designer des processus humains et des processus d’intégration soit possible, cela suppose que la technologie sous-jacente de ces processus sera elle aussi commune. En d’autres termes, les orchestrations BizTalk deviendront des workflows, comme cela est déjà le cas dans BizTalk Services (la version Cloud de BizTalk Server). Cette fusion des workflows et des orchestrations avait été annoncée il y a plusieurs années mais n’avait pas été mise en oeuvre. Nous pouvons donc nous attendre à cela dans les prochaines versions de BizTalk Server, ce qui est une excellente nouvelle tant les orchestrations et leur technologie XLang/S paraissent dépassées par rapport aux workflows.

    Microsoft annonce également que le moteur de règles, indispensable dans une plateforme BPM, sera le Business Rules Engine de BizTalk. Ce choix semble faire suite à un feedback très positif de la communauté autour de ce moteur de règles qui est en effet performant et très flexible. Le moteur sera porté dans le Cloud pour être utilisable au sein des processus hébergé dans Windows Azure. La modélisation des règles sera offerte via l’outil de modélisation des processus.

    Hébergement et motorisation des processus

    Concernant l’hébergement et la motorisation des processus, la simplification est au rendez-vous : comme nous venons de le mentionner, les orchestrations deviennent des workflows et leur hébergement est donc possible dans le même moteur que ces derniers.

    Au programme, une simplification dans le déploiement des processus, une supervision centralisée et une meilleure cohérence.

    Microsoft ne mentionne pas encore si le moteur qui hébergera ces processus est l’actuel moteur de BizTalk Server, le moteur d’AppFabric ou bien encore le moteur de WF Manager. Cela n’a finalement assez peu d’importance puisque ce qui compte ici est qu’un seul moteur permettra d’héberger tous les processus.

    Supervision des processus

    Microsoft annonce que le BAM de BizTalk sera le coeur de la solution de supervision des processus (pour les KPI et les SLA). Le BAM, pour rappel, permet de collecter les indicateurs des processus et les stocke pour les restituer aux utilisateurs.

    Microsoft annonce un nouveau portail BAM permettant la restitution des indicateurs aux utilisateurs et probablement la notification de ces utilisateurs en cas de problèmes de SLA sur les processus.

    Cloud first

    Fidèle à sa stratégie, Microsoft va tout d’abord implémenter ces fonctionnalités dans le Cloud Azure, au sein de BizTalk Services, pour qu’ensuite ces fonctionnalités soient portées en version à demeure dans BizTalk Server.

    Roadmap annoncée

    Microsoft n’annonce pas de dates pour toutes ces évolutions de la plateforme. En revanche Microsoft confirme que les roadmaps de BizTalk seront alignées sur :

    • Une mise à jour de la solution Cloud BizTalk chaque trimestre;
    • Une mise à jour majeure de BizTalk Server tous les 2 ans;
    • Une mise à jour mineure de BizTalk Server chaque année (essentiellement pour des alignements techniques avec la plateforme Windows, SQL Server et Visual Studio).

    On peut donc supposer que ces évolutions vont arriver progressivement dans BizTalk Services (Cloud) a partir des prochaines mises à jour et on peut espérer avoir une version de BizTalk Server alignée sur BizTalk Services en 2015. Ces dates n’engagent que moi vu qu’aucune date n’a été mentionnée.

    Que faut-il faire en attendant ?

    Quelle est donc la stratégie à adopter pour faire du BPM dans la plateforme applicative Microsoft ?

    Les évolutions annoncées par Microsoft sont cohérentes avec l’actuelle plateforme, elles consistent simplement à rendre plus lisible le positionnement des produits et la compréhension des usages de ces produits. C’est également l’occasion pour Microsoft de capitaliser sur des technologies qui sont très performantes et largement diffusées aujourd’hui. Il n’y aura pas de remise en cause des investissements réalisés lors de ces dernières années autour de BizTalk, AppFabric et .Net.

    La stratégie qu’il faut considérer aujourd’hui, en attendant les évolutions annoncées, est la suivante :

    • BizTalk Server et BizTalk Services : pour les besoins d’intégration (applications ou partenaires);
    • .Net Workflow Foundation : pour les processus humains;
    • WF Manager et AppFabric Server : pour l’hébergement des services Web et des workflows;
    • BizTalk BAM : pour la supervision des processus;
    • BizTalk BRE : pour les règles métiers.

    En suivant cette stratégie, que nous conseillons chez MiddleWay à nos client et prospects, vous investissez sur des technologies qui sont pérennes et qui permettent dès maintenant de mettre en œuvre une plateforme BPM performante et agile.

    Restez à l’écoute, nous vous informerons lorsque cette stratégie BPM s’affinera.

    Bien entendu, n’hésitez pas a commenter cet article pour donner votre avis, et suivez nous sur Twitter http://Twitter.com/@middlewaysas.

    Continue reading ‘La plateforme Microsoft et le BPM : des changements annoncés’

    Publicités

    Le Cumulative Update 6 de BizTalk 2010 est sorti depuis plusieurs semaines (http://support.microsoft.com/kb/2855367/en-us) et contient de nombreuses corrections de bugs (notamment un bug concernant la suppression inopinée de la déclaration XML lorsqu’un message est traité par un port avec un tracking profile BAM : http://support.microsoft.com/kb/2689953).

    Je vous conseille vivement d’attendre avant de déployer ce Cumulative Update car il introduit régression concernant le déploiement d’applications BizTalk, plus particulièrement lors de la mise à jour de ressources dans une application existante. Explications ci-dessous avec un exemple à la clé.

    Je dispose dans l’exemple ci-dessous de deux projets BizTalk et deux maps dans chaque projet :

    • Input_TO_Output dans le projet « TestCU6« 
    • Output_TO_Input dans le projet « TestCU6_Project2« .

    Projets

    Les deux projets sont compilés et déployés dans une application BizTalk nommée CU6 qui contient :

    • Un port de réception « rpCU6 » associé à la map Input_TO_Output

    rpCU6

    • Un port d’envoi « spCU6 » associé à la map Output_TO_Input

    spCU6

    L’application fonctionne mais là n’est pas le propos.

    Supposons maintenant que vous fassiez une modification dans la map Input_TO_Output, c’est à dire dans le projet TestCU6. Pour déployer cette modification, vous pouvez soit utiliser la commande « Deploy » de Visual Studio, soit depuis la console d’administration BizTalk en modifiant la ressource déployée (en l’occurrence l’assembly TestCU6.dll).

    Or si le CU6 est installé, vous ne pourrez tout simplement pas déployer la modification et obtiendrez l’erreur suivante:

    ErreurDeploiement

    La même opération fonctionne sans problèmes avant l’installation du CU5.

    L’erreur se produit car avant de mettre à jour l’assembly TestCU6.dll dans l’application, toutes les autres assemblies de l’application sont elles mêmes mises à jour (supprimées puis ajoutées de nouveau). Dans notre cas cela veut dire que même l’assembly TestCU6_Project2.dll (qui n’a pas été modifiée) est supprimée puis ajoutée de nouveau. Or la suppression est impossible car l’assembly contient une map qui est encore associée à un port (en l’occurrence un send port) — d’où l’erreur de FK présentée dans le message d’erreur.

    La mise à jour d’assembly dans une application BizTalk a toujours fonctionné de la sorte, mais en revanche, ce qui est nouveau avec le CU6, et qui cause cette erreur, est l’absence d’une étape lors de la suppression des ressources : la suppression de l’association maps / ports. Cette étape, qui derrière la scène est réalisée par une clause SQL DELETE, n’est plus déclenchées avec le CU6. Avec le CU5, on constate par exemple qu’une clause DELETE est envoyée à la base de configuration BizTalk (table bts_sendport_transform), juste avant la suppression de l’assembly, puis un INSERT est déclenché dans cette même table pour réassocier la map au port.

    Donc si vous êtes contraints d’installer le CU6, ou si vous l’avez déjà fait et ne pouvez pas revenir en arrière facilement, vous pouvez contourner ce bug en déssassociant vous même manuellement les maps des ports avant la mise à jour d’une assembly. Avec des bindings cela peut être plus simple mais cela reste tout de même fastidieux.

    Un ticket de support Microsoft est ouvert sur ce bug, je mettrais à jour ce post si un hotfix est mis à disposition par Microsoft.

     


    Après plusieurs mois d’absence sur ce blog, j’ai décidé de reprendre du service.

    J’ai le plaisir de vous annoncer la création de MiddleWay, cabinet d’architecture spécialisé dans l’interopérabilité et l’interconnexion des systèmes informatiques.
    MiddleWay est une structure de conseil qui accompagne ses clients dans le design et la mise en oeuvre de leur stratégie d’intégration : interopérabilité des systèmes, communication avec les partenaires de l’entreprise, sécurité des échanges, alignement du SI avec les nouveaux enjeux de l’entreprise.
    Je vous invite à nous contacter par email contact@middleway.fr pour en savoir plus. Vous pourrez très prochainement visiter notre site Internet en cours d’implémentation et qui sera disponible à l’adresse suivante : http://www.middleway.fr.

    La création de cette activité est une nouvelle aventure et s’inscrit parfaitement dans la continuité des années précédentes me concernant.
    Depuis plus de 15 ans, j’ai la chance de travailler dans le service informatique, tour à tour développeur, chef de projet ou architecte au sein de plusieurs intégrateurs et sociétés de services.
    C’est en 2006 que je décide de sauter le pas et de m’installer en tant que consultant indépendant spécialiste du produit Microsoft BizTalk Server. J’ai, dans le cadre de cette activité, eu la chance de travailler sur de nombreux projets EAI/SOA, dans différents secteurs d’activité (santé, industrie, énergie, sport, …) et d’affiner mon expertise. Fort de cette expertise technologique, j’ai publié en 2010 l’ouvrage « Microsoft BizTalk Server 2009 – Mise en oeuvre opérationnelle » aux éditions ENI. Ce livre, préfacé par Eric ORTIZ, à l’époque chef de produit BizTalk pour Microsoft France, est un ouvrage de référence sur le produit BizTalk, seul livre à ce jour en français. Bien que concernant une ancienne version de BizTalk, cet ouvrage est toujours d’actualité et est utilisé très régulièrement pour l’apprentissage du produit. Vous pouvez le trouver en vente ici.

    En 2011, je co-fonde la société ReachSOA, société de conseil spécialisée dans l’intégration de systèmes. Jusqu’en 2013, la société ReachSOA se développe grâce aux actions conjointes menées par l’équipe et permettent à la société de mener de nombreux projets d’envergure dans le sport notamment. Cette aventure est l’occasion d’étendre mes expertises techniques et organisationnelles des projets EAI/SOA.

    En 2013, l’aventure ReachSOA évolue. La société ReachSOA est scindée en deux. Cédric MARMEY et moi-même créons la société MiddleWay et faisons l’acquisition d’une partie de la clientèle de ReachSOA. Grâce à cette acquisition, MiddleWay assure ainsi la continuité des nombreuses missions d’accompagnement en architecture auprès de clients historiques et fidèles qui ont été développés depuis de nombreuses années.

    Nous sommes désormais pleinement opérationnels, fraichement installés dans nos bureaux lyonnais, et prêts à accompagner nos clients dans leurs projets SOA et EAI. Nous recherchons également très activement de nouveaux associés, spécialistes du middle-ware, et soucieux de collaborer au sein d’une équipe de spécialistes.

    Pour de plus amples renseignements, n’hésitez pas à nous contacter (contact@middleway.fr) ou à laisser un commentaire sur ce post.

     


    Je vous invite à consulter les deux posts rédigés par mon associé, Dave NOLTING, co-fondateur de ReachSOA (www.reachsoa.fr) concernant le MDM (Master Data Management). Ces deux posts illustrent:

      – Pour le premier, la mise en oeuvre du MDM avec SQL Server 2008 R2 MDS (Master Data Services). Vous découvrirez dans ce post comment modéliser les données du MDM et les exposer aux applications du SI (http://bit.ly/g5VZjX)

      – Le second post est quant à lui consacré à la mise en oeuvre d’un MDM haute performance grâce à la combinaison des technologies AppFabric, BizTalk et Dynamics AX (http://bit.ly/gBwB5k).

    Bonne lecture Smile


    Logo MS Techdays 2011

    Lors des MS TechDays 2011 (8,  9 et 10 février 2011), j’ai co-animé (avec Benjamin Guinebertière de MS et Daniel Pham de Rok Solutions) une session illustrant l’automatisation des processus de l’entreprise grâce aux technologies Microsoft (WF, WCF, AppFabric, BizTalk ainsi qu’avec l’outil ROK développé par ROK Solutions).

    Lors de cette session, nous avons illustré (entre autres sujets) l’utilisation du BAM de BizTalk Server pour suivre l’ensemble du processus de prise de commande utilisé comme scénario de démonstration.

    Pour ceux qui n’étaient pas présents aux TechDays et en attendant la sortie du webcast (fin mars certainement), voici quelques liens complémentaires permettant de visualiser le BAM en action. 3 vidéos :

    – Définition du BAM grâce à Excel : définition des indicateurs, des mesures et des dimensions d’analyse:

    http://cid-034bbd9ec4e51939.office.live.com/embedicon.aspx/Public/ARC305/TD11-ARC305-BAM1.wmv

    – Visualisation des indicateurs du BAM dans le Portail BAM de BizTalk et dans une page Web ASP.Net

    http://cid-034bbd9ec4e51939.office.live.com/embedicon.aspx/Public/ARC305/TD11-ARC305-BAM2.wmv

    – Visualisation du BAM grâce au controle PivotViewer de SilverLight, illustré par l’intégration dans l’outil ROK

    http://cid-034bbd9ec4e51939.office.live.com/embedicon.aspx/Public/ARC305/TD11-ARC305-BAM3.wmv

    Lors de la session nous avons cité différents outils facilitant l’utilisation du BAM. Voici des informations détaillées sur ces outils:

    – Génération d’une API typée : le BAM BizTalk est livré avec une API faiblement typée utilisable depuis n’importe quel client .Net et permettant d’enrichir le BAM. L’inconvénient majeur de cette API est justement son faible typage et ainsi son utilisation dans une application n’est pas toujours facilitée. Je vous conseille vivement d’utiliser le projet Codeplex http://generatetypedbamapi.codeplex.com/ afin de générer, à partir du fichier Excel de définition BAM, une API fortement typée,

    – Génération d’un service WCF : si vous souhaitez que des applications non .Net enrichissent le BAM (applications non .Net), vous pouvez également produire un service WCF à partir de la définition du BAM. Vous pouvez utiliser le projet Codeplex : http://bmsrvgen.codeplex.com/

    – Intercepteurs : pour rappel, l’enrichissement du BAM est également possible grâce à des intercepteurs (= sondes) pouvant être accostés à des workflows WF, des services WCF ou des flux BizTalk,

    – Concernant la consommation des données du BAM (pour leur restitution dans une application, un dashboard, …), il est bien évidemment toujours possible de requêter directement la base de données SQL Server de stockage du BAM (base de données BAMPrimaryImport). Toutefois, je conseille souvent de créer un projet de type WCF Data Services, exposant les données du BAM, et pouvant être consommé par toute application (notamment Silverlight).

    N’hésitez pas à laisser un commentaire pour toute question complémentaire ou demande de renseignement.


    L’ESB Toolkit de BizTalk (quelle que soit la version) contient un excellent pattern de gestion d’erreurs, reposant notamment sur une base de données pour le stockage des erreurs survenues dans l’environnement. Il s’agit de la base de données SQL Sever EsbExceptionDb (si vous avez gardé le nom par défaut).

    Cette base de données contient notamment:

          – Les erreurs survenues : détail de l’erreur, message(s) en erreur, …

          – Les actions réalisées sur ces erreurs : est-ce que l’erreur a été traitée par un opérateur, est-ce que le message a été relancé dans le système.

    Cette base de données devient donc tout aussi critique que les autres bases de données BizTalk et il convient d’adopter une stratégie de sauvegarde adaptée.

    Vous pouvez certes créer un plan de maintenance pour réaliser le backup ‘standard’ SQL Server mais je vous conseille d’opter pour le backup BizTalk : le job de backup BizTalk Server effectue les sauvegardes des bases de données BizTalk (en garantissant une cohérence dans les sauvegardes de toutes les bases de données) et vous pouvez le configurer pour qu’il intègre également des bases tierces. Voici comment procéder pour la based de données EsbExceptionDb.

    1) Créer la table MarkLog dans la base EsbExceptionDb

    Lorsque le job de Backup BizTalk s’exécute sur une base de données, et avant de réaliser le backup effectif, il met à jour le contenu de la table MarkLog. Cette table doit donc être présente dans la base EsbExceptionDb (comme dans toutes les autres bases de données intégrées au job de Backup).

    Pour créer cette table, exécutez simplement le script nommé Backup_Setup_All_Tables.sql situé dans le répertoire Schema du répertoire d’installation de BizTalk.

    2) Créer les procédures stockées dans la base EsbExceptionDb

    Le backup effectif de la base de données et la mise à jour de la table MarkLog sont effectués par un ensemble de procédures stockées devant être créées dans la base EsbExceptionDb.

    Pour cela, exécutez le script Backup_Setup_All_Procs.sql situé lui aussi dans le répertoire Schema du répertoire d’installation de BizTalk.

    3) Configurer le job de backup

    Afin que le job de backup BizTalk intègre la base EsbExceptionDb dans le processus de sauvegarde, vous devez simplement mettre à jour la table adm_OtherBackupDatabases de la base de données BizTalkMgmtDb :

    image

    Ajoutez une entrée dans cette table pour votre base de données comme illustré ci-dessous :

    image

    Vous devez bien entendu personnaliser l’occurrence ajoutée à la table pour qu’elle corresponde à votre environnement :

         – Le champ ServerName doit contenir le nom de l’instance SQL Server,

         – Le champ BTSServerName doit contenir le nom du serveur BizTalk.

    4) Tester le job

    Exécutez ce job pour tester la sauvegarde. Vous obtiendrez un fichier de sauvegarde pour la base EsbExceptionDb : en configuration traditionnelle, vous aurez un full backup une fois par jour et un backup des logs toutes les 15 minutes.

    Bonne pratique

    Bien entendu cette procédure s’applique à toutes les bases de données tierces (base de configuration, données de transcodification, autres bases de données de l’ESB Toolkit…).

    C’est une bonne pratique d’utiliser le job de backup BizTalk car il assure une cohérence dans les sauvegardes. Si vous utilisez le BizTalk Log Shipping pour un site de secours, toutes les bases de données sauvegardées par le job BizTalk seront automatiquement restaurées sur le site de secours sans effort. Smile


    MVP BizTalk 2010

    07Juil10

    C’est avec beaucoup de fierté que j’ai reçu, le 1er juillet,et pour la première fois, ma nomination en tant que MVP BizTalk. Je rejoins la communauté des MVPs BizTalk et compte bien profiter des avantages de cette nomination.

    Ce billet est l’occasion de remercier les membres de la communauté BizTalk française ainsi qu’Eric Ortiz (Microsoft France) qui a proposé ma nomination et qui, pour rappel, à écrit la préface de mon livre BizTalk Server 2009 (http://tinyurl.com/livreBizTalk2009).

    Smile