urbanisation-si

urbanisation-si

Moteur de règles


BRMS Moteur de règles : mais que fait IBM ?

BRMS-moteur-de-règles-IBM-ODM-1.jpg

En tant qu'urbaniste, j'ai été amenée à travailler avec les BRMS ou moteurs de règles.

Mon premier contact a tout d'abord été avec jRules de l'éditeur français ILOG, puis avec l'open source DROOLS de Red Hat  jBoss  et enfin avec IBM ODM (Operational Decision Manager), anciennement IBM WebSphere ILOG Rules for COBOL, IBM ayant racheté il y a quelques années ILOG pour absorbé son produit phare jRules et le renommer. 

Alors que peut-on dire de ce mastodonte ?

En premier lieu il faut signaler que IBM ODM = ILOG JRules (stateless) + IBM Business Event (stateful). Une des grandes nouveauté est l'intégration de la corrélation d'évènements comme le fait d'ailleurs son concurrent open source DROOLS.

Le moteur de règle d’ODM 8.5 est le même quelque soit l’environnement (zOS, Linux, Windows) et est écrit en Java. C’est le moteur d’origine ILOG JRules. 

Des optimisations ont été faites :

  • L’introspection a été remplacé par un compilateur natif Java qui compile les classes en code natif 
  • Le moteur s’auto tune (factorisation, principe de la compilation just in time)

Le moteur (full Java) et les règles (Java) s’exécutent dans une JVM, 3 solutions possibles :

  1. Stand alone zRES, solution la plus performante
  2. Celle de WAS z/OS avec le framework WOLA, solution la plus confortable, offrant le plus de fonctionnalités
  3. Celle de CICS 

Remarque : la solution 2 (WAS z/OS WOLA) est la solution retenue pour intégrer Drools à CICS/COBOL

Avec ODM, il n’y a plus de COBOL généré (le produit JRules for COBOL a été complètement abandonné !) car il fallait recompiler le COBOL généré ! Il n’y plus qu’un seul produit ODM. Les 2 produits « IBM ILOG JRules for COBOL » et « for Java » ont donc fusionné. Le moteur est un JAR avec du byte code standard. Le code compilé des règles par ODM est factorisé et optimisé.

Ce qui m'a "scotché", c'est l'intégration dans IBM ODM du module Rules for Office permettant d’écrire les règles avec Excel ou Word en proposant un ensemble de macros.

Le Decision Center Repository permet entre autre la synchronisation des versions. La modification d’une règle par l’expert métier stockée dans le Repository sera répercutée au développeur au moment ou il se synchronisera. Ceci est Identique à Drools (IBM Decision Center Repository = JBoss Guvnor). 

ODM possède un outil de vérification de cohérence de règles (règles qui ne peut pas s’exécuter, inclusion d’une règle dans une autre, …).

Mon avis sur IBM ODM zRES est que le coût de la licence reste chère, on est dépendant vis-à-vis d’IBM et pour le mainframe avec l'intégration de COBOL, il faut acheter un processeur spécifique zAAP, donc encore des coûts supplémentaires.

Par contre IBM a tout misé sur les outils pour la MOA permettant vraiment de rédiger les règles avec le vocabulaire métier. Evidemment c'est la meilleure solution d’intégration pour les batchs COBOL et les programmes CICS. 

Se lancer avec un outil propriétaire présente toujours les inconvénients de devenir esclave de l'éditeur et de mettre la main au porte monnaie régulièrement mais pour ceux qui n'aiment pas mettre les mains dans le cambouis, les risques techniques seront mieux maîtrisés.

 

"Il est extrêmement rare que la montagne soit abrupte de tous côtés."
André Gide

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


27/05/2015
0 Poster un commentaire

Comment concevoir une règle ?

regle-metier.jpg

Pour concevoir directement une règle, l’expert métier peut utiliser différents outils, suivant le type de règles :
1. L’assistant de conception de règles (BRL = Business Rule Language)
2. Le DSL (Domain Specific Language)
3. Une table de décision avec un tableau Excel

Les tables de décisions

. Une table de décision est simple et lisible (avec une approche classique, l’implémentation n’est pas jolie)
. Si on devait développer en Java l’équivalent cela prendrait au minimum 10 jours. Les ajouts ou modifications vont conduire à un code rapidemant inextricable et et inmaintenable, figé, non évolutif et non réutilisable. La documentation technique va être très complexe.
. D’autre part dès qu’on commencerait à ajouter des colonnes, cela deviendrait vite une « usine à gaz » inmaintenable.
. Les experts métier sont familiarisés avec Excel
. Les experts métier peuvent fixer eux-mêmes les valeurs des algorithmes sans l’assistance à temps plein d’un développeur
. L’implémentation (en Excel) est proche de la spécification fonctionnelle (très souvent elle aussi en Excel)

