Tag :BRMS

BRMS – Les produits existants : ILOG et Drools. Paris JUG (Partie 2)

Après la dégustation de spécialités mauriciennes et le résultat du jeu concours lancé par Ippon, retour aux choses sérieuses avec la présentation de deux BRMS présents sur le marché : ILOG et Drools.

Enabling agile business and IT collaboration using the ILOG BRMS

Daniel Selamn, architecte du produit chez IBM Websphere est venu nous présenter Ilog, l’ancien JRules. Convaincu que dans un monde qui change vite, le SI doit être capable d’évoluer très vite, Daniel est venu nous parler de ce qu’il appelle une “Change Oriented Architecture”.

Daniel Selamn

Daniel Salamn – Photo : José Paumard

Différents types de changement

De la même façon qu’on a externalisé les données dans des bases, on cherche maintenant à externaliser la logique métier dans un dépôt externe. Néanmoins les changements dans une application peuvent être de types très différents : il peut s’agir d’un refactoring de code, de modèle, de règles métiers, de GUI, etc … Chacun de ces changement impliquera un processus et aura un impact différents sur l’application, les tests et la validation ne seront pas les mêmes pour tous.

Changement et données

Un processus de validation du changement a besoin de méta-donnée : quel est le numéro de version ? est-ce validé ? est-ce déployé ? Ces méta-données vont aussi refléter l’aspect humain du changement : qui a demandé ce changement ? qui l’a fait ? qui l’a validé ? De plus même lorsqu’une nouvelle version est disponible et déployée, les précédentes doivent toujours fonctionner. Tout ceci rentre en compte dans le processus de traçabilité, processus relativement coûteux d’où l’intérêt d’externaliser les règles. C’est ce que Daniel appelle le “time-travel” : la possibilité de simuler à tout moment un résultat avec un ancien jeu de règles.

L’humain face au changement

Les audits quant à eux coûtent cher aussi, néanmoins avant tout changement il faut s’assurer que les conditions nécessaires sont réunies : le code doit être prêt avant que l’utilisateur ne s’en serve, ce qui demande une coordination dans l’équipe. De plus il ne faut pas perdre de vue que le travail réalisé doit rester compréhensible par des humains, c’est à dire des personnes dont le raisonnement, contrairement à celui d’une machine, ne peut pas changer toutes les semaines voir tous les jours ou toutes les heures.

Le rôle de l’IT

Les développeurs et l’architecte doivent mettre en place le container for change, ce qui nécessite :

  • une réelle compréhension du business
  • des outils compréhensibles par tout le monde
  • des connaissances approfondies certes, mais aussi diversifiées
  • de bien connaître la problématique de gouvernance : pourquoi a-t’on fait ces changements ?
  • d’avoir réussi à faire intégrer au management que l’intérêt de payer plus au départ est d’avoir une pérennité sur le long terme
  • d’avoir correctement listé les types de changements nécessaires afin de limiter le “over-engineering”

Change cycle with Ilog BRMS

Pour le développement du langage usuel qui sera utilisé par le métier, Ilog offre un environnement eclipse : le Rule Studio. Le RuleTeamServer quant à lui, est un environnement basé sur le web pour les utilisateurs métiers offrant à la fois la possibilité d’éditer les règles dans le repository, de les versionner, commenter etc … Les modifications sont clairement repérables et traçables. Les règles sont ensuite déployées dans un serveur qui sera appelé par l’application finale pour les exécuter : le Rule Execution Server. Celui ci permet d’obtenir des statistiques, de rechercher une transaction individuelle, d’exporter les données, bref de faire du Business Intelligence.

Plus d’informations sur Ilog ici.

Pushing the rule engine to its limits with Drools Planner

Cette quatrième partie de la soirée a été présenté par Geoffrey De Smet. Geoffrey a travaillé dans plusieurs projets opensource, notamment des plugins Maven, Spring Rich Client et d’autres projets JBoss. En 2007, son framework des méta-heuristiques – aujourd’hui connu sous le nom de Drools Planner – a été pris par JBoss.org et la communauté Drools. Depuis 2010 il travaille pour Red Hat à temps complet sur la plateforme Drools.

Geoffrey De Smet

Geoffrey De Smet – Photo : José Paumard

La présentation a été vraiment riche en contenu, très intéressante et méritait bien une heure complète.

Drools – plateforme

La plateforme de Drools est composée des modules suivantes :

  • Expert : Le moteur des règles
  • Flow (jBPM 5) : Le workflow bussiness associé à un processus
  • Fusion : Complex Event Processing (CEP)
  • Guvnor : Le BRMS (Business Rule Management System)
  • Planner : Automated planner

