Actualités

[26/06/2017] Smile acquiert Hypertexte, expert en référencement naturel (SEO) et en contenus optimisés

Smile annonce l’acquisition de l’agence Hypertexte, spécialiste du référencement naturel, de la conception et de la réalisation de contenus pensés pour le SEO.

[21/06/2017] Smile dans le top 10 des entreprises où il fait bon travailler !

Smile entre dans le classement très fermé des entreprises où il fait bon débuter sa carrière. Un palmarès publié dans Les échos et réalisé par Meilleures-entreprises.com.

[20/06/2017] Smile classé 1er hébergeur en haute disponibilité depuis 3 mois

Depuis début mars, soit 3 mois consécutifs, Smile est à la tête du Classement des Hébergeurs en haute disponibilité, réalisé par ip-label et le Groupe NextRadio TV (01net, BFM, RMC).

Toutes les actualités picto
       

Vous avez besoin de mettre à jour votre Lecteur Flash Flash 7

Guillemet ouvrant l'actualité des solutions
et des technologies open source Guillemet fermant
picto

BPM et génération de formulaires automatique: les solutions open source

Intalio, Netbeans, Bonita, les éditeurs de BPM et de génération de formulaires rivalisent d'ouverture open source et vous apportent des possibilités très puissantes.

La BPM

Les processus d'entreprises sont à la fois variés, complexes et changeant. Ils recoupent des actions aussi diverses que le passage d'une commande à un fournisseur, l'émission d'une proposition commerciale, la demande d'une prise de congés ou encore la publication d'un contenu dans un CMS. Leur caractéristique est de changer l'état de données selon des process automatiques d'une part et des interventions humaines déléguées aux différents acteurs de l'entreprise selon leurs responsabilités d'autre part. L'acronyme rattaché à ce concept s'appelle la BPM (Business Process Management).

L'informatique permet aujourd'hui d'automatiser à la fois les parties de traitement de données, mais aussi la délégation aux employés des process. Outre le gain de productivité lié à la dématérialisation et à la dispense d'administrateur physique des process, les bénéfices apportés par un moteur de process sont aussi la traçabilité et l'assurance que les process sont respectés à la lettre (c'est bien sûr le design des process qui devra anticiper les marges de tolérances). Cependant, plusieurs approches sont envisageables pour modéliser puis exécuter ces processus:

  1. On peut naturellement 'hardcoder' spécifiquement au cas par cas la logique métier avec l'infrastructure, en faisant par exemple des requêtes SQL dans un langage de programmation, l'état du process étant testé de façon plus ou moins systématique par des requêtes spécifiques. Si elle ne crée aucune dépendance, cette approche a néanmoins des limites évidentes en terme de fiabilité (tous les états possibles ne sont pas forcément traités, il peut y avoir des cas blocages) et par ailleurs cette solution pêche également par son manque de maintenabilité: en effet, un processus codé en plusieurs centaines voire milliers de lignes qui mélange allègrement actions métiers, tests sur les droits, code de log et requêtes SQL n'est pas très lisible et par conséquent peu maintenable dans le temps. A noter que l'usage d'un ETL permet certes d'élever l'abstraction, mais ne permet pas la délégation correcte des actions aux employés ni de traçabilité ni de monitoring à ce niveau.
  2. Si on monte un petit peu en abstraction, chaque progiciel peut séparément décider d'offrir une abstraction de type machine à états de ses processus. Dès lors le progiciel met un oeuvre un "moteur BPM" qui va savoir exécuter les différents processus qui lui sont soumis et qui sont modélisés dans un langage déclaratif approprié, à un haut niveau d'abstraction qui se concentre sur les aspects métiers et abstrait les problématiques d'infrastructure tacitement admises par l'adhésion au concept même de BPM. Il peut ou non y avoir une interface graphique (éventuellement web) pour éditer ce langage déclaratif (souvent XML) d'une façon plus intuitive, mais c'est assez rare ou alors les limites de l'éditeur graphique se font très vite sentir lorsque ces moteurs de process sont trop spécifiques. Généralement, les solutions de CMS ou de GED open source, par exemple celles proposées par Smile font appel à ce type d'abstraction des processus. C'est encore le cas du moteur de process de la solution de GED Alfresco qui, si elle est robuste ne dispose pas d'une interface d'édition très poussée. Listons encore ici TinyERP, dont la modélisation XPDL sur un moteur propre rend le code très léger et flexible avec à la clé un ERP immensément plus fonctionnel qu'un ERP ne disposant pas de BPM tel que Compiere ou Ofbiz, mais qui n'offre encore pas d'éditeur orienté utilisateur final.
  3. Mais finalement, on peut aussi pousser la logique d'abstraction encore plus loin et dire que les process sont centralisés dans un moteur de process externe qui va invoquer des actions spécifiques sur les différents progiciels en fonction de l'évolution de l'état des processus. On atteint ainsi un degré d'intégration très intéressant. En revanche, ceci ne marche bien sûr que si les progiciels qu'on prétend intégrer sont suffisamment ouverts en terme de webservices. Contrairement aux solutions de BPM d'éditeurs de produits spécifiques, cette solution générique a tendance a être d'autant plus mature et orienté utilisateur final (non codeur) qu'elle mutualise les efforts de développement dans des concepts très génériques. Au final, les progiciels capables d'externaliser leurs process sur de tels moteurs bénéficieront en retour de ces back-office très matures pour l'édition et le monitoring de ces process.

