Gestion des processus d’entreprise (BPM1)

Problématique et mise en œuvre sur la plateforme Microsoft

Auteur : Benjamin Guinebertière, Architecte en système d’informationMicrosoft France

Contributeurs: François Baranger Conseiller en Stratégie de PlateformeEric Ortiz Chef de ProduitMicrosoft France

Version : 1.0Publication : Juin 2010

Copyright

© 2010 Microsoft Corporation. Tous droits réservés.

1 BPM = Business Process Management

Page 1

© 2010 Microsoft Corporation. Tous droits réservés.

Les informations contenues dans ce document représentent le point de vue actuel de Microsoft Corporation sur les sujets traités à la date de publication. Etant donné que Microsoft doit s’adapter aux conditions changeantes du marché, ces informations ne doivent pas être interprétées comme un engagement de la part de Microsoft, et Microsoft n’est pas en mesure de garantir l’exactitude de toute information présentée après la date de publication.

MICROSOFT NE DONNE AUCUNE GARANTIE EXPRESSE OU IMPLICITE DANS CE DOCUMENT.

Les autres noms de produits ou de sociétés cités dans ce document peuvent être des marques de leurs propriétaires respectifs.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • Etats-Unis

Page 2

IntroductionLes entreprises ont investi depuis des années dans un système d’information devenu mature mais dont les frontières tendent à se redessiner, projet par projet, en fonction des relations avec les partenaires commerciaux. Dans ce contexte, chaque entreprise cherche à s’appuyer à la fois sur son système d’information, celui de ses partenaires, ainsi que sur les logiciels en tant que services (SaaS2) pour tirer parti des investissements. Cela passe entre autres par l’automatisation de processus qui permet d’assembler rapidement des fonctions disponibles dans le système d’information, et de décharger les personnes des tâches de coordination les plus fastidieuses. Dans une étude datée de novembre 2009 le Gartner met en avant l’importance croissante de la gestion des processus de l’entreprise. En particulier, il est indiqué qu’en 2014, on apportera plus de valeur par la composition que par l’écriture de code3.

Ce livre blanc rappelle les enjeux de la gestion des processus dans l’entreprise, puis indique en quoi la plateforme Microsoft aide à mettre en œuvre les processus que l’on veut automatiser.

ProblématiqueL’entreprise est confrontée à une opposition permanente entre deux contraintes importantes. D’une part, elle doit faire face à des investissements importants pour la mise en œuvre de ses applications « cœur de métier », qui implémentent et automatisent leur savoir-faire fondamental. D’autre part, les exigences des clients et la concurrence poussent l’entreprise à proposer ses produits et services sous des formes renouvelées de plus en plus rapidement.

Les applications fondamentales du système d’information sont des piliers sur lesquels s’appuie l’entreprise. Comme pour des fondations d’un bâtiment, l’investissement est important et les remises en cause difficiles. En fait, ces piliers existent au niveau informatique mais également à des niveaux plus réels (humains, matériels, …) puisqu’ils définissent fondamentalement ce qu’est l’entreprise. Une banque ne deviendra pas une usine de production d’appareils électroménagers et les applications de ces deux entreprises restent différentes.

Ces applications fondamentales sont de plusieurs ordres. Il peut s’agir d’un progiciel du marché comme un outil de gestion de la relation client par exemple (CRM4). Lorsque plusieurs fonctions de l’entreprise sont mises en œuvre par un logiciel unique, on utilise un progiciel de gestion intégré ou PGI (ERP5) spécialement paramétré pour les besoins de l’entreprise. La mise en œuvre de ce type de logiciel correspond souvent à un projet de plusieurs années et peut remettre en cause la façon même de travailler au sein de l’entreprise. Une application fondamentale peut aussi être un développement spécifique qui s’appuie sur une plateforme de développement et d’exécution, ainsi qu’un gestionnaire de bases de données relationnelles dans une grande majorité des cas. Là encore, l’analyse, la conception et

2 SaaS= Software as a Service3 Selon une étude du Gartner de novembre 2009 (G00172856), « Through 2014, the act of composition will be a stronger opportunity to deliver value from software than the act of development”.4 CRM = Customer Relationship Management5 ERP = Enterprise Resource Planning

Page 3

la mise en œuvre d’un tel logiciel prend des mois pour chaque nouvelle version et cela peut prendre des années avant d’atteindre une version dont la maturité est satisfaisante.

Bien que ces applications fondamentales soient souvent de gros bateaux difficiles à manœuvrer, l’entreprise opère dans un marché concurrentiel, ou qui exige des améliorations permanentes, sinon les deux. Elle se doit donc d’adapter son offre et ses modes de fonctionnement aux besoins de ses clients, partenaires, et même de ses salariés. Elle a donc d’un côté des applications puissantes mais qui changent lentement, et de l’autre des demandes changeantes.

Lien DemandeApplications

Le lien entre les applications et la demande se fait par une couche d’intégration entre les applications, qui permet d’effectuer la navette entre les besoins changeants, et les savoir-faire fondamentaux.

Cette intégration peut être manuelle ou automatisée, ad-hoc ou formelle. Elle constitue un processus d’entreprise. Un processus manuel et ad-hoc se traduit typiquement par des utilisateurs qui collaborent entre eux par des moyens génériques tels que le téléphone, des papiers, de la messagerie électronique, chacun travaillant sur sa propre application.

Page 4

Application A

Application BApplication C

Processus ad- hoc

