Configuration du webservice dans Bonita

Suite à la validation des données dans le BPMS, il va être nécessaire d’appeler le service web e-dec. Dans Bonita, cette opération est possible par le biais d’un connecteur. C’est-à-dire une interface qui gère l’appel de service par le biais d’un paramétrage. Dans sa version payante Bonita Teamwork permet la configuration des web services par le biais d’une interface dédiée et prenant en charge les fichiers de type WDSL. Ce travail académique n’étant pas basé sur des solutions informatiques payantes, il aura été nécessaire de réaliser le paramétrage sur l’interface basique pour les web services. Celle-ci est visible à la Figure 32.

Partie pratique : Application du BPM Lifecycle dans une PME 65

FIGURE 32: INTERFACE CONNECTEUR SERVICE WEB DE BONITA

Cette tentative de configuration se sera avérée vaine pour qu’un appel du web service soit possible. En revanche, les champs demandés à compléter pour connecter le service sont ci-dessous documentés. Les champs suivants seront à renseigner depuis le fichier WSDL. :

1. Cible NS

La cible NS désigne le targetNamespace, soit l’endroit où est stocké le fichier WSDL. Cette information est elle-même stockée dans le fichier WSDL sous l’attribut targetNamespace visible à la Figure 33.

2. Nom de service

Le Nom de service désigne le nom associé au contrat de service. Il est disponible dans le fichier WSDL sous l’attribut name visible à la Figure 33.

Partie pratique : Application du BPM Lifecycle dans une PME 66

FIGURE 33: DEFINITIONS DU FICHIER E-DEC WSDL

Les deux premières informations demandées font partie de ce qui a été défini au point 3.3.5 comme étant l’interface abstraite du service.

3. Nom du port

Le Nom du port désigne une information qui lie un URL et un binding. Ce dernier étant une association entre plusieurs paramètres présents dans le fichier WSDL et qui ont étés décrits lors de la description de la Figure 31.

4. Requête

La requête est constituée de l’enveloppe SOAP qui est à transmettre au web service. Ici, les variables sont celles qui ont été confirmées par l’utilisateur grâce au formulaire. La forme de l’enveloppe SOAP est celle que l’on trouve dans SOAP UI sous la forme de l’enveloppe associée à Request1 qui est visible à la Figure 31.

5. Adresse endpoint

L’adresse endpoint est la destination à laquelle l’enveloppe SOAP va être utilisée pour le traitement. Ici, c’est l’adresse qui est fournie par SOAP UI et qui héberge le mock service.

C’est-à-dire que le contenu de l’enveloppe sera envoyé au mock service lancé par SOAP UI et qu’une réponse correspondant lui sera envoyée.

6. Binding

Le binding a été configuré ici selon les informations présentes dans le mode d’emploi pour les connecteurs disponible sur la page web. Il s’agit de la meilleure source à disposition pour l’utilisation de connecteurs trouvée.

7. SOAP Action

SOAP Action désigne quelle action décrite dans le fichier WSDL va-t-être utilisée pour traiter la requête.

Partie pratique : Application du BPM Lifecycle dans une PME 67 5.3.4 RÉPONSE DU WEB SERVICE

La réponse du web service va être assumée par le mock service mis en place dans SOAP UI. Ce programme va permettre pour la requête envoyée au endpoint de définir une requête définissable à l’avance. Celle-ci sera basée sur le fichier WSDL et utilisera l’enveloppe SOAP utilisée par le web service e-dec. Il est toutefois nécessaire de configurer ce fichier.

Dans ce travail, le fichier a été configuré de façon à donner une réponse qui soit identique à celle obtenue sur l’interface test de e-dec web. C’est-à-dire un fichier XML contenant la déclaration et un PDF. Ces informations sont disponibles dans leur format original à l’annexe 8.2. La Figure 34 illustre leur contenu.

FIGURE 34: DÉCLARATION EN FORMAT XML

5.3.5 INTÉGRATION DES RÉSULTATS DANS LE BPMS