Le bonne nouvelle, c'est donc l'arrivée sur le marché d'une féroce compétition open source pour prendre le leadership de ces moteurs de process génériques. En ces temps de dumping open source, il est donc totalement dans votre intérêt de grappiller chez les éditeurs ces briques hautes de gamme devenues libres et interopérables.

La normalisation des process métiers: BPMN

La mutualisation des bibliothèques de process ainsi que du moteur de process présuppose l'uniformisation de la modélisation des process entre les différentes sensibilités métiers. Cela fait déjà de nombreuses années que des travaux de normalisation sont menés et aujourd'hui on peut dire que sous l'impulsion du comité de normalisation BMI.org, le langage graphique "BPMN" emporte une large adhésion. Une récente étude de BPTrends.com rapporte ainsi que 41% des 274 enquêtés utilisent BPMN lorsqu'ils n'utilisent pas des langages encore plus précis tels que BPEL et OMG (33% à eux deux). A la seconde place des langages orientés utilisateur, on trouve donc CMM/CMMI (28%), qui a d'ailleurs été très utilisé en France.

La normalisation des process éxécutables: JPDL, XPDL et BPEL

Normaliser les symboles de dessin des process, à l'instar de BPMN, est une bonne chose car elle aide les personnes de différents métiers à communiquer et à interagir dans des process communs. En revanche, elle n'aide pas les machines à interpréter les process. Pour ceci, d'autres langages, plus bas niveau, avec plus de paramètres techniques doivent être définis. Un bon éditeur graphique comme Intalio ou Netbeans se chargera d'offrir une interface de modélisation type BPMN mais en même temps de produire le code correspondant dans ce langage exécutable. Différents standards exécutables existent, passons les principaux en revu:

  • JPDL: il s'agit du frigidaire du BPM: ce n'est pas un standard, mais son large support par JBoss (JBPM) et de nombreuses applications l'a rendu populaire et fiable. Hélas, du coté des outils d'édition, l'éditeur lourd Eclipse fait un peu pâle figure devant des éditeurs comme Intalio. En fait, si l'édition des process par une interface type BPMN est acceptable, l'édition des formulaires qu'on pourrait y rattacher est trop légère pour l'instant. L'édition de formulaires un minimum complexes avec de petites règles de validation nécessitera donc de coder. Un process JDPL n'est pas non plus portable, il doit être exécuté par l'interpréteur JBPM et les extensions utilisés dans un process JDPL sont potentiellement dépendantes du classpath de l'environnement applicatif. JPDL est tout juste lisible par un codeur et devra impérativement être édité. Il n'en reste pas moins que disposer de process JPDL est beaucoup mieux que rien et c'est sans doute une des raisons par exemple de la fiabilité et de la souplesse d'un produit comme Alfresco.
  • XPDL: il s'agit cette fois d'un standard mais qui n'a pas vocation à couvrir 100% de la modélisation d'un process. Globalement, la structure du workflow, et les noms des étapes seront respectés. En revanche, les "hooks", ces API externes qu'on appelle lors des transitions pour effectuer des actions (envoi d'un mail ou d'un webservice, lecture dans une base...) sont là aussi dépendantes du classpath de l'environnement applicatif. Ainsi, un process XPDL sera portable à 80%. Donc XDPL, tout comme JPDL, facilite l'interopérabilité, mais ne l'automatise pas. Ajoutons qu'XPDL est un peu à mi-chemin entre code exécutable et code lisible: il est beaucoup moins orienté métier que le BPMN, il teste par exemple les rôles sur chaque noeud au lieu d'utiliser la modélisation type "swimlane" associée aux rôles du BPMN. Ainsi il reste intelligible mais est moins lisible ou facile à créer que du BPMN. Voilà pourquoi Bonita, par exemple, s'il rend l'édition de process possible pour des profils techniques, permet plus difficilement aux profils uniquement fonctionnels de s'approprier la modélisation. A Smile, c'est TinyERP que nous retrouvons dans ce cas. Là encore, des gains immenses par rapport à la majorité des ERP qui ne poussent pas l'abstraction jusqu'au BPM et dilapident leurs effort en code au raz des pâquerettes.
  • Pourtant, le graal du BPM existe. Il se nomme BPEL. BPEL réalise l'exploit de rendre vos processus véritablement 100% portables. Il s'agit en effet d'un langage déclaratif directement interprétable et qui se suffit à lui même. Oui mais alors comment faire pour écrire quelque chose dans ma base de données propre ou me connecter à mon API propre et comment cela peut il être portable? Eh bien l'astuce de BPEL, c'est de déléguer l'équivalent des "hooks" personnalisables du XPDL à l'appel de webservices externes SOAP. Dès lors, si l'environnement SOAP est en place, le moteur BPEL peut être changé sans aucun problème. BPEL déporte donc la difficulté dans l'exigence d'un éco-système SOA (Service Oriented Architecture) complet. Mais ceci est heureusement relativement acquis sur la plateforme Java très mature dans ce domaine.