Cette solution peut se mettre en place rapidement. En revanche, elle ne permet pas d’avoir un résultat très prédictible ; il peut y avoir des comportements différents d’une fois sur l’autre, ne serait-ce que parce que le processus s’améliore au fur et à mesure. Elle ne monte pas non plus facilement en charge lorsque le nombre d’acteurs augmente. Que se passe-t-il si au lieu d’avoir un utilisateur d’une l’application A, on a tout une équipe et que certains sont en vacances, que certains viennent d’arriver dans l’équipe, que d’autres ont changé de rôle ?

Un processus formel, qu’il soit automatisé ou pas, décrit la façon dont l’intégration entre les applications doit être exécutée, par qui, dans quel ordre, etc… Une fois automatisé, ce processus formel présente l’avantage de faire en sorte que les utilisateurs se concentrent sur les tâches qui leur sont assignées sans avoir besoin de suivre l’évolution de l’exécution du processus lui-même. On inverse les liens par rapport au schéma précédent. Chaque utilisateur travaille dans son ou ses applications, reçoit des notifications pour les tâches qu’il a à accomplir (valider, choisir, déléguer, escalader, compléter, etc…). Il peut accomplir ces tâches directement depuis son client de messagerie (cliquer sur tel ou tel lien, répondre à un mail en respectant un formalisme particulier permettant le traitement automatisé comme mettre une seule pièce attachée qui est le document complété) ou depuis ses applications habituelles, ou encore depuis des applications spécifiquement développées pour le processus (formulaire, interface spécifique, etc...).

Page 5

Application A

Application B

Application C

Processus automatisé

Pour faire communiquer les personnes, les applications impliquées dans un processus, il est nécessaire de s’appuyer sur une couche d’intégration qui peut avoir lieu à différents niveaux. Le niveau le plus simple d’un point de vue informatique est le niveau humain qui nous ramène au processus manuel. Egalement appelé intégration de la chaise pivotante, ce niveau d’intégration est celui où l’utilisateur passe d’un écran à un autre, d’une application à une autre, en faisant pivoter la chaise sur laquelle il est assis : cela ne demande aucun développement informatique particulier mais peut être source d’erreurs et limite la productivité de l’utilisateur.

Un deuxième niveau d’intégration est celui de l’interface utilisateur. Le cas le plus simple est l’hyperlien web qui permet de naviguer d’une application à une autre, voire de passer des données (via les paramètres de l’URL par exemple). Il existe également des niveaux plus sophistiqués comme ce qui existe avec Microsoft CRM6 qui permet de présenter visuellement dans une même application des écrans qui s’exécutent en fait dans différentes applications existantes ; cela est typiquement utilisé pour automatiser des saisies multiples dans des applications différentes, toutes disponibles depuis le poste de travail d’un téléconseiller dans un centre d’appel.

6 Cf User Interface Integration SDK for Microsoft Dynamics CRM 4.0 à http://www.microsoft.com/downloads/details.aspx?FamilyID=ca2858ac-e280-4371-bbce-888346a2dc2d&displaylang=en

Page 6

L’intégration peut également se faire au niveau des applications elles-mêmes. Cela peut se faire au niveau applicatif (on réutilise la logique applicative) ou au niveau des données (connexion directe à la base de données de l’application, utilisation d’outils d’ETL7, …). Ces connexions peuvent se faire point à point ou via des intermédiaires que l’on peut appeler MOM8 (MSMQ9, WebSphere MQ10, …), serveur d’EAI11, infrastructure SOA12, bus de services d’entreprise ou ESB13. Il est à noter que l’échange de fichiers, mode d’intégration très répandu, peut être considéré comme de l’intégration au niveau applicatif ou au niveau données suivant que l’importation ou l’exportation des fichiers passe ou ne passe pas par la logique applicative. Le choix parmi ces possibilités se fait en prenant en compte des critères tels que la facilité de mise en œuvre (l’intégration au niveau des données et via des fichiers est bien placée de ce point de vue-là), la performance, la maintenabilité dans le temps (cela milite pour les couches d’intermédiation, et l’utilisation d’interfaces supportées par les éditeurs des applications à intégrer).

Du point de vue de l’automatisation des processus d’entreprise, la solution idéale est de disposer d’une couche d’intégration des applications intermédiaire, de type SOA. En effet, l’automatisation des processus consiste alors à envoyer des messages vers le bus de services d’entreprise qui les fera parvenir aux bonnes applications et renverra les réponses quand les tâches auront été effectuées. De plus, ce niveau d’intégration permet typiquement de s’adresser aussi facilement à des applications internes à l’entreprise qu’à des services de partenaires tels que les fournisseurs ou les clients. Parallèlement à cela, la messagerie électronique permet aux processus automatisés de joindre les personnes impliquées, ne

7 ETL = Extract Transform Load8 MOM = Message Oriented Midlleware9 MSMQ = Microsoft Message Queuing10 MQ = Message Queue11 EAI = Enterprise Application Integration12 SOA = Service Oriented Architecture13 ESB = Enterprise Service Bus

Page 7

serait-ce que pour les notifier de la présence de tâches au sein de leurs applications ou d’un autre entrepôt de tâches.