Geoffrey est venu nous présenter le module “Planner”

Qu’est-ce que c’est un problème de planning ?

Geoffrey, très passionné par son métier, nous a démontré par un exemple récent de sa vie quotidienne ce qu’est un problème de planning.

Qui n’a jamais été chez Ikea, ou n’a jamais déménagé ? On se retrouve avec plusieurs cartons de différentes tailles … mais on ne dispose que d’une seule voiture. On souhaite tout y mettre  afin de réaliser un seul voyage (ou le minimum de voyages possible), donc pour cela il faut économiser l’espace, ranger les boîtes dans un ordre précis et les placer dans la bonne position, ce qui n’est pas évident. On doit toujours passer pas mal de temps pour trouver le bon ordre… Et finalement on se demande si on avait bien choisi ou si une autre manière d’ordonner n’aurait pas été plus performante….

Ceci est connu comme étant un problème de “Bin packaging”. La réalité est que pour un problème déterminé, il n’existe pas une et une seule solution. Pis, si la solution n’existe pas, il n’est pas facile de prouver la non-existence de solution. Drools planner est là pour trouver la solution la plus optimale, ou nous montrer qu’aucune solution n’existe.

Organisation des employeurs

Imaginons le besoin d’organiser le travail des employés d’un hôpital, notamment les rotations des infirmières. Drools Planner est capable d’organiser tout cela en tenant compte des contraintes – qu’elles soient fortes ou faibles, tout en travaillant en parallèle avec Drools Expert (le moteurs de règles). Par exemple, une contrainte forte peut être qu’une infirmière ne peut travailler qu’un tour par jour (sinon elle sera trop fatiguée) :

// a nurse can only work one shift per day
rule "oneShiftPerDay"
   when
      $left : EmployeeAssignment(
              $employee : employee,
              $shiftDate : shiftDate,
              $leftId : id
      );
     $right : EmployeeAssignment(
              employee == $employee, shiftDate == $shiftDate,
              id > $leftId);
     then
        // Lower the hard score with a weight ...
end

Et en même temps, des contraintes faibles vont venir s’ajouter : par exemple certaines infirmières préféreront ne pas travailler le mercredi et d’autres préféreront avoir leur week end. Or, la quantité de contraintes faibles est plus nombreuse que celle des contraintes fortes. Drools planner est capable de travailler avec beaucoup de contraintes de manière efficiente, ce qui améliore ne seulement le service offert, mais également l’optimisation des ressources.

Admission des patients d’un hôpital

Une autre problématique liée à la planification, en restant dans le domaine de la santé, est l’organisation de l’admission des patients dans un hôpital. Ainsi :

Quelques contraintes fortes:

  • Deux patients ne peuvent pas occuper le même lit dans la même nuit
  • Les hommes et les femmes occupent des chambres séparées
  • Le patient a besoin d’équipement adapté

Quelques contraintes faibles :

  • La spécialisation du département
  • La spécialisation de la chambre
  • Le patient demande un équipement particulier dans la chambre

Les données suivantes sont réelles. On dispose de 310 lits et de 2750 patients (admissions) – sans tenir compte ici ni des départements, ni du genre de la chambre, ni du nombre de nuits à planifier.

Combien existe-t-il de solutions possibles ? Moins que …

  1. la quantité d’ouvrages du Louvre : 35 000 ?
  2. le nombre d’humains sur terre : 7 000 000 000 ?
  3. le minimums d’atomes observables dans l’univers : 10^80 ?
  4. le nombre d’atomes dans l’univers dans lesquel chaque atome est un univers lui même  : (10^80)^80 = 10^6400 ?
  5. plus ? :)

La quantité de possibilités dans le cas décrit est d’un peu plus de 10^6851 !!!!!!!! Et comment ? (ahh les maths …)

  • 1 patient, 310 possibilités
  • 2 patients, 310×310 possibilités : 96 100
  • 3 patients, 310 x 310 x 310 : 29 791 000
  • 2750 patients : 310 ^ 2750 –> un peu plus de 10^6851

Drools planner à l’aide de Drools Expert nous permettra de trouver la bonne planification.

Les algorithmes – les bons algorithmes vs le CPU

Geoffrey nous a expliqué ici que la recherche des résultats de planification avec les données décrites précédemment, et ce de façon performante n’est pas possible aujourd’hui avec les seules machines et leur hardware aussi puissant soit-il (c’est qui est appelé la force brute). Ainsi, si on réalise des algorithmes un tant soit peu intelligents, mais pas suffisamment, on n’y arrivera pas non plus.