. L’expert métier utilise un modèle de table de décision (sous Excel) à partir du référentiel ou de la DSI
. Il saisit les valeurs des conditions et des actions
. Le développeur récupère la table de décision
. Il met en place des tests
. Il effectue éventuellement des modifications sur la table qu’il fait valider par l’expert métier
. L’expert métier peut ajouter de nouvelles règles dans la table de décision

 

Voir aussi :  http://urbanisation-si.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://urbanisation-si.eklablog.com/

http://bonnes-pratiques-si.eklablog.com/

http://rhonamaxwel.over-blog.com/


21/09/2014
0 Poster un commentaire

Qui fait fonctionner un moteur de règles ?

règle-métier.jpg

La mise en place d’un moteur de règles requiert la collaboration étroite entre 3 grands types d’acteurs : l’expert métier, le développeur de règles, l’administrateur du moteur de règles.

L’expert métier : 

  • Définit le modèle de règles en collaboration avec l’administrateur du moteur de règles 

  • Conçoit les règles selon le modèle défini, si elles répondent aux critères définis par l’administrateur (granularité, complexité, style, correspondance avec un modèle, table de décision, …)  

    • Si une règle ne correspond pas aux critères, elle devra être écrite par le développeur 

  • Effectue les tests unitaires  

Le développeur de règles : 

  • Injecte le modèle métier (classes Java JAR) dans le référentiel des règles (Guvnor)  

  • Conçoit le langage métier (DSL = Domain Specific Language) qui servira à l’expert métier pour écrire ses règles 

  • Conçoit, réalise et teste :  

    • les classes Java à partir du modèle de données métier MEGA 

    • le composant générique pour lancer le moteur de règles 

    • les fonctions utilitaires (conversions, …) et les formules de calculs (l’expert métier peut écrire des fonctions et des expressions) 

    • ajouter des « import » de packages et des variables globales 

    • le DSL 

    • les modèles de règles à destination des experts métiers  

    • les tables de décision à destination des experts métiers 

  • Teste les règles écrites par l’expert métier, à l’aide de scénarios  (valeurs en entrée et valeurs attendus), ainsi que les tests de non régression 

  • Met à jour les règles (versionning) et gère les impacts d’une modification du modèle métier 

    • Méta-modèle, généricité (code, libellé, valeur, type, …) 

  • Ordonnance les règles (rule flow ou processus avec un BPM=  Business Process Management) 

  • Conçoit le service technique pour le lancement du moteur de règle  

L’administrateur du moteur de règles : 

  • Etablit une méthode et la fait valider par le Métier 

    • Périmètre 

    • Modèle de règles 

  • Définit la granularité des objets 

    • Objets spécifiques ne contenant que les données nécessaires au moteur de règles 

  • Définit le passage par lots (1 ou plusieurs objets avec leurs grappes par ex. un dossier et ses dossiers liés) 

    • Ex : IHM du traitement d’un sinistre, traitement batch de plusieurs sinistres…  

  • Réalise une 1ère itération de l’application avec les développeurs… 

  • … puis une 2e itération avec le métier et les développeurs (ajout de nouvelles règles)  

Retour d'expérience : pendant la 1ère itération, les développeurs doivent implémenter les règles dans le langage technique du moteur puis dans les itérations suivantes on communique  la méthode mise au point comprenant la structure et les granularités des règles aux experts métier pour qu'ils se lancent à leur tour dans l'aventure.

Voir aussi :  http://urbanisation-si.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://rhonamaxwel.over-blog.com/


20/09/2014
0 Poster un commentaire

Quand faut il utiliser un moteur de règles ?

moteur-de-règles.gif

Un moteur de règles contribue aux objectifs de l'urbanisation des SI qui sont d'augmenter la flexibilité et l'évolutivité de l'entreprise en permettant d'ajouter de nouvelles règles métiers à moindre coût. Doit on intégrer à tout prix un moteur de règles, existe-t-il des raisons qui justifient son emploi ou au contraire y a-t'il des situations ou c'est fortement déconseillé ?

Quels sont donc les cas ou l'utilisation d'un moteur de règles est recommandée ? 

. Pour un problème simple qui sera résolu usuellement avec de la cuisine/bricolage algorithmique 

. Un problème trop difficile à résoudre avec des algorithmes traditionnels 

. La logique métier  change fréquemment 

. Les experts fonctionnels doivent modifier les règles dynamiquement 