On notera que si une telle couche ESB n’existe pas, il est probable que l’automatisation des processus devra prendre en compte une partie de l’intégration. Par exemple, si les applications sont toutes accessibles via des web services (ce qui peut déjà être un scénario optimiste) mais qu’il n’y a pas d’ESB, c’est sans doute le moteur d’automatisation de processus qui jouera partiellement ce rôle et même un changement mineur d’une des applications aura des impacts sur le processus automatisé. De plus le processus automatisé ayant besoin d’entrer dans plus de niveaux de détails, il sera moins proche du processus tel que conçu fonctionnellement.

Un autre élément intervient dans l’automatisation des processus d’entreprise, pour apporter encore plus de souplesse ; il s’agit du moteur de règles métier (BRE14). Ce moteur, permet d’exprimer, la plupart du temps dans un langage intermédiaire entre le langage naturel et les langages formels de programmation, des règles qui permettent au processus de s’exécuter de façon différente en fonction du contexte. Les règles métier peuvent être typiquement utilisées pour décider de passer dans telle ou telle branche d’un processus.

14 BRE = Business Rules Engine

Page 8

Appel à un moteur de règles métier

Certains moteurs de règles métier permettent d’exprimer des règles qui ne sont pas faciles à exprimer dans un langage algorithmique classique. C’est typiquement le cas des moteurs d’inférence qui permettent d’enchaîner des règles simples pour exprimer une stratégie. Par exemple, sur un site de commerce électronique une stratégie peut s’exprimer avec des règles telles que :

1. SI le total du panier est > 100 € ALORS appliquer une réduction de 5%2. SI la machine à café ABC est ajoutée au panier ALORS ajouter les dosettes XYZ

On voit que si la règle 2 est déclenchée, la règle 1 doit être évaluée car elle peut s’appliquer. C’est le rôle du moteur d’inférence que de faire cela.

Au niveau du cycle de vie du système d’information, on a donc par ordre croissant de souplesse les éléments suivants :

Applications Couche d’intégration Processus métier Règles métier

Les utilisateurs voient les processus via les tâches qui leur sont assignées et via les résultats de ces processus. Au-delà de cela, certains acteurs doivent avoir une vision plus précise de la façon dont se

Page 9

déroulent les instances de processus en cours d’exécution, d’autant plus que ces processus peuvent durer plusieurs heures, voire plusieurs semaines.

Il y a bien sûr les équipes d’exploitation informatique des serveurs. Leur vision de l’exécution des processus est fournie par les serveurs et peut dépendre de chaque type de serveur. C’est typiquement ce que montreront les consoles d’administration.

Il y a également les administrateurs fonctionnels, responsables de la bonne exécution fonctionnelle des processus d’entreprise. Suivant les outils, ils peuvent avoir une vue typiquement graphique et unitaire de l’exécution d’une instance de processus qui correspond exactement à la façon dont le processus a été développé. Il peut cependant être nécessaire d’avoir des vues plus globales ou moins corrélées à l’implémentation des processus. Il s’agit alors du suivi de processus métier (BAM15). Comme la vue fonctionnelle peut ne pas correspondre exactement à l’implémentation technique du processus, il peut être nécessaire de définir une vue fonctionnelle du ou des processus techniques sous-jacents. Au niveau BAM, on peut vouloir par exemple inclure dans la vue fonctionnelle, des étapes qui sont en amont de l’exécution du processus, comme l’arrivée d’un événement déclencheur, ou l’envoi d’un résultat. On voudra également omettre des détails d’implémentation. Cette vision BAM permet de produire des indicateurs de performances (KPI16), des données fonctionnelles détaillées ou agrégées. Ces données ont donc naturellement leur place dans des bases de données multidimensionnelles. Au niveau de l’interface utilisateur, on retrouvera typiquement les outils classiques d’interrogation des données multidimensionnelles telles qu’Excel ou des rapports.

On voit donc qu’un autre avantage des processus formels et automatisés est qu’ils peuvent être mesurés, ce qui permet entre autres de les améliorer.

Lien avec d’autres disciplinesComme nous l’avons vu dans le chapitre précédent, la gestion de processus (BPM) est liée à d’autres disciplines.

L’architecture orientée service (SOA) est un soutien puissant, voire indispensable à la gestion de processus pour permettre de ne gérer que la logique métier au niveau BPM.

Cette intégration peut permettre bien sûr la réutilisation des services au sein de l’entreprise, mais également au-delà de l’entreprise. On parle de plus en plus d’entreprise virtuelle, composée de services offerts par des entités juridiques différentes, dans des lieux géographiques différents, mais participant toutes à un même service offert à des clients. Dans ce cadre-là, la relation d’entreprise à entreprise (B2B17) est une composante importante de soutien au BPM. Toujours dans ce cadre, les logiciels en tant que services (SaaS) font également partie des composantes sur lesquelles un processus d’entreprise étendue peut s’appuyer. Par exemple, un logiciel de gestion de la relation client (CRM) que l’entreprise consomme en mode SaaS peut intervenir dans des processus automatisés. Bien que le logiciel fasse

15 BAM = Business Activity Monitoring16 KPI = Key Performance Indicator17 B2B = Business to business

Page 10

logiquement partie du système d’information de l’entreprise, les techniques mises en œuvre pour se connecter à l’application peuvent être proches de celles utilisées dans le cadre du B2B.