les formulaires

Qui dit process d'entreprise dit aussi interface graphique orientée utilisateur final (cette fois). On parle donc ici de formulaires web. Lors d'une demande d'achat par exemple, un employé peut disposer d'un formulaire de demande d'achat, puis lors d'une étape ultérieure, un comptable va lui aussi disposer d'une nouvelle interface qui va par exemple lui permettre, outre la validation de l'achat, d'attacher des données d'ordre comptable à la demande d'achat.

Ce qui est nouveau, c'est qu'on dispose enfin, sous certaines conditions, d'outils graphiques sans coder pour générer ces formulaires, puis transmettre les données qu'ils collectent au moteur de process qui saura alors les dispatcher au différents services métiers, et ce, encore une fois grâce à un paramétrage totalement graphique et sans code.

Les outils graphiques les plus accessibles aux non programmeurs sont des interfaces de type glisser-déposer qui permettent de générer des formulaires XForms, lesquels sont ensuite automatiquement déployés sur un émulateur web de XForms, tel que Chiba ou Orbeon qui vont offrir une interface Ajax+DHTML (y compris dégradable pour une accessibilité W3C) à l'utilisateur final. Ci-dessous: un formulaire web présenté par Orbéon:

 

Techniquement parlant, Chiba et Orbeon prennent la forme d'un ServletFilter qui va venir s'interfacer entre le client web et la servlet qui traitera in fine l'action HTTP POST classique. Tant que le formulaire ne valide pas toutes les contraintes XForms (champs obligatoires, regexp...), des allez-retours AJAX (éventuellement dégradés en non Ajax, en tout cas pour Chiba en absence de Javacript) auront lieu entre le ServletFilter et le client. A la fin les données sont transmises à la servlet comme pour un formulaire HTTP classique, en l'ocurrence au moteur de BPM dans notre cas. Lorsqu'on utilise Chiba ou Orbeon seuls au moins, on peut aussi générer dynamiquement le XForm avant de commencer à le servir (mais pas en cours d'interaction), par exemple avec une JSP.