Dans cette partie qui a été très rapidement expliquée, faute de temps, on retient que Drools Planner comprend des fonctionnalités pour réaliser des recherches et des algorithmes complexes et performants. On apprend que ces algorithmes de recherche ont aussi une nature stateful : les voies de recherche déjà explorées sont mémorisées, les branches qui ne sont pas liées à un changement particulier dans l’arbre de recherche ne sont pas explorées etc. Cette partie n’est pas facile, mais elle suppose un vrai challenge vis -à-vis de notre métier.

Conclusions

Avec Drools planner on pourra résoudre des vrais problèmes de planification. On sera capable d’ajouter des contraintes facilement et de façon scalable, et rendre facile l’adaptation et/ou la combinaison des algorithmes de recherche.

Pour en savoir plus rendez-vous sur http://www.jboss.org/drools/

Au prochain Paris JUG !!

:-)

A la découverte des moteurs de règles – Paris JUG Novembre (partie 1)

La soirée a commencé par la réunion d’une quinzaine de personnes à l’Avant JUG, dont l’un de nos speakers de la soirée : Emmanuel Bonnet ! Ce dernier nous a d’ailleurs parlé du JUG qu’il fréquente régulièrement : le JUG Toulouse.

Puis départ vers les locaux de l’ISEP et pour commencer la soirée, un petit retour d’Antonio sur la réunion à laquelle les JUGs leaders européens étaient conviés par Oracle le mois dernier. Pour un résumé de cette rencontre, voir ici. Pour continuer un retour sur le fonctionnement du site javablackbelt par le responsable du site mais qui ne vient jamais au JUG ;)

Et pour finir avec l’introduction de la soirée, présentation d’Ippon, sponsor de la soirée qui mettait en jeu deux places pour Devoxx, hébergement et transport inclus.

Les BRMS (Business Rules Management Services) ou plus simplement les moteurs de règles

Durant cette première moitié de soirée (ils sont comme ça au JUG, ils n’hésitent pas à passer sur la quantité, pourvu que la qualité soit au rendez vous ;) ) Emmanuel Bonnet, consultant et expert en BRMS chez Génigraph nous a présenté les concepts fondamentaux liés aux BRMS et les moteurs des règles.

Les BRMS

Emmanuel Bonnet – Photo : José Paumard

Et pour commencer nous apprenons que le concept des BRMS n’est pas nouveau. En effet, notre speaker travaille depuis 10 ans maintenant dans l’implémentation de solutions d’architecture basés sur les moteurs de règles.

Les moteurs de règles s’articulent autour de trois concepts :

  • l’écriture des règles métiers,
  • l’exécution de ces règles par le moteur de règle,
  • la gestion de ses règles et de leurs versions par un BRMS.

La recette du moteur de règle en trois ingrédients :

Prenez quelques règles métier …

Une règle métier, c’est du contenu métier exprimé sous forme intelligible par tous, y compris (et surtout en fait) le commun des mortels. Traditionnellement une règle métier est exprimée sous la forme “Si … Alors …”.

… ajoutez-y un un moteur d’inférence …

Sous ce mot quelque peu barbare se cache en fait le “cœur” du moteur de règle : les algorithmes et ensemble d’API qui exécutent les règles précédemment énoncées.

… et faites cuire le tout dans un BRMS !

Le BRMS est là pour assembler les règles métiers et le moteur d’inférence. C’est lui qui est responsable du cycle de vie des règles, de leur écriture et de leur exécution. Il doit permettre de gérer une configuration qui s’avère souvent problématique, permettre d’avoir des version des règles et de mettre en place des processus de test et de validation.

Quand utiliser un moteur de règle ?

Dans la demande du client peut se faire sentir le besoin de changement qui peut parfois être extrêmement difficile à atteindre. Deux cas nous sont proposés :

  • Le métier du client est trop compliqué pour être mis dans une architecture traditionnelle,
  • Le cycle de vie des règles change plus souvent que celui de l’application.

Emmanuel illustre son propos avec des exemples parfaitement concrets dans un cas comme dans l’autre :

  • Comment détecter les problèmes de pannes d’un hélicoptère tout en évitant la déperdition d’information ? Le métier demande des connaissances dans des domaines pointus et assez différents de ceux de la programmation, il vaut mieux déléguer la rédaction des règles aux experts de ces domaines, qui seront eux à même de les expliciter.
  • Comment gérer le cycle de développement d’une application où les règles métiers vont être modifiées tous les mois en fonction des besoins du marketing, comme c’est le cas chez les opérateurs de télécommunication par exemple ? Il devient plus intéressant en terme de coût et de réactivité d’externaliser la logique métier dans les règles, elle est ainsi modifiable plus souvent, sans pour autant passer par un cycle de livraison java complet.