Chaque processus métier, tel qu’il est défini au niveau conception, peut être instancié au niveau exécution par l’arrivée d’un événement déclencheur. Cet événement déclencheur peut être simple comme l’arrivée d’un e-mail, l’arrivée d’un message en provenance d’une application, mais il peut aussi être le résultat d’un ensemble de conditions. On arrive alors dans le domaine du traitement d’événements complexes (CEP18) qui permettra de corréler un ensemble d’événements simples en un événement de plus haut niveau, ayant une valeur métier. On rencontre typiquement cela dans des environnements industriels où la surveillance de paramètres d’un ensemble d’équipements peut déclencher une alerte qui devra ensuite être traitée en suivant un processus particulier.

Les processus d’entreprise utilisent des données qui sont souvent définies plusieurs fois dans l’entreprise alors qu’une définition unifiée pourrait exister. Par exemple, la notion de client peut exister dans le cadre de la relation commerciale, mais également dans le cadre de la logistique, et encore dans le cadre de la comptabilité ; avoir une définition unifiée de ces différentes notions peut faciliter la définition d’un processus de création d’un nouveau client par exemple. C’est là qu’intervient la discipline de gestion des données de référence (MDM19). Au-delà de la définition unifiée, le MDM permet également une gouvernance des flux de données au sein de l’entreprise. Le MDM est aux données ce que la SOA est aux services. Les processus manipulant des données traitées par des services, il est logique qu’ils sachent utiliser ces deux éléments.

Les données sont également intéressantes en aval des processus de façon à pouvoir analyser la façon dont les processus s’exécutent, la vitesse à laquelle ils le font, les points de contention, la réactivité des différents acteurs, qu’ils soient externes ou internes, l’utilisation réelle de tel ou tel type de processus de façon à vérifier que l’automatisation était rentable, etc. Tout cela peut se faire grâce à deux disciplines que sont le BAM (dont nous avons parlé plus haut) et la BI20 qui permet de présenter les données collectées de façon plus ou moins agrégées avec de bonnes performances de restitution.

Ce chapitre est également l’occasion d’aborder un autre point important quant à la gestion des processus d’entreprise, à savoir la gestion des transactions. Une transaction a pour but d’assurer qu’un ensemble d’opérations individuelles a lieu complètement ou pas du tout. Dans le domaine du BPM, il existe deux grandes façons de faire. D’une part, on peut assurer la transaction par des mécanismes de transactions distribuées de type ACID21 tels que le permettent les bases de données et d’autre part, on peut utiliser des mécanismes de compensation, qui consistent à défaire ce qui a été fait si tous les acteurs n’ont pu aller jusqu’au bout de la transaction. Les transactions de type ACID ont l’avantage d’être gérées de façon générique au niveau des plateformes d’exécution (gestionnaires de bases de données,

18 CEP = Complex Event Processing19 MDM = Master Data Management20 BI = Business Intelligence21 ACID = Atomique (Atomic), Cohérente (Consistent), Isolée (Isolated), Durable (Durable)

Page 11

implémentations SOAP22, …) ce qui fait qu’il suffit de déclarer qu’un ensemble d’opérations appartient à une même transaction pour que cela ait lieu. Cependant, l’inconvénient de cette approche est que pendant que la transaction a lieu, chacune des parties doit maintenir des verrous en attendant que le gestionnaire de la transaction distribuée déclare la transaction comme terminée (que ce soit validée (commit) ou invalidée (rollback)). Dans des scénarios de type BPM ou des systèmes (services) divers sont impliqués, utiliser des transactions distribuées va à l’encontre du principe d’autonomie des services, principe important en SOA. C’est pour cette raison que le BPM met plus classiquement en œuvre les principes de compensation où chaque étape correspond à un état stable de chaque service impliqué. Par exemple, on peut passer une écriture en comptabilité ; si la transaction n’a pu être complètement réalisée, le processus d’entreprise demandera à la comptabilité de passer une écriture inverse. Cela demande plus de travail au niveau de l’écriture du processus, mais permet une performance meilleure et plus prédictible au niveau de chaque service.

22 SOAP = Simple Object Access Protocol

Page 12

Technologies d’implémentationOn propose dans cette seconde partie du document de voir comment la plateforme Microsoft permet de mettre en œuvre les principes énoncés dans la première partie. Pour cela, on indiquera les technologies principales à disposition et comment elles peuvent fonctionner ensemble.

Ces technologies sont principalement, outre Visio, le serveur d’intégration BizTalk Server, le serveur d’application Windows Server AppFabric, mais également SharePoint Server pour la partie plus spécifiquement liée aux interactions humaines.

VisioUne très grande partie des processus d’entreprise sont modélisés dans PowerPoint ou Visio.

Visio Premium 2010 intègre des modèles de diagramme EPC23 et BPMN24:

EPC a historiquement été plutôt utilisé pour modéliser des processus SAP. BPMN est utilisé de façon plus généraliste. Ces notations permettent dans les phases d’analyse et de conception de modéliser les processus sous forme graphique.

NB : Pour des versions plus anciennes de Visio, il est possible d’utiliser des modèles de stencils qui sont disponibles sur le site de BPMN25. Ces stencils sont plus rudimentaire qu’en Visio 2010, mais cela permet tout de même une formalisation BPMN avec des versions antérieures.

D’une façon générale, la génération de code à partir d’un modèle est envisageable s’il s’agit d’un modèle de conception mais a priori à proscrire s’il s’agit d’un modèle d’analyse car les niveaux d’abstraction sont

23 EPC = Event Driven Process Chain24 BPMN = Business Process Modeling Notation25 Voir en bas de la page http://www.bpmn.org/documents

Page 13