Bien sûr, l'utilisation de Xforms n'est pas une obligation et elle a aussi des limites à bien connaître, notamment:

  • dépendance envers des outils difficiles à faire, et donc pas toujours disponibles sur les plateformes désirées ni avec les licences désirées
  • quasi impossibilité de recharger dynamiquement des champs d'un formulaire, par exemple d'avoir deux listes déroulantes interdépendantes nécessitant des requêtes en base de données

On peut bien sûr passer outre les XForms et alors opter pour des frameworks plus souples et plus puissants comme les JSF ou JRuby on Rails qu'on connectera alors au moteur de services par webservices. Il s'agit là d'un développement d'infrastructure spécifique. Ensuite, le développement de chaque formulaire, à défaut d'être 100% graphique, le sera partiellement ou encore sera guidé par une pratique de développement standard et la programmation, s'il y'en a se fera par langage déclaratif.

Intalio

Intalio est un moteur BPM d'une efficacité redoutable. Tout y est graphique avec une très bonne finition des interfaces et seuls des composants robustes et fiables sont utilisés. Ainsi:

  • le client lourd d'édition des process et des formulaire est constitué de plugins Eclipse minimalistes, propre et open source (licence EPL)
  • le "player de XForm" n'est autre que le réputé Orbeon
  • les flux d'informations qui sont transmis au cours des workflows sont définis par des schémas XML qu'on édite graphiquement avec Eclipse le cas échéant
  • l'interopérabilité avec l'extérieur se fait en webservice SOAP, graphiquement grâce à lintrospection des fichiers de description des webservices WSDL

 

Mais surtout, Intalio utilise un BPEL comme définition de ces process et comme moteur d'exécution. Il s'agit là d'un must de l'interopérabilité puisqu'on n'a plus aucune dépendance en terme de classpath ou même de technologie (on peut y mixer allègrement du .NET, du Java ou du Ruby).

Outre l'édition des process, Intalio offre aussi une interface graphique permettant de dessiner des XForms et d'appliquer un certain nombre de contraintes (champs obligatoires, regexps, types de champ...). Pour allez plus loin dans les possibilités des XForms (champ conditionnés à d'autres etc...) il faudra hélas compléter l'édition du XForm à la main. Mais gageons que l'éditeur graphique suffise dans 90% des cas, c'est déjà ça de pris par rapport au formulaires qu'on doit hardcoder depuis le début traditionnellement. Le contrôle de la présentation existe aussi mais là encore il faut s'attendre à quelque chose de moins fin qu'un formulaire fait au cas par cas; l'objectif ici n'est pas l'optimisation graphique d'un formulaire en particulier, mais bien l'automatisation de la création des interfaces.

 

Par ailleurs, un énorme atout d'Intalio est encore son "data mapper" qui permet, à l'instar d'un ETL (tel que Kettle ou Talend), d'effectuer graphiquement les correspondances entre les flux d'information. Ainsi, après avoir créé un formulaire XForms graphiquement, on peut facilement associer les champs collectés pour les envoyer dans un webservice d'un ERP ou d'un ETL par exemple. Lorsqu'il s'agit d'un webservice, le fichier de description WSDL est automatiquement introspecté pour générer la bonne interface graphique. D'autres connecteurs tels que JDBC, Ldap, Netweaver existent mais ils ne sont pas au rendez vous de la version gratuite Community Edition.


Le tableau serait parfait si la politique de licences était plus claire. En effet, l'usage exact qu'on peut faire de progiciel dans sa version community manque de lisibilité. Intalio stipule que sa version Community peut être utilisée comme on veut à la condition qu'elle ne soit déployée que sur un serveur J2EE Geronimo et une base Derby ou MySQL. Pour un intranet, même assez gros, cela conviendra sans problème. Pour aller plus loin, peut être qu'une entreprise souhaiterait utiliser JBoss, avec Oracle ou PostGreSQL par exemple, si elle les maîtrise. Et pour ces utilisations, il faut acquérir une licence "Entreprise".

Pourtant, Intalio est composé essentiellement de 3 composants, tous sous des licences libres:

  • Intalio Tempo: les interpréteurs de process BPEL entre autre: ils sont sous licence Eclipse EPL (semblable à Mozilla Public licence en changeant Mozilla par Eclipse)
  • ODE: un orchestrateur de webservices SOAP: sous licence EPL aussi
  • Eclipse STP BPMN Designer , là encore donné à la fondation Eclipse sous licence EPL.

Dès lors, il n'est pas interdit de prendre les composants séparément, et les déployer où on veut selon les seules restrictions permises par les bibliothèques EPL et Apache embarquées par Intalio. De plus, le code BPEL2.0 généré est également portable à un autre interpréteur BPEL, c'est bien la puissance de l'architecture SOA. Cela fait un peu penser à la politique de RedHat ou Mandriva qui sur leurs sites se gardent bien de mettre des liens pour télécharger gratuitement ce qu'ils proposent de vendre, alors que les licence qu'ils utilisent le permettent et des organisations comme CentOS en profitent eux allègrement.

Ce qu'il y a aussi de sûr, c'est qu'un certain nombre de composants comme un connecteur JDBC, Ldap ou encore un connecteur SAP sont resérvés aux packages payants (et c'est bien normal). A priori, encore une fois les licences employées devraient permettre de contourner ces restrictions et développer ses propres connecteurs dans le cas ou vous estimeriez ceux d'Intalio trop chers. Pour les connecteurs WSDL vers JDBC (par exemple en automatisant l'extraction de classes entités à partir de base JDBC par le plugin libre JAX-RS de Netbeans, puis en y rajoutant les annotation JAX-WS adéquates automatiquement pour une exposition au minimum Creat Read Update Delete par SOAP+WDSL) ou Ldap (via Ldapbc par exemple), il ne fait pas l'ombre d'un doute qu'on peut utiliser tous ceux qu'on souhaite. En revanche, il faudrait vérifier que tel est bien le cas des connecteurs s'interfaçant par API cette fois qu'on voudrait développer.