Il est possible d’intégrer les résultats issus de la déclaration au niveau du connecteur. Pour cela, il est nécessaire d’attribuer aux valeurs de retour du web service une variable présente dans le processus, comme cela est illustré à la Figure 35. On notera encore ici que le BPMS dans sa version testée n’a pas reconnu le fichier GoodsDeclaration.xsd comme valide. La configuration ici est donc donnée par défaut avec comme valeur par défaut à cette opération le fichier xml généré par l’interface test de e-dec web.

Partie pratique : Application du BPM Lifecycle dans une PME 68

FIGURE 35: CONFIGURATION DU RETOUR DES DONNÉES DANS BONITA

Suite à l’intégration de ces données par le biais du connecteur, il faut encore rendre celles-ci consultables dans le processus. Pour cela, un formulaire de consultation a été généré dans la tâche de Réception de la DDE présente à la Figure 28 qui permette à l’utilisateur d’avoir accès à ces variables une fois qu’elles ont été saisies correctement.

Partie pratique : Application du BPM Lifecycle dans une PME 69

5.4 BPM Phase 4 : Process Runtime

Etant donné que le processus est non fonctionnel, il est difficile lors de cette première phase du BPM Lifecycle de s’intéresser à son déploiement et à son monitoring. Il n’y a en effet pas de charge de travail, ni de possibilité de le simuler dans son entier. Toutefois, il est possible de consulter les éléments que le système BPMS a générés avec les données de configuration qui lui ont été transmises.

5.4.1 UTILISATION DE LA USER XP

La User XP dans Bonita représente l’interface par laquelle les utilisateurs voient les processus et les exécutent. Il s’agit en fait d’un Inbox dans lequel les utilisateurs reçoivent des tâches qui sont de leur responsabilité lorsqu’elles s’exécutent. Cette User XP est accessible aux utilisateurs depuis une interface web que l’on peut voir à la Figure 36

FIGURE 36: USER EXPERIENCE BONITA

Cette interface permet à l’utilisateur de gérer les tâches qu’il doit accomplir sous la forme d’une boîte de réception. Lorsqu’il est considéré comme responsable d’un processus, il peut aussi « Démarrer un cas » du processus. Ci-dessus, c’est le cas avec le processus Export avec e-dec visible dans le menu horizontal.

5.4.2 CONTRÔLE ET SAISIE DES DONNÉES PAR L’UTILISATEUR

Lors du lancement du processus depuis la User XP, l’utilisateur doit remplir un formulaire qui contient les données du cas d’exportation qui ont été sorties de l’ERP. Il peut modifier celles-ci si elles s’avèrent fausses ou les saisir si elles sont incomplètes. Le formulaire réalisé à cette occasion dans la tâche de saisie des données contient plusieurs pages. Chacune d’entre elle représentant une rubrique de la déclaration d’export. On peut voir un aperçu du formulaire à la Figure 37.

Partie pratique : Application du BPM Lifecycle dans une PME 70

FIGURE 37: FORMULAIRE DE SAISIE ET DE CONTRÔLE DES DONNÉES

Partie pratique : Application du BPM Lifecycle dans une PME 71

5.5 Phase 5 : Process Improvement

Comme on a pu le voir lors de cette tentative d’implémenter un processus, le recours au BPM Lifecycle n’est en rien garant qu’un processus soit facile à implémenter et que toutes les options choisies durant cette tentative soient les bonnes. En revanche, de BPM Lifecycle, de par sa nature itérative, permet d’intégrer l’expérience de chaque itération pour améliorer le processus par la suite. Dans ce travail, son recours permettra d’évaluer les enjeux d’une telle implémentation et de définir ce qui peut être amélioré et comment. A cette fin, les principaux éléments qui se sont avérés critiques sont ici mentionnés et pourront servir à une prochaine itération du processus.

5.5.1 ENVOI DES DONNÉES PAR L’ERP

Afin de rendre le processus pleinement fonctionnel et optimal en termes de fonctionnement, il est essentiel que la transition entre l’ERP et le BPMS se fasse de manière automatique.