trop différents. Il est effectivement illusoire de faire générer automatiquement une implémentation à partir d’une description de besoin.

Cependant, avec les outils de développement qui permettent des niveaux d’abstraction de plus en haut, il est également possible de faire la conception dans l’environnement de développement, le développement continuant ensuite dans le même environnement, pas nécessairement avec les mêmes personnes. Dans le cadre de Workflow Foundation, cela peut se faire grâce à des activités spécifiques de haut niveau et spécifiques à la problématique.

BizTalk ServerBizTalk Server, qui existe depuis 2000 et dont la version 2010 est en Bêta au moment où ces lignes sont écrites, est le serveur d’intégration de la plateforme Microsoft. La version 2004 a marqué un changement d’architecture important du produit. Dans le cadre du BPM, son rôle est principalement d’exposer aux processus les fonctionnalités des applications qui n’ont pas nécessairement été conçues pour cela.

Pour cela, BizTalk dispose d’un grand nombre d’adaptateurs en standard26, au-delà de ceux qu’il est possible de développer à partir du WCF LOB Adapter SDK27. Ces adaptateurs standard permettent d’adresser des applications, systèmes ou technologies d’éditeurs tels que SAP, Siebel eBusiness Applications, Oracle eBusiness Suite, des bases de données DB2, Oracle ou SQL Server, des fichiers accessibles directement depuis Windows ou hébergés sur des mainframes IBM, des middlewares orientés messages tels que MSMQ ou WebSphere MQ pour n’en citer que quelques-uns.

L’exposition de ces applications sous forme de services demande des modifications au niveau protocole de transport mais également éventuellement au niveau de la logique d’échange. Il peut même être nécessaire de combiner (d’orchestrer) plusieurs appels de façon à exposer un service plus simple à consommer du point de vue d’un processus qui ne connaît pas nécessairement le ou les systèmes exposés. BizTalk Server dispose donc d’une capacité de messagerie et d’une capacité d’orchestration (incluant des mécanismes de compensation).

BizTalk Server dispose également d’un moteur de règles, le BRE28. Ce moteur d’inférence peut être appelé depuis une orchestration ou depuis du code .NET. Cela permet typiquement d’externaliser des orchestrations des règles qui changent plus vite que les orchestrations.

L’exposition des systèmes sous forme de Web Services dans BizTalk peut être complétée avec « l’ESB Toolkit 2.0 »29. L’ESB Toolkit introduit la notion d’itinéraire qui est un ensemble d’étapes attachées à un

26 Voir http://www.microsoft.com/biztalk/en/us/adapters.aspx 27 WCF = Windows Communication Foundation, LOB = Line Of Business, SDK = Software Development Kit, voir http://msdn.microsoft.com/en-us/biztalk/bb905478.aspx 28 BRE = Business Rules Engine29 ESB = Enterprise Service Bus. Voir http://www.microsoft.com/biztalk/en/us/esb-guidance.aspx

Page 14

message. Ces étapes peuvent être des sollicitations de systèmes, directes ou via des orchestrations. Au fur et à mesure que les étapes sont franchies, le message voit son itinéraire diminué jusqu’à la dernière étape qui peut typiquement être l’envoi d’une réponse à l’appelant, le plus souvent de façon asynchrone. Cela permet d’utiliser BizTalk comme tout ou partie d’un bus de services d’entreprise sur lequel s’appuient les processus automatisés. Ainsi, la sollicitation d’un système quelconque par un processus se traduit par des échanges de messages avec l’ESB, et uniquement l’ESB ; on dispose ainsi d’un couplage lâche et d’une séparation des préoccupations (automatisation des processus d’une part, intégration d’autre part).

On peut représenter schématiquement l’échange de messages avec l’ESB de la façon suivante :

Une autre grande fonctionnalité couverte par BizTalk Server est le BAM. Le BAM de BizTalk permet de surveiller fonctionnellement un ou plusieurs traitements techniques : échanges WCF, exécution de processus Windows Workflow Foundation (voir plus bas), exécution d’orchestrations BizTalk, échanges de messages BizTalk, ou tout autre code écrit avec le .NET Framework.

Page 15

Au moment de l’exécution, le BAM de BizTalk se présente de la façon suivante :

De façon à définir cela, et comme le montre le schéma ci-dessous, un analyste métier décrit dans Excel ce qu’il veut voir du processus d’entreprise (l’activité BAM), sans se préoccuper de la façon dont cela est implémenté (1). Cette définition dans Excel permet de générer les schémas de données qui contiendront les indicateurs voulus ; on parle d’infrastructure dynamique ce qui correspond concrètement à des schémas de bases de données relationnelles et cubes (2). Un développeur pourra ensuite faire le lien entre l’activité et les processus techniques et autres éléments d’exécution (3). Ce lien se fait via un outil permettant de pointer sur les parties d’orchestration ou de messagerie, par de la configuration WCF ou WF, ou encore par des appels d’API assez simples.

Page 16

Au moment de la conception, cela se présente donc de la façon suivante :

Le module BAM de BizTalk Server fournit donc les outils pour facilement définir les structures de données à alimenter, et simplifie l’alimentation depuis les sources en gérant la récupération de ces données (par des sondes ou des API), et leur acheminement jusqu’aux entrepôts de données.

La restitution des données peut se faire depuis n’importe quelle gamme d’outils habituels pour lire des données dans des bases de données relationnelles ou des cubes (SQL Server Reporting Services, Excel, SharePoint, applications ASP.NET spécifiques, autres, …). Il est également proposé une application ASP.NET par défaut qu’est le portail BAM, qui permet de démarrer simplement.