Quoi qu'il en soit, pour une utilisation en entreprise dans un contexte critique, le support de l'éditeur sera certainement une bonne option.

Netbeans

L'éditeur BPEL de Netbeans est très similaire à celui d'Intalio. Il permet donc de dessiner des process tout aussi complexes et portables puisque que l'affichage est BPMN mais le code produit est BPEL2. Cette fois c'est Swing plutôt que SWT qui est utilisé (on pourrait donc imaginer des applets d'édition RIA sécurisées alors que ça ne sera pas le cas avec SWT).


Tout comme Intalio, Netbeans dispose d'un "data mapper" tout aussi efficace qui sait intropsecter entre autres les descripteurs de webservice WSDL pour demander comment les champs doivent être associés. Mais Netbeans étant plus ouvertemet open source qu'Intalio, disons qu'on se sentira moins prisonnier pour développer ses propres connecteurs si on répugne au SOAP.


L'inconvénient majeur de Netbeans est de ne pas disposer lui d'éditeur de formulaires qui permette de se dispenser totalement de code. L'idée est alors de passer par les JSF dont l'édition est graphique à 90% et standardisée. Mais hélas, il y aura touhours 10% du code pour les lier les JSF aux webservices ou autres connecteurs BPEL qu'il faudra alors coder à la main. On développera éventuellement un framework générique pour rendre ces développements plus simples et plus fiables.

 

Autre idée, utiliser (J)Ruby on Rails dont le support par Netbeans est impressionnant et totalement assumé par Sun Microsystem. L'idée est alors de produire des formulaires dans un langage déclaratif minimaliste à la fois très souple et très puissant. Mais cette fois, la puissance sera au détriment de toute interface graphique, du moins pour l'instant. Par rapport aux JSF, on disposera alors de plus de facilités pour réaliser des choses plus complexes, par exemple en terme d'AJAX. Avec Rails, on produira aussi des formulaires facilement dégradables au sens W3C (l'usage du javascript est dit "inobstrusif"), ce qui est très rarement possible avec les JSF et encore moins avec l'implémentation de Sun supportée par l'éditeur graphique de Netbeans.