Pour cela, il faudra configurer l’ERP et le BPMS pour que la décision d’envoyer des montres, lorsqu’elle concerne des montres à exporter aboutisse à l’envoi des données pour les lignes de commandes désignées.

Les données concernant cet export sont en grande majorité présentes dans l’ERP, comme la Figure 29 en atteste avec notamment la présence des HS Code sur la facture. Il faut ici remarquer que l’intégration des informations douanières sur la facture ne servent pas qu’au processus d’export, mais rendent aussi possible l’importation dans les marchés cible. Cela implique que ces informations devront figurer dans l’ERP afin de soutenir la totalité du processus d’export. Il conviendra donc dans un premier temps de renseigner les objets

« articles » et « client » de l’ERP de manière optimale. Le BPMS pourrait ensuite jouer un rôle important dans le contrôle de la validité de ces informations avant leur envoi à la douane. C’est notamment ce qui sera expliqué au point 5.5.2.

5.5.2 UTILISATION DE FICHIERS XML DANS LE BPMS

Dans sa version actuelle, le prototype se base sur des variables indépendantes les unes des autres à titre d’input de données du processus d’import. Si ce format brut et non structuré pourrait être ce qu’un ERP serait à même de fournir comme données d’input à un cas d’export, il est à noter que la communication entre le web service et le BPMS s’effectue à l’aide de fichiers XML qui sont définis à l’aide de XML Schemas. Cette forme devrait être utilisée afin de réaliser les interfaces de contrôle avant l’envoi des données. Les XML Schemas stipulant la forme des variables, leur optionalité et d’éventuels liens avec d’autres variables. Pour cela, le BPMS devra être à même de reconnaître le XML Schema Goods Declaration, ce qui n’est pas le cas actuellement.

Partie pratique : Application du BPM Lifecycle dans une PME 72 Dans sa forme actuelle, le connecteur du BPMS qui accède à e-dec nécessite qu’il faille placer chaque variable dans l’enveloppe SOAP. Or il existe une extension payante qui va rendre possible la gestion des fichiers XML et qui permette une configuration nettement plus simple des variables, comme il est possible de le voir à la Figure 38.

FIGURE 38: INTERFACE DE CONNEXION WEB SERVICE PAYANTE DE BONITA (BONITASOFT, 2011)

De plus, ce module permet aussi de gérer le retour d’information sous la forme de fichier XML, ce qui aurait permis un meilleur retour des informations.

5.5.3 GESTION DES RÉPONSES DE DÉCLARATION PAR LE BPMS

Un des intérêts d’un service comme e-dec est, comme cela a été illustré à la Figure 28, sa capacité à pouvoir automatiquement déceler des erreurs dans la déclaration de douane et à communiquer avec le déclarant. Or, le système du déclarant doit être à même de gérer cela par le biais d’interfaces qui prennent en charge les différentes réponses, c’est-à-dire soit un fichier à corriger, soit la consultation de la déclaration acceptée. Ces interfaces doivent elles aussi se baser sur des XML Schema pour être générées. Elles pourront se baser sur l’interface de contrôle des données à la sortie de l’ERP au niveau de leur layout et de leur

Partie pratique : Application du BPM Lifecycle dans une PME 73 implémentation tout en intégrant les spécificités dues à la communication avec le web service e-dec.

5.5.4 DÉFINITION DES RÔLES AUTOUR DU PROCESSUS DANS LA PERSPECTIVE D’UNE IMPLÉMENTATION

Lors de cette première itération, il n’a pas été considéré que plusieurs personnes allaient participer à l’exécution du processus. Or si on veut que celui-ci se passe selon un optimum, il va falloir définir des responsabilités plus claires que ce n’est le cas actuellement. Par exemple, les données transmises à e-dec depuis l’ERP devront toujours être à jour. Cette responsabilité devra-t-être clairement assignée à quelqu’un dans l’entreprise afin d’éviter que des informations incomplètes sortent de l’ERP. De plus, le recours au BPMS va demander aux personnes de l’organisation de s’habituer à de nouvelles interfaces et à une nouvelle manière de travailler. Il faudra à la fois offrir la formation nécessaire aux utilisateurs et gérer le changement et toutes les réticences qu’il peut occasionner. De plus, cette implémentation devra se faire avec la conviction et le soutien inconditionnel de la hiérarchie.

