Innovation

L'interopérabilité des processus

La vraie puissance du BPM consiste à combiner l’intégration des Web Services à la gestion de règles métiers. Ce sont en effet ces règles métiers qui prendront en charge l’orchestration des Web Services.

Les systèmes d’information doivent non seulement gérer des volumes de données structurées de plus en plus importants, mais aussi les informations représentées sous forme non structurées.

Cela entraine une hétérogénéité de plus en plus forte de ces systèmes d’information et n’oublions pas que c’est bien l’outil qui doit s’adapter à l’utilisateur et non l’inverse !

Un responsable informatique doit relever trois défis :

Dans ce contexte, le BPM permet la mise en place d’une architecture orientée processus afin de fédérer les données des systèmes hétérogènes aussi bien que les connaissances. Pour satisfaire l’interopérabilité et la réutilisation des applications générées, les outils de BPM s’appuient sur des standards.

D’autre part et afin de s’adapter aux besoins des utilisateurs, il est nécessaire de minimiser l’impact de l’architecture technique sur l’évolutivité des processus.

L’idée est donc de séparer la logique fonctionnelle des processus, sous la responsabilité d’un expert métier, et le domaine applicatif, sous la responsabilité de la direction des systèmes d’information. Les applications seront adaptables.

Quelques exemples :

Vers une architecture orientée processus

Pour permettre l’interopérabilité, les éditeurs de solutions informatiques ont mis en place des standards qui ont débouchés sur la notion de Web Services. Ces Web Services permettent d’appeler des objets métiers depuis des applications tierces.

L’intégration de ces Web Services sera sous la responsabilité du BPM (Business Process Mangement) par la modélisation rigoureuse des processus métiers.

Le BPM est donc la couche effectuant le lien entre la logique applicative et les services métiers, on parle d’orchestration de Web Services ou d’architecture orientée processus. Une telle organisation permet à l’expert métier de détenir l’entière responsabilité sur la définition de la logique applicative.

Les outils de BPM permettent d’intégrer des Web Services dans les applications à tous les niveaux du workflow, sur une transition, un test, une activité,… Pour cela, ces outils s’appuient sur des architectures orientée service (SOA) qui offrent la possibilité d’exposer sous forme de services Web des fonctions issues d’applications existantes.

Les propriétés de ces services Web seront définies dans un référentiel indépendant. Par exemple, si le service permettant de calculer le stock est modifié, le processus de réapprovisionnement, lui, ne l’est pas.

Mais, la vraie puissance du BPM consiste à combiner l’intégration des Web Services à la gestion de règles métiers. Ce sont en effet ces règles métiers qui prendront en charge l’orchestration des Web Services. Seule la combinaison du BPM et d’un outil de gestion des règles métiers fournira aux entreprises l’agilité attendue.

Intéropérabilité, systèmes hétérogènes, standards, BPEL,…

Nous venons de voir comment les règles métiers associées aux Web Services permettaient l’interopérabilité au sein de l’entreprise. Mais comment ouvrir ces processus métiers à l’écosystème de l’entreprise ? (fournisseurs, sous-traitants, clients…) Dans ce cas, certains services métiers proviennent de l’extérieur. Prenons par exemple une application de traitement des commandes. Certaines pièces étant sous traitées, cette application doit être capable d’interroger la gestion des stocks du fournisseur.

Comment les intégrer dans les processus internes ?

L’idée est de permettre aux règles métiers de s’exécuter à l’extérieur de l’entreprise, sur un moteur spécifique. C’est ici que l’utilisation de technologie standard prend toute son importance. Rappelons que les règles sont des processus qui coordonnent des actions entre des systèmes (et pas entre des personnes). On parle de workflow de type “Integration-Centric” vs. “Human-Centric” pour les workflows de type formulaires.

Pour ces processus, un langage standard d’exécution a été mis en place par l’ »Organization for the Advancement of Structured Information Standards » (OASIS), c’est le BPEL (Business Process Execution Language). Ce standard permet de rendre les processus à 100% portables ! Il s’agit en effet d’un langage déclaratif directement inteprétable, donc, plus de code généré propriétaire. Le BPEL se base sur l’appel de services Web externes SOAP et dans ce cadre, un processus peut s’exécuter sur n’importe quel moteur.

Grace à l’utilisation de ce standard, une règle pourra commencer à s’exécuter sur le moteur interne de l’entreprise, puis à une étape donnée, sortir et continuer à s’exécuter sur une plateforme externe compatible BPEL.

Intégrer l’application dans des plateformes hétérogènes

VDoc possède sa propre plateforme de CMS (Content Management System), VDoc Easy Site. Naturellement, une application VDoc 2.0 s’intégrera « nativement » dans cette plateforme. Le formulaire généré sera directement accessible dans Easy Site.

Mais l’accès à l’application via le formulaire pourrait se faire depuis un autre portail (SharePoint, SAP, Oracle,…).
Pour réaliser cet objectif, la représentation du formulaire sera basée sur des standards (XForms, REST).

Nous parlons bien ici de la partie « rendue graphique » de l’application. Le moteur sous jacent permettant de calculer les routages du formulaire sera dans tous les cas le moteur VDoc.