Le BRMS est là pour gérer tout ça : on externalise le métier, on l’explicite en règle et le réinjecte dans l’application.

Une fois explicité, le métier est compréhensible par un utilisateur métier ce qui lui donne deux avantages majeurs, il est à la fois :

  • traçable : on peut retrouver facilement la logique qui a amené à telle ou telle prise de décision,
  • modifiable sans l’intervention de développeurs.

La traçabilité devient un avantage non négligeable dans un métier où les règles évoluent rapidement : dans le cas d’un robot trader, elle permet de savoir pourquoi telles actions ont été vendues à tel moment, en remettant le contexte de l’époque en mémoire par exemple.

Remarque intéressante, notre speaker insiste sur le fait que le rôle du métier n’est pas forcément de faire des spécifications ou de gérer les prestataires mais bien de savoir dans son contexte. La forme si/alors va permettre de modéliser le savoir du client en un langage usuel et le rôle du développeur est alors le mapping entre le langage objet qu’il maîtrise et le langage usuel du métier, entre les concepts et la grammaire.

Comme nous le disions en introduction, le concept de BRMS existe depuis des années et il est maintenant assez avancé pour permettre de proposer un langage naturel aux utilisateurs. Le mapping du Business Object Model en Business Rules va lui permettre d’exécuter ce qu’il lit, mais il a néanmoins toujours besoin d’être guidé et c’est là le rôle du développeur. Typiquement, l’usage d’un moteur de règle est particulièrement courant dans des grandes banques, qui vont avoir jusqu’à 14000 règles métiers et des dizaines d’experts, non développeurs, qui sont là pour les gérer.

Le rôle du moteur de données est donc d’inférer pour produire un résultat en fonction du code, des données et des règles qui lui sont passés, et ce en grande quantité puisqu’il a été optimisé pour traiter un très grand nombre de faits et un très grand nombre de règles à la fois.

Emmanuel, apparemment fan d’Odile Deray ;) , appelle l’algorithme Red Is Dead :

  • mieux vaut exécuter mille fois mille règles qu’une fois une règle
  • mieux vaut exécuter une fois mille règle que mille fois une règle

De plus il est capable de ré-exécuter ces règles, encore et encore puisque le résultat qu’il produit est une conclusion qu’il l’amène à de nouveaux faits et donc de nouveaux éléments. C’est la cohérence garantie dans l’exécution, principe qui est résumé par l’algorithme de RETE.

L’architecture

Le client souhaite donc pouvoir modifier la logique régulièrement tout en continuant à faire tourner d’autres versions du contenu en production et ce sans avoir de connaissances en informatique : c’est le rôle du BRMS, qui va lui permettre de gérer les règles, de les exécuter, de faire du monitoring et des statistiques le tout dans un environnement varié, voir même familier.

Un BRMS est principalement constitué de 3 parties :

  • l’interface utilisateur qui va proposer des outils de type word, excel, eclipse ou web pour éditer les règles. Celles ci peuvent être écrite de multiples façons, sous la forme Si/Alors comme expliqué précédemment ou encore sous la forme d’un tableau de décision où les colonnes sont séparées entre conditions et actions et où chaque ligne représente une règle,
  • le dépôt des règles qui va conserver toutes les règles et toutes leurs versions afin d’assurer la traçabilité,
  • la partie intégration qui va lire les règles et produire le résultat. Cela se fait très simplement, en 10 lignes de codes. Mais attention : si vous recherchez des performances ou un déploiement à chaud, la complexité est au rendez vous et c’est pourquoi l’intégration est souvent proposée par les vendeurs de BRMS.

La gestion de configuration nécessite quant à elle quelques outils indispensables pour supporter le processus mis en place : gestion de l’accès concourant, des rôles et autorisations, des processus, etc …

Retour d’expérience

Et pour finir de nous convaincre, notre speaker va insister sur les défis à relever et les faux problèmes à éviter.

Les défis à relever avant de se lancer sont :

  • identifier un projet où l’outil BRMS est vraiment utile. Ce n’est pas toujours le cas, il faut donc s’assurer que le projet remplisse au moins une des conditions citées dans les paragraphes précédents : métier complexe, en constante évolution ou nécessitant une traçabilité,
  • extraire le métier, l’organiser sans qu’il y ait déperdition d’informations,
  • le mettre en place, autrement dit trouver le bon processus.