5.5.5 GESTION DES RESSOURCES

Tout projet informatique est soumis à un impératif budgétaire. Afin de rendre possible l’intégration de e-dec dans le SI de l’entreprise, il va être nécessaire de procéder à des investissements qui n’ont pas eu lieu dans cette première itération du BPM Lifecycle. Il faudra en effet soit investir dans la solution Bonita pour la rendre utilisable selon les exigences fournies par le web service e-dec en investissant dans des modules et du conseil, soit utiliser une solution propriétaire qui soit à même de garantir que l’implémentation fonctionne sans bug technique. Ce n’est donc qu’en fonction d’un budget donné qu’une prochaine itération pourrait avoir lieu. Ce budget permettrait alors d’évaluer si les solutions libres retenues pour ce travail sont à même de concurrencer les solutions propriétaires en termes de rapport qualité/prix.

Conclusion 74

6 C ONCLUSION

Comme cela a été démontré dans ce travail par le biais des questions de recherche qui ont été traitées tout le long du travail, les approches SOA et BPM permettent aux dirigeants de gérer des problématiques qui sont centrales dans toute organisation : la pérennité du système d’information et le lien entre processus et création de valeur. Maîtriser les outils conceptuels de SOA et BPM contribue indéniablement à une prise de décision stratégique qui offre des avantages concurrentiels. L’approche SOA va en effet permettre au système d’information de pouvoir développer des nouvelles fonctionnalités qui puissent être les plus proches possibles des besoins de l’organisation. Quant à la gestion des processus offerte par BPM, elle va être à même de toujours relier les activités réalisées dans l’entreprise au but final de création de valeur et de mettre sur pied une philosophie d’amélioration continue.

En ayant pour objectif l’implémentation d’un processus d’export utilisant un web service issu d’une SOA, ce travail a pu évaluer en pratique la collaboration des deux paradigmes. Il a ainsi été possible d’étudier et d’interagir avec les interfaces du web service e-dec, lui-même basé sur une SOA. Cette interaction s’est faite dans le cadre d’une méthodologie dédiée aux processus : le BPM Lifecycle.

Cette démarche a nécessité une intégration des services passant par des outils BMPS et avec l’utilisation du langage de modélisation et d’exécution BPMN 2.0. Ces outils se sont avérés d’une très grande efficacité lorsqu’il a fallu identifier les fonctions cibles des acteurs faisant l’objet de l’intégration, modéliser les processus, les documenter. Au travers du modèle BPMM, le degré de maîtrise des processus a pu être situé et des objectifs ont pu être placés. Il a aussi été possible, en vertu de la qualité du BPMN 2.0 de garder le même modèle entre la phase de modélisation et d’exécution.

Les principaux problèmes qui sont apparus lors de ce travail sont liés au recours à un BPMS.

Les solutions en libre accès dans le domaine des BPMS se sont avérées inadéquates pour implémenter un web service utilisant SOAP et WSDL. Ces lacunes auraient dû être relevées plus tôt dans ce travail, notamment en évaluant la prise en charge des web services à la partie 4.5.2. Les tentatives sur différents outils réalisées dans ce travail se sont soldées par la mise sur pied d’un prototype non fonctionnel. Cela démontre que la gestion des processus et leur intégration nécessite à la fois un investissement en ressources et une réflexion organisationnelle et infrastructurelle. Un excellent degré de réflexion sur les processus ne suffira pas à implémenter ceux-ci. Il faut disposer d’outils qui soient fonctionnels et qui permettent d’interagir avec les web services sur des interfaces standardisées qui supportent les standards WS*. Ces propriétés sont essentielles pour tirer profit des web services et afin de rendre possible l’agilité promise par la rencontre entre SOA et BPM.