Et quels sont ceux ou c'est déconseillé ? 

. Petit projet  (quelques dizaines de règles) 

. La logique métier est bien défini et change rarement 

. Les règles sont simples et peuvent être  contenu dans un même objet métier 

. La performance est la principale inquiétude (règles et faits sont en mémoire !) 

. Pas de ressources (temps et budget) pour former les  développeurs 

Que peut on espérer comme Bénéfices ? 

. Mise à disposition d’un référentiel de connaissances (règles) permettant de rechercher facilement une règle, la modifier, l’archiver et créer de nouvelles règles 

. Intégration de nouvelles règles plus rapide et plus facile  

. Accroissement de la rapidité de développement de nouvelles fonctionnalités 

. Réutilisabilité 

. Évolutivité  

. Maintenabilité 

Mais comme rien n'est jamais parfait, quels sont les points d’attention ? 

. L’organisation du travail doit être modifiée 

. Les développeurs doivent connaître la technologie 

. Les experts métiers doivent se familiariser avec de nouvelles méthodes de travail et de nouveaux outils 

Il y a pléthore d'offres de moteurs de règles open source ou commerciales qui ont fait leurs preuves avec de nombreux retours d'expérience couronnés de succès. Si vos activités sont sujettes à des fréquents changements alors tentez l'innovation et lancez vous dans l'intégration d'un moteur de règles. 

Voir aussi :  Les bonnes pratiques des SI

Le blog de Rhona Maxwel


19/09/2014
0 Poster un commentaire

Les étapes d’un projet avec un moteur de règles

BRMS.gif

Utiliser un moteur de règles (BRMS Business Rules Management System) va dans le sens de l'urbanisation des SI dont l'objectif est de rendre le SI flexible et évolutif. Mais quelles sont les étapes à réaliser pour mettre en œuvre un moteur de règles ?

La première étape est la phase de conception qui consiste à : 

. paramétrer le moteur de règles 

. définir les concepts métier (diagramme de classes UML) et le langage utilisé pour les règles 

. définir les objets physiques et les liens avec le modèle métier 

. définir le modèles de règles 

La deuxième étape consiste à écrire les règles par l’équipe de développement dans un premier temps puis par l’expert métier ensuite, à tester les règles et à les valider. 

La troisième étape représente la phase de maturité. On met en place les processus de  modification, ajout  et suppression de règles. On s'appuie sur des données existantes dans le SI. L’utilisateur métier est autonome. Si le modèle de données évolue alors l’intervention de l’équipe de développement est alors nécessaire. 

La quatrième étape a pour but d'intégrer le moteur dans l'application avec par exemple l'utilisation native du langage Java, l'Intégration dans l’architectures cible choisie (COBOL ou Java). 

Les prérequis et contraintes sont : 

. la couche d’objets « métier » doit être suffisamment stable avant d’écrire les règles. 

. les première phases d’écriture de règles sont à réaliser par un développeur, puis le transfert doit être progressif vers l’utilisateur « métier ». 

Le point critique d’un projet BRMS concerne le développement de tout ce qui va être exposé aux utilisateurs « métier », c’est à dire : 

. le langage « métier » utilisé,  

. l’élaboration de modèles et d’autres fonctions connexes comme des tests de non-régression ou des aides au débogage.  

. la criticité vient principalement du niveau technique des utilisateurs « métier » concernés. 

Si trop de liberté est laissée et que les utilisateurs ne sont pas assez formés, le système peut devenir instable, incompréhensible et donc ne pas remplir du tout ses objectifs d’amélioration de d’évolutivité du système, les utilisateurs ayant systématiquement besoin de l’assistance de l’équipe informatique. 

À l’inverse, si le système est trop contraint, les utilisateurs ne pourront pas forcément exprimer toutes les règles qu’ils souhaiteraient. Dans ce cas, soit les utilisateurs cessent d’utiliser le système, soit les demandes à l’équipe informatique se multiplient. 

Un bon conseil, n'hésitez pas à réaliser un POC avec comme objectifs de concevoir la méthode, les modèles et la granularité des règles, de former quelques développeurs et experts métiers, de communiquer avec pédagogie à l'ensemble des acteurs projet y compris la direction générale et la DSI.  Puis faites une première itération ou seul les développeurs vont écrire les règles. Les processus d'intégration, d'exploitation, de tests et de cycle de vie des règles doivent être validés. Profitez-en pour mesurer les temps de développement et autres charges pour affiner votre retour sur investissement. 

Voir aussi :  Les bonnes pratiques de SI

Le blog de Rhona Maxwel


18/09/2014
2 Poster un commentaire


Recherche

Vous recherchez ? :