Windows Azure AppFabric Service Bus and Access ControlDans le cadre de la communication B2B entre entreprises différentes, ou dans le cadre du lien entre le système d’information avec des applications en nuage, une possibilité est d’utiliser le bus de la plateforme Windows Azure qui permet une connexion sans changement d’infrastructure. Windows Azure Platform Service Bus & Access Control permet d’exposer un service hébergé dans les murs de l’entreprise avec une simple connexion sortante vers Internet, tout en ayant un contrôle d’accès sur le service exposé. Cela permet des scénarios de connectivité étendue au-delà des murs de l’entreprise

Page 17

comme on le montre dans le schéma suivant :

L’entreprise A connecte son ESB au bus Azure. L’entreprise B n’a pas d’infrastructure SOA, mais elle peut tout de même bénéficier de la connectivité à Azure Service Bus par des liens un à un. Enfin, les services exposés par les entreprises A et B peuvent être consommés non seulement par l’autre entreprise mais également par des applications hébergées dans le nuage public (pour peu qu’elles disposent des clefs qui lui donnent les bons accès).

Avec une telle topologie, le processus de l’entreprise A peut faire appel non seulement à des applications de son entreprise, mais également à des applications d’entreprises partenaires, ainsi qu’à des services hébergés sur Internet.

Windows Workflow FoundationWindows Workflow Foundation (qu’on abrège par WF) est apparu avec le .NET Framework 3.0. Il a évolué en .NET Framework 3.5 et a été plus profondément modifié en .NET Framework 4.0. Ce moteur est conçu pour gérer des workflows ou processus impliquant des interactions avec des systèmes et des personnes. Une des capacités qui rend WF adapté aux interactions humaines est la possibilité de modifier une instance de processus en cours d’exécution. En effet, contrairement aux applications, les personnes peuvent changer d’avis ou de comportement et il peut donc être nécessaire de modifier la façon dont une instance particulière de processus se déroule. WF est également conçu pour être hébergé dans des types d’applications variées telles qu’une application Web, SharePoint, un Web Service, une application console, un service Windows, une application Office (Excel, …).

Page 18

WF comprend un moteur d’exécution de workflows composés d’activités. Ces activités composent le processus. Le moteur d’exécution s’appuie sur des services (exemples : persistance, traces). Il existe des activités et services standard, mais il est également possible de créer les siens. Par exemple, on peut créer une bibliothèque d’activités spécifiquement adaptées au contexte dans lequel on voudra développer les workflows. Tout cela est schématisé dans cet extrait30 de la documentation en ligne :

Un outillage permettant de développer dans Visual Studio est également fourni. Il permet de voir les activités dans une barre d’outils à partir de laquelle les activités peuvent être glissées sur la surface de conception du workflow. Il est également possible d’héberger ce concepteur de workflow dans une application spécifique, en dehors de Visual Studio, permettant en particulier la visualisation des workflows en dehors de l’environnement de développement.

Les workflows peuvent communiquer avec l’extérieur via l’échange de messages (au sens SOA du terme). Il y a pour cela des activités standard de réception et/ou d’envoi.

30 Cf http://msdn.microsoft.com/fr-fr/library/dd489465.aspx

Page 19

C’est dans cette technologie riche que l’on implémentera typiquement sur la plateforme Microsoft des processus d’entreprise. Au niveau de la conception du workflow lui-même, au-delà des échanges de messages, il existe tout un tas d’activités standard que l’on passe rapidement ici en revue.

Pour contrôler l’ordre d’enchaînement des activités, on dispose des activités suivantes :

Pour échanger des messages avec l’extérieur, coordonner ces échanges et gérer les erreurs, on dispose des activités de messagerie, de transactions et de gestions d’erreurs

Pour contrôler la façon dont le workflow s’exécute, on dispose des activités suivantes :

Page 20

Enfin, il existe également d’autres activités qui permettent d’éviter d’écrire des lignes de code31 :

Outre ces activités de bases, des activités spécifiques peuvent être développées. Par exemple, l’assignation d’une tâche à une personne peut se faire via un protocole prédéfini au niveau de l’ESB. Ce protocole peut être implémenté dans une activité WF livrée dans une librairie (DLL32) faisant partie du Framework d’entreprise à partir duquel seront développés les workflows.

L’ESB, de son côté, reconnaîtra le message et pourra lui affecter un itinéraire qui commencera par exemple par déterminer comment la personne préfère recevoir cette tâche (messagerie instantanée ou e-mail, assignation de tâche au sein d’une application ou dans un portail, …), avant d’acheminer le contenu de la tâche à l’endroit ainsi déterminé.

Les mécanismes d’escalades lorsqu’un utilisateur ne répond pas dans un temps donné à une tâche qui lui est assignée peuvent eux-aussi être traités de façon spécifique au niveau de chaque processus d’entreprise, ou gérés de façon standard dans le Framework d’entreprise. Parmi les mécanismes d’escalade, on pourra noter l’assignation de la même tâche à tout un groupe de personnes en parallèle, l’assignation de la tâche à la même personne suivant d’autres canaux, l’assignation de la tâche à d’autres personnes (via des niveaux hiérarchiques ou autres) après un certain temps, etc.