Conclusion 75 Pour s’assurer que la PME puisse disposer d’une solution d’export qui soit viable à l’avenir et ceci grâce aux prochaines itérations du BPM Lifecycle, il faudra prendre une décision au niveau de l’orchestration des processus. Soit celle-ci devra être laissée à l’ERP actuel et les processus soutenus seront ceux qui feront l’objet de développement par l’éditeur et la communauté open source qui le soutient, ou alors la PME pourra faire le choix d’investir dans une solution BPM qui soit conforme aux spécificités techniques du service e-dec. Dans les deux cas de figure, ce travail pourra servir de base pour réaliser soit un module qui permette la collaboration directe entre l’ERP et le web service e-dec, soit pour intégrer dans la PME une politique de gestion des processus qui soit basée sur un BPMS. Cette dernière option sera sans doute la plus intéressante pour l’entreprise si elle entend profiter de toute la puissance des outils de BPM. Il lui serait alors possible de pouvoir adapter son SI aux processus de manière optimale. Pas uniquement pour des cas concernant l’export, mais pour tous les processus de l’entreprise.

Pour réaliser cette vision, il faudrait traiter des points laissés ouverts par ce travail. Il faudrait tout d’abord commencer par une étude approfondie de l’offre faite aux PME pour intégrer de tels systèmes, tant au niveau de la solution logicielle - et de l’architecture qu’elle implique - qu’au niveau de la formation des utilisateurs. Car comme ce travail l’a montré, l’explication des concepts théoriques n’est en rien garante qu’une solution BPMS fonctionne sans difficultés techniques. Si les concepts sont nécessaires ne serait-ce qu’à la formulation des besoins qui motivent le choix d’un BPMS, un lien contractuel avec un fournisseur de solution sera une garantie importante pour que les processus puissent s’exécuter.

Un autre point laissé ouvert par ce travail concerne la collaboration entre le management de l’entreprise et les personnes responsables des processus. Il sera nécessaire que le management puisse, en ayant consulté ce travail, se faire une idée précise sur les approches BPM et SOA et qu’il leur attribue des ressources et des buts qui cadrent avec la stratégie de l’organisation. Pour cela les objectifs des itérations suivantes de BPM Lifecycle devront impérativement être définis à l’aide de métriques quantifiables. Car même si le langage de modélisation de BPMN 2.0 facilite la communication entre les différents acteurs impliqués dans la gestion des processus, c’est bien l’adéquation avec les objectifs fixés qui va être garante que le BPM et SOA soient des approches pertinentes et qui permettent à l’organisation de créer de la valeur.

Bibliographie 76

7 B IBLIOGRAPHIE

AFD, 2012. Manuel e-dec exportation pour la clientèle externe et les entreprises, Berne:

Confédération helvétique.

AFD, 2012. Service Contract für Zollanmeldung, Berne: Confédération helvétique.

BonitaSoft, 2011. Bonita Connector Reference Guide, Grenoble: BonitaSoft SA.

BPMS Maîtriser la complexité, 2012. bpms.info. [En ligne]

Available at:

http://www.bpms.info/index.php/component/option,com_glossary/Itemid,75/catid,95/func,view /term,BPMM/

[Accès le 01 03 2013].

BPtrends, 2007. SOA Maturity Model. [En ligne]

Available at: http://bpmg.orgwww.bptrends.com/publicationfiles/04-07-ART-The%20SOA%20MaturityModel-Inagantifinal.pdf

[Accès le 17 03 2013].

Brocke, J. V. & Rosenmann, M., 2009. Handbook on Business Process Management 1.

Heidelberg: Springer.

Caseau, Y., 2011. Urbanisation, SOA et BPM. Paris: Dunod.

Collectif, 2009. Encyclopedia of Information Science and Technology. New York: Information SCI.

CSB, 2013. Site web CSB. [En ligne]

Available at: http://csbapp.csb.uncw.edu/janickit/mis213/learning/module8/8-2.htm [Accès le 01 04 2013].

Cummins, F. A., 2009. Building the Agile Enterprise. Burlington: Elsevier.

Cummins, F. A., 2009. Building the agile enterprise with SOA BPM and MBM. Burlington:

Morgan Kaufmann Publishers.

Morgan Kaufmann Publishers.