Pendant un certain temps les moteurs de règles étaient fortement dépendant des fournisseurs de solution. Mais depuis que le standard DMN pour Decision Model and Notation est maintenant disponible l’ensemble des éditeurs Opensource ou Closesource fournisse une implémentation de ce standard. Nous allons voir avec un exemple rapide comment utiliser DMN.

Le standard DMN, un KYC en exemple

Introdution

DMN est une norme de l’OMG. Cette norme a pour objectif de standardiser la modélisation et le référentiel des règles de décision dans les applications ayant des besoins de scoring, d’évaluation et/ou d’aide à la décision.

La norme se propose de faciliter le développement des règles avec des patterns de règles bien connues, comme par exemple les tables de décision. Elle propose un langage de programmation standardiser appelé FEEL Friendly Enough Expression Language. Ce langage se veut très proche des macros Excel, facilitant l’appropriation du DMN par des équipes métiers.

DMN est aussi une norme d’éléments graphique. Chaque élément graphique correspond à un pattern qui possède des entrées, un traitement et une sortie. Les éléments graphique sont reliés entre eux dans un arbre de dépendance d’exécution des règles. Au fur et à mesure de l’exécution des règles on opère une réduction du nombre d’élément pour arriver au dernier élément qui contiendra la décision finale.

Le standard DMN est disponible en suivant le lien : http://www.omg.org/spec/DMN/1.0/

TCK

Il existe un outil en ligne listant l’ensemble des implémentation actuellement disponible et leur degré de maturité.

https://dmn-tck.github.io/tck/

Un Exemple : KYC

Dans notre exemple nous allons procéder à l’évaluation d’un nouveau client bancaire. Ce processus d’évaluation est communément appeler KYC pour Know Your Customer. Ce processus va calculer un score en fonction de données en entrée. Le score sera par la suite interprété par le conseiller bancaire afin accepter ou pas le nouveau client dans son fichier. Il se peut que la note du score nécessite simplement l’approbation à un niveau supérieur.

Les Input

Afin de pouvoir calculer le score il est nécessaire d’avoir les inputs. Pour cela nous allons avoir besoin de trois entrées :

1. PEP
   • Pour Political Exposed People
   • de type boolean
2. Amount
   • Pour la quantité de son apport
   • de type number
3. Fiscal Residency
   • Pour la localisation de sa résidence fiscal
   • de type string

Dans le contexte DMN il suffit simplement d’utiliser le type de box suivantes :

Il est bien sûr possible de définir des types d’entrée plus complexe.

Les Decision

Le principal élément du DMN est le concept de Decision. Cette Decision va calculer un résultat en fonction d’une ou plusieurs entrée. On utilise pour cela les box suivantes dans le modeleur.

On lie ensuite les Input avec les Decision

Ensuite, il est possible de lier les Decision entre elles, afin de remonter les sorties des premières Decision dans une autre Decision

Ici Input PEP est utilisé par la Decision PEP Rule, qui sera lui utilisé dans la Decision KYC.

Type de décision

1. Literal expression
   • Il s’agit d’une formule/code FEEL
   • par ex : A - B, SUM(A, B, C)
   • ex:
2. Decision Table
   • Il s’agit d’une liste de règle métier qui seront exécutées
   • ex:
3. Context
   • Il s’agit d’une liste de variables associées à des valeurs
   • Chaque valeur de la liste peut etre le resultat d’une Literal expression, d’une Decision Table ou d’une BKM.
   • ex:

Les Business Knowledge Model

Les Business Knowledge Model fournissent au modeleur la possibilité de réutiliser des briques logiques. Pour un développeur, les BKM peuvent être vues comme des fonctions réutilisable dans une ou plusieurs Decision, notamment car elles s’appellent directement dans les Decision et qu’elles possèdent des paramètres d’entrées.

Comme pour les Decision il existe trois types de BKM.

Dans notre cas nous allons utiliser une Decision Table pour calculer le score pour chaque règle.

On relie ensuite le BKM avec la Decision

Result

C’est la Decision KYC qui va contenir le résultat de ce petit moteur de règle. Dans notre cas, nous faisons la somme des trois appel à la BKM Level de chaque retour des Decision rule. Bien sur, cette fonction peut être plus ou moins compliquée car elle utilise le langage de programmation FEEL (Friendly Enough Expression Language). Il s’agit d’un langage qui ressemble un peu aux macros Excel.

Pour résumer, les Input sont donc utilisés dans les Decision, ces Decision sont reliées à des BKM ou bien d’autres Decision qui au fur et à mesure se termine vers une seule Decision. Comme on l’a vue précédemment, la Decision finale peut avoir plusieurs type de retour. Par convention on partira du bas pour les Input puis étage par étage on empilera les Decision jusqu’à les réduire en une seule.

Conclusion

J’espère que cette brève introduction à DMN vous aura convaincu de l’utiliser dans vos projets de moteur de règles. Le fait de standardiser les spécifications du moteur de règles permettra par exemple de pouvoir changer de fournisseur de moteur de règle. En fonction des fournisseur, une documentation peut être automatiquement générée facilitant le fond documentaire des projets et l’interaction avec les analystes business.

Nous verrons dans un prochain post comment exécuter le moteur de KYC.

Vous pouvez voir directement le resultat du DMN avec cet éditeur en ligne