En particulier, on utiliserait alors un plugin Rails de développement rapide de back-office, tel que ActiveScaffold. Autre avantage à considérer de cette méthode: non seulement on réalise des formulaires AJAX très complets en quelques rares lignes de code déclaratives, mais surtout on génère en même temps la structure de la base de données avec les associations adéquates, ainsi que la couche d'ORM (Object Relationnal Mapping) ActiveRecord qui se fera l'intermédiaire entre le SGBD et la modélisation objet, notamment utilisée par le formulaire mais qu'on pourra remettre à profit par ailleurs, notamment pour du code métier ou une exposition par webservice. Utiliser Rails, c'est aussi ne dépendre d'aucun outil puisque la puissance du (J)Ruby suffit à elle seule à garantir à la fois la productivité d'une interface graphique, toute la puissance du code objet et la programmation déclarative type XML (en fait la souplesse syntaxique de Ruby permet d'utiliser différents paradigmes tels que la programmation fonctionnelle (grâces aux closures notamment) impérative ou déclarative comme par exemple dans ce cas des forumaires où on ne cherche à qu'à expirmer une serie de contraintes dans un contexte métier bien définis et couvert par un framework léger tel qu'ActiveScaffold.
.

Bonita

Le troisième laron de notre étude s'appelle Bonita, un progiciel développé par Bull et rendu open source. Tout comme Intalio, Bonita permet d'éditer graphiquement formulaires et processus dans un client lourd qui ne servira là aussi que pour le back-office; le front office étant full web. Tout comme Netbeans, le client lourd est en Swing. Cependant, à la différence d'Intalio et de Netbeans, il ne s'agit pas d'une plateforme de client riche réputé et solide mais d'un développement spécifique qui coûte bien plus à développer et à maintenir que le RCP Netbeans ou le RCP Eclipse. Cette interface s'appelle ProEd.

Pour ce qui est des formulaires, le système est très sensiblement le même que celui mis en oeuvre par Intalio (bien qu'offrant moins de contrôles visuels): il s'agit d'un éditeur graphique de XForms. ces Xforms sont déposés automatiquement sur le moteur de processus. Lorsqu'un formulaire doit être soumis à un utilisateur, c'est le moteur de formulaire Chiba (là où Intalio utilisait Orbeon) aui va cette fois être utilisé pour présenter une interface DHTML+Ajax qui émule le comportement d'un formulaire XForm pour les navigateurs web. Les fonctionnalité d'édition de formulaire sont très sensiblement égales à celles d'Intalio ici.


En revanche, côté process, Bonita semble un cran en dessous (mais toujours intéressant). En effet, le standard utilisé n'est pas ici BPEL mais XPDL. Ceci veut dire qu'il s'agit d'un standard certes orienté technique et précis, mais qui n'est pas portable à 100%. Au lieu comme dans BPEL d'appeler les action externes par web services, Bonita appelle les "hooks" directement en Java: on a qu'à choisir dans une liste le hook à appeler. Il s'agit de toutes les classes du classpath Java qui implémentent la bonne interface Bonita. Dès lors cette classe peut être invoquée lors d'une transistion: elle a accès au flux d'information entrant et sortant. Mais donc là encore, les possibilités sont moindres. En effet, charge au code Java de prendre et de faire sortir les bons paramètres, il n'y a pas comme dans Netbeans ou Intalio de "data mapper" graphique qui permette facilement à la personne éditant un process de décider quels paramètres passer.

 

 

Si Bonita est inférieur en terme définition de processus, pourquoi en parler? Eh bien parce que Bonita a néanmoins l'avantage non négligeable de posséder une licence LGPL et une communication open source beaucoup plus claire qu'Intalio.

Comme nous l'avons vu, les solutions open source de BPM et de gestion de formulaires sont de plus en plus compétitives et devraient suciter plus souvent la réflexion en vue de leur adoption car dans bien des cas, l'alternative consiterait alors à engloutir de gros budgets dans le codage manuel et non maintenable des process et de leurs interfaces. Attention, si ces solutions sont partiques pour les administrations et les intranets, leur défauts éventuels en terme de scalabilité et leur manque de flexibilité dans les interfaces en limitera toujours l'usage pour les applications grand publique et B2C, domaines pour lesquels le code a encore de belles perspectives.

Raphael Valyi
picto