En fonction de la stratégie décidée, ces mécanismes peuvent être implémentés au niveau de chaque workflow dans WF, ou au niveau d’activités WF présentes dans une librairie du Framework d’entreprise, ou encore au sein de l’ESB (s’il est nécessaire d’aller chercher dans des systèmes tels que l’annuaire ou l’application des ressources humaines, la personne à qui router le message contenant la tâche).

WF comprend également un moteur d’inférence (moteur de règles). Il peut aussi utiliser celui de BizTalk Server.

31 NB : l’activité Assign ci-dessus a pour but d’assigner une valeur à une variable et non d’assigner une tâche à une personne.32 DLL = Dynamic Link Library

Page 21

On notera que BizTalk Server 2010, actuellement en bêta, apporte des fonctionnalités complémentaires à Windows Workflow Foundation. En effet, il est maintenant possible de disposer du « mapper » (outil graphique de transformation de messages XML) au sein de WF, ou encore de consommer des adaptateurs WCF depuis WF. On notera que l’utilisation d’un adaptateur WCF directement depuis WF alors qu’on dispose de BizTalk n’est pas nécessairement la meilleure option en terme de séparation de couches, comme nous l’avons vu dans la première partie de ce document où BPM a été positionné au-dessus de la couche SOA.

Le moteur WF permet donc un développement assez outillé de workflows. Microsoft utilise bien sûr également la technologie pour ses propres produits comme SharePoint Server 2010 ou Team Foundation Server 2010.

AppFabricCependant, dans le cadre d’un développement de processus spécifique, WF lui-même ne fournit pas de processus d’hébergement standard. C’est le rôle de Windows Server AppFabric, le serveur d’applications, que d’héberger ces processus.

Page 22

Windows Server AppFabric comprend deux types de technologies complémentaires : l’hébergement de processus WF (« Hosting ») dont nous allons parler ici, et un cache distribué qui permet de stocker des données en mémoire vive sur plusieurs serveurs avec ou sans redondance.

Windows Server AppFabric Hosting tire parti des capacités de Windows Server 2008 ou Windows Server 2008 R2, et plus précisément de WAS33 et IIS34. WAS et IIS permettent d’héberger des services WCF qui communiquent sur les protocoles HTTP et HTTPS bien sûr mais également sur d’autres protocoles tels que des sockets TCP, des canaux nommés ou encore MSMQ. Indépendamment des protocoles utilisés, l’administration se fait depuis la console d’IIS. Windows Server AppFabric instrumente WAS et IIS au niveau de l’exécution, mais également la console d’administration IIS pour donner de la visibilité sur l’exécution des processus et appels de services WCF.

Au niveau de l’exécution, Windows Server AppFabric Hosting apporte des services WF de persistance et de suivi compatibles avec les fonctionnalités complémentaires offertes, telles que le fonctionnement en ferme NLB35, ou la visibilité donnée via le tableau de bord dans la console d’administration IIS.

Cela est résumé dans les schémas suivants :

33 WAS = Windows process Activation Services.34 IIS = Internet Information Services, serveur Web de Windows35 NLB = Network Load Balancing

Page 23

WF hébergé dans Windows Server AppFabric permet donc d’implémenter et d’exécuter les processus d’entreprise connectés aux personnes et systèmes de l’entreprise directement, ou de préférence via une infrastructure SOA typiquement implémentée par BizTalk Server.

Outils pour les tâches humainesPour les interactions entre les processus et les personnes, il existe de nombreuses possibilités et la plateforme Microsoft peut rendre cette interaction plus naturelle et productive.

Les axes d’optimisation (par rapport à de simples envois d’e-mails) de cette interaction sont en effet

Le mode de communication dépend de la disponibilité de l’utilisateur La tâche est envoyée sous forme d’événement ou est stockée dans un portefeuille de tâches que

l’utilisateur peut consulter L’utilisateur reste dans des environnements qui lui sont familiers, comme son outil de

messagerie, sa suite bureautique, son portail d’entreprise, ses applications

Page 24

Par exemple, une tâche destinée à un utilisateur peut être publiée dans une liste SharePoint. Les utilisateurs peuvent s’abonner ou pas à l’arrivée de nouveaux éléments dans cette liste de tâches.

Cela permet à la fois de disposer d’une liste à jour de tâches à effectuer et d’être prévenu quand une nouvelle tâche arrive. A l’inverse, un utilisateur qui reçoit des dizaines de tâches par jour ne demandera pas la notification par e-mail, car il ira systématiquement dans le portail pour traiter ses tâches.

La publication dans des listes peut également donner lieu au déclenchement de workflows SharePoint (qui s’appuie lui-même sur WF, d’ailleurs) pour gérer des escalades ou de la coordination entre utilisateurs. Par exemple, la tâche peut consister à remplir un document sur lequel un workflow de saisie, puis d’approbation de premier et second niveaux peut avoir lieu.

Pour ce qui est de la mise en œuvre, BizTalk Server dispose d’un adaptateur pour SharePoint qui rend ces échanges simples. Par exemple, on peut typiquement publier des tâches à destination des utilisateurs avec un statut positionné à « à faire », et récupérer dans BizTalk toutes les tâches dont le statut est passé à « fait ».

Les tâches peuvent classiquement être représentées techniquement sous forme de documents XML, qui ne peuvent pas être manipulés tels quels par les utilisateurs finaux. Dans la suite Office, InfoPath est typiquement là pour offrir un masque de saisie autour de documents XML. Du point de vue du développeur, on manipule un document XML dont l’en-tête indique qu’il s’agit d’un formulaire InfoPath, comme le montre l’exemple suivant :