Les faux problèmes qui pourraient être soulevés sont :

  • les performances. Comme nous l’avons expliqué plus haut, les moteurs d’inférence ont été optimisés pour traiter un grand volume de données,
  • la mise en production rapide. Les utilisateurs métiers étant responsables des règles, puisque c’est eux qui les renseignent, vont bien évidemment vouloir les tester avant,
  • l’implication des utilisateurs. C’est en fait un plus car ils ont le budget et le métier.

Il était parfois les BRMS …

Laurent Magnin

Laurent Magnin – Photo : José Paumard

Présentée par Laurent Magnin, consultant senior chez In Fine, cette deuxième partie tombait à point nommée pour nous convaincre que dans la vraie vie, les applications aux BRMS sont multiples et intéressantes.

Laurent est détenteur d’un doctorat en Intelligence Artificielle, discipline qu’il a enseigné à l’université de Montréal avant d’être consultant JRules pour Ilog USA avant de revenir en France pour continuer à travailler sur d’autres projets impliquant des BRMS, avec JRules ou Drools.

Ex. 1 : Turbinage

Une compagnie de production d’aluminium ayant de gros besoin d’électricité, elle possède en règle générale un ou plusieurs barrages. Mais leur fonctionnement est complexe, fortement lié à la météo, au prix de l’électricité, etc … Le problème de la compagnie pour laquelle Laurent est intervenu était le départ en retraite des experts qui ont donc formalisé leur savoir pour permettre le pilotage et la prise de décision de ces barrages via un BRMS.

Ex. 2 : A la bonne température

Le chauffage de bâtiments dans un pays aussi froid que le Canada est un problème complexe, impliquant la connaissance de nombreuses règles métiers. Laurent nous fait remarquer que le technicien qui vient diagnostiquer un problème de chauffage ne se base pas sur ces règles, mais plutôt sur leurs cas d’utilisation. Il connait de nombreux cas “généraux”, mais retient surtout les solutions qu’il a appliqué aux cas particuliers : c’est le Case-Base Reasoning.

De là une initialisation avec des règles générales et des cas de départ qu’on exécute en simulation a été faite, puis adapté aux bâtiments. Le BRMS a fait office de technologie complémentaire permettant de faire parler les experts.

Ex. 3 : Money Money

La capitale du Nevada, Carson City, est une ville principalement occupée par les fonctionnaires … et les casinos ;) . Parmi ces fonctionnaires, ceux en charge de verser les pensions à la population devaient connaître un certain nombre de règles qui venaient “se superposer” les unes aux autres : la personne a-t-elle fraudé, quelle est sa situation familiale etc … rendant ce travail particulièrement complexe.

En effet dans la vie de tous les jours, les humains n’ont “pas de règles”, d’où la nécessité de se baser sur des cas concrets pour pouvoir élaborer ces règles, ce que Laurent résumera ainsi : “l’humain ne travaille jamais avec des règles, toujours avec des cas; et les cas permettent de tester les règles.”

Ex. 4 : Sans sucre

Dans une banlieue aisée de Boston où les cas de diabètes sont récurrents, la nécessité de diagnostiquer automatiquement les cas dans un domaine très sensible a amené à la création d’un ruleflow très affiné, afin de ne pas risquer de manquer un cas avéré. Le cheminement est parfaitement déterminé, chaque cas est évalué (âge, sexe, origine etc …) et le tout est réalisé en langage naturel avec des experts médecins.
Face au cas particulier de son patient, le médecin peut alors tracer le raisonnement qui a été suivi et prendre la décision particulière qui s’impose.

Ex. 5 – Faire son marché

Le cas d’une grande banque de marché française vient en opposition totale au cas précédent. Là où le cas médical est beaucoup testé avant d’être utilisé, le cas financier est tout de suite utilisé en production, quasiment sans test préalable, impératifs économiques obligent.

Cette banque disposait déjà d’un système qui connaissait des problèmes de maintenance et de performance, et c’est pourquoi, plutôt que de le refaire alors qu’il était devenu ingérable, Laurent a proposé l’utilisation d’un tableau décisionnel, a pu résumer 23 cas de demandes de prêt en un seul, tout en fournissant aux utilisateurs métiers un tableau de bord de type fichier excel, aisément compréhensible.

Fin de la première partie, direction la salle de pause où nous attend un buffet mauricien particulièrement alléchant, offert par Ippon :)

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer