Convergence BPM-SOA 5 juillet 2017 JDEV 2017 - T6 Convergence BPM-SOA 5 juillet 2017

Contacts Christophe DENEUX Architecte d’entreprise / Urbaniste Tech-leader de Petals ESB  christophe.deneux@linagora.com  +33 6 48 86 53 09 http://www.flowable.org http://petals.ow2.org @ChrisDENEUX @linagora @petalsesb @flowablebpm /petalslink /linagora /flowable

Constat de départ Dans les SIs modernes urbanisés, on a : Des processus (du BPM) portés par un moteur Des services (de la SOA) portés par un ESB Mais : L’instanciation d’un processus se fait via l’API du moteur BPM Alors que cette instanciation a une vraie signification métier Et les complétions des tâches humaines, n’auraient-elles pas aussi une signification métier ? Pas très agile, pas très SOA Il faudrait alors un service métier instanciant le processus L’instanciation a une vraie signification métier : Créer une commande c’est lancer le processus de traitement d’une commande BPM et SOA sont-ils si éloignés ? Ou comme pour « onde/particule », n’aurait-on pas une dualité « BPM/SOA » ? Ne pourrait-on pas les faire converger ?

SI moderne Démarche d’urbanisation Macro architecture

SI moderne Développer au travers d’une démarche d’urbanisation : Définition des processus métiers de l’entreprise Définition de la cartographie fonctionnelle Identification : des services métiers des données métiers des responsabilités Cet îlot fonctionnel est responsable de cette donnée et de tels services. Projection sur les ressources applicatives

Convergence BPM/SOA ? Macro architecture BPM Portail BPM Infrastructure de services RA #2 RA #3 RA #n RA #1

Convergence BPM/SOA BPMN SOA → BPM BPM → SOA Services d’intégration Gestion d’identité

BPMN BPMN 2.0 Norme ISO, maintenu par l’OMG pour la définition et l’implémentation de processus Notation sous forme de symboles graphiques ... … facilement compréhensible par tous Sérialisation XML

SOA→ BPM C’est le sens facile : Un processus appelle des services Prévu dans BPMN ... … via une « service task »

Sinon, un service par start event APH : Accueil Personne Handicapée BPM→ SOA Exposer les éléments d’interaction BPMN sous forme de services : Instanciation d’un processus : Exposer le(s) « start event(s) » sous forme de service(s) Un service par « start event » Ou, un unique service pour tous les « start events » Le start event utilisé est fonction du payload d’invocation Service : « Demande APH » Opération : « Nouvelle demande » Le choix entre « un service par start event » ou « un service pour tous les start events » est fonction des start events : Si les starts events ont une même signification métier → un unique service pour tous les start events Sinon, un service par start event APH : Accueil Personne Handicapée

APH : Accueil Personne Handicapée BPM→ SOA Complétion des tâches humaines : Exposer les « user tasks » sous forme de services Un service par « user task » Service : « Demande APH » Opération : « Dossier complet » APH : Accueil Personne Handicapée

APH : Accueil Personne Handicapée BPM→ SOA Réception d’évènement : Exposer les « message intermediate catch event » sous forme de services Un service par « message intermediate catch event » APH : Accueil Personne Handicapée Service : « Demande APH » Opération : « Acquitement de stockage reçu »

Services d’intégration Comment inter-agir avec le moteur BPM ? Pour récupérer la bannette d’un utilisateur Pour administrer les processus ou instances de processus Suspension, Reprise, Rechercher suivant différents critères Des services dits d’« intégration » doivent exister

Gestion d’identité (LDAP) Un moteur BPM nécessite Utilisateurs et Groupes d’Utilisateurs Généralement portés par un annuaire LDAP Configuré au niveau du moteur BPM Dans un SI moderne agile Le composant de « gestion d’identité » doit pouvoir être changé sans impact Donc sans avoir besoin de reconfigurer le moteur BPM Le moteur BPM est consommateur de services « Identité », il impose leurs interfaces Ces services « Identité » sont implémentés en s’appuyant sur les services proposés par la brique « Gestion d’identité » Infrastructure de services BPM Services « Identité » Gestion d’identité (LDAP)

Implémentation dans Petals ESB SE Flowable

Petals ESB Infrastructure de services (ESB) 100 % libre (LGPL v3) Français Développé à Toulouse depuis 2004 Edité par Linagora http://petals.ow2.org/ Intégration / Orchestration Transformation BPMN 2.0 ASE Connecteurs

SE Flowable Composant de Petals ESB Moteur de services Basé sur Flowable (fork d’Activiti) Implémente la convergence BPM/SOA Propose nativement les services d’intégration Propose nativement des modules « Identité »: Simple fichier (à vocation de démonstration) LDAP (intégration LDAP de Flowable) Basé sur des services (à venir) Unité de service Artefact déployable Le processus Les services associés

Mapping BPMN ↔ Services Le SE Flowable utilise des annotations WSDL pour faire le lien Services définis dans le WSDL de l’unité de service Processus définis dans un fichier BPMN <wsdl:binding name="vacationBinding" type="vacationService:vacation"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="new"> <soap:operation soapAction="http://petals.ow2.org/samples/se-flowable/vacation/vacationService/newVacationRequest" /> <bpmn:operation processDefinitionId="vacationRequest" action="startEvent" none-start-event-id="start" /> <bpmn:userId>/*[local-name()='vacationRequest']/*[local-name()='enquirer']</bpmn:userId> <bpmn:variable name="numberOfDays">/*[local-name()='vacationRequest']/*[local-name()='day-number']</bpmn:variable> <bpmn:variable name="startDate">/*[local-name()='vacationRequest']/*[local-name()='start-date']</bpmn:variable> <bpmn:variable name="vacationMotivation">/*[local-name()='vacationRequest']/*[local-name()='reason']</bpmn:variable> <bpmn:output>newVacationRequestResponse.xsl</bpmn:output> <wsdl:input>...</wsdl:input> <wsdl:output>...</wsdl:output> </wsdl:operation> <wsdl:operation name="validate"> <soap:operation soapAction="http://petals.ow2.org/samples/se-flowable/vacation/vacationService/handleRequest" /> <bpmn:operation processDefinitionId="vacationRequest" action="userTask" user-task-id="handleVacationRequest" /> <bpmn:processInstanceId>/*[local-name()='validationRequest']/*[local-name()='vacationRequestId']</bpmn:processInstanceId> <bpmn:userId>/*[local-name()='validationRequest']/*[local-name()='approved-by']</bpmn:userId> <bpmn:variable name="vacationApproved">/*[local-name()='validationRequest']/*[local-name()='approval']</bpmn:variable> <bpmn:variable name="managerMotivation">/*[local-name()='validationRequest']/*[local-name()='rejection-reason']</bpmn:variable> <bpmn:variable name="isTransverse">/*[local-name()='validationRequest']/*[local-name()='is-transverse']</bpmn:variable> <bpmn:output>validationResponse.xsl</bpmn:output> <wsdl:fault name="vacationRequestIdUnknown">...</wsdl:fault> <wsdl:fault name="vacationRequestAlreadyValidated">...</wsdl:fault> <wsdl:fault name="unexpectedUser">...</wsdl:fault> </wsdl:binding> start-event user-task

Merci de votre attention LINAGORA – Siège social Tour Franklin, 100, terrasse Boieldieu 92800 PUTEAUX FRANCE Tél. : +33 (0)1 46 96 63 63 Fax : +33 (0)1 46 96 63 64 Info : info@linagora.com Web : www.linagora.com @linagora facebook.com/Linagora/ © LINAGORA