Page 25

Du point de vue de l’utilisateur, il s’agit d’un formulaire avec un bouton de soumission qui peut envoyer le contenu par exemple via un POST HTTP ou un appel de Web Service SOAP.

InfoPath peut être combiné avec l’utilisation de listes SharePoint. D’un point de vue déploiement, on peut même se passer du client InfoPath avec Forms Server qui permet à SharePoint de publier les formulaires InfoPath sous forme de pages Web.

On peut aussi vouloir mettre les tâches à disposition de l’utilisateur de façon encore plus intégrée, en les rendant directement disponibles depuis Outlook, par exemple via une synchronisation entre une liste SharePoint et Outlook.

On voit donc que les interactions avec l’utilisateur pour lui permettre de réaliser les tâches que les processus lui affectent sont nombreuses, et vont au-delà du simple e-mail.

Complémentarités des technologiesComme nous l’avons vu plus haut, différentes technologies de la plateforme Microsoft jouent un rôle complémentaire pour l’automatisation de processus. Pour résumer, le tableau suivant met en regard les technologies et les rôles qu’elles peuvent jouer complémentairement entre elles et avec toutes autres technologies en place dans le système d’information de l’entreprise.

Produit Technologies Rôle dans le cadre du BPMOffice Visio Premium 2010 Elaboration de diagrammes EPC ou

BPMN dans le cadre de l’analyse et/ou de la conception des processus

.NET FrameworkWindows Server

Windows Workflow FoundationWindows Server AppFabric

Développement et exécution des processus d’entreprise

BizTalk Server BizTalk Server Intégration, d’infrastructure SOA, ou d’ESB

SharePointOffice

SharePoint, InfoPath, Outlook Interaction avec les utilisateurs participant aux processus

BizTalk Server BizTalk Server Business Activity Monitoring (BAM)

Supervision fonctionnelle de l’exécution des processus

Page 26

Le schéma suivant donne une vue synoptique du positionnement des différentes technologies dans le cadre du BPM :

Plusieurs processus d’entreprise développés avec WF sont hébergés dans Windows Server AppFabric (1). Ils sont vus et surveillés comme un seul processus global (par exemple le cycle de vie d’un prêt immobilier de l’avant-vente à la clôture), bien qu’implémenté par plusieurs processus, en utilisant le Business Activity Monitoring de BizTalk (2).

La connectivité est assurée par BizTalk Server et Windows Azure AppFabric Service Bus (3). Cela permet aux processus dans Windows Server AppFabric (1) d’adresser SharePoint (4) en tant qu’entrepôt de tâches (entre autres). SharePoint (4) peut lui-même héberger des workflows WF pour gérer des enchaînements de tâches locales. On peut aussi adresser des applications hébergées dans Windows Azure (5) ; il peut s’agir d’une application Web de prise de rendez-vous dans le cadre d’une avant-vente sur Internet, et qui déclenche un processus de vente (dans Windows Server AppFabric (1)). D’autres applications (6) (7) au sein de l’entreprise sont aussi en lien avec les processus d’entreprise hébergés dans Windows Server AppFabric. Ces applications (7), comme les applications au sein de Windows Azure (5) peuvent elles-mêmes utiliser WF pour exécuter des processus au service de workflow de pilotage de l’interface utilisateur (cas d’un contrôleur MVC36 implémenté en WF).

36 MVC = Model View Controller

Page 27

Tout cela permet de voir que Windows Server AppFabric hébergeant WF et BizTalk Server ont des rôles très complémentaires dans le cadre du BPM, les processus étant hébergés dans Windows Server AppFabric, BizTalk Server assurant la connectivité avec les applications, et le BAM (autre brique de BizTalk Server) assurant la supervision globale.

Enfin, sans entrer dans le détail ni être exhaustif, on évoque ici les technologies principales de la plateforme Microsoft au service de disciplines complémentaires du BPM, telles qu’évoquées plus haut : CEP, MDM, BI, …

Produit Technologies Rôle dans le cadre du BPMSQL ServerBizTalk Server

SQL Server 2008 R2 StreamInsightBizTalk RFID37

Gestion d’événements complexes (CEP) pour transformer des événements techniques corrélés en événements fonctionnels

SQL Server SQL Server 2008 R2 Master Data Services Master Data Management (MDM)BizTalk Server.NET Framework

BizTalk Server Business Rules Engine (BRE)Windows Workflow Foundation

Moteurs d’inférence

SQL ServerSharePointOffice

SQL Server Analysis ServicesSharePoint Performance Point ServicesSQL Server 2008 R2 PowerPivotSQL Server Reporting ServicesExcel

Business Intelligence

ConclusionL’automatisation de processus, s’appuyant sur une couche d’intégration ou d’infrastructure SOA, permet à une entreprise de bénéficier à la fois des ressources principales de son systèmes d’information que sont ses applications « cœur de métier » (ERP ou autres progiciels et applications spécifiques) dont l’acquisition, le développement, le paramétrage se font sur des périodes assez longues, et à la fois d’adresser des marchés qui évoluent sur des cycles beaucoup plus courts.

La plateforme Microsoft offre toute une gamme de produits pour mettre en œuvre cette stratégie de façon efficace, interopérable et agile.

37 RFID = Radio Frequence IDentifier

Page 28