Oswald Regular
OpenSans Regular
Business Rules Environment

Ab Initio répond aux besoins d'un large panel d'utilisateurs. À une extrémité du spectre se trouvent les développeurs d'applications. Ils savent comment concevoir et créer des systèmes sophistiqués capables de traiter de grandes quantités de données dans des environnements complexes. À ces utilisateurs, Ab Initio propose le Graphical Development Environment (GDE) pour la création graphique de processus complexes et de logique métier. Les applications résultantes sont exécutées sur le Co>Operating System, un moteur extrêmement robuste et évolutif.

À l'autre extrémité du spectre Ab Initio se trouvent les utilisateurs métier. Ces personnes ne s'intéressent pas à la mécanique du traitement de téraoctets de données ou de milliers de messages par seconde et n'ont pas les compétences nécessaires dans ce domaine. Toutefois, elles savent parfaitement ce que leurs systèmes doivent accomplir et sont souvent les mieux renseignées sur les détails des données et les règles gouvernant l'entreprise.

Au fil des années, une pomme de discorde s'est formée entre les équipes informatiques et les utilisateurs métier dont elles s'occupent. Les utilisateurs métier connaissent l'objectif à réaliser et sa raison d'être pour l'entreprise, et les informaticiens savent comment procéder. L'équipe informatique requiert des spécifications qui sont généralement fournies par les utilisateurs métier. Mais les ambiguïtés et les erreurs sont inévitables : en particulier, des erreurs dans les spécifications et dans leur traduction en code. Le processus, consistant à passer des spécifications au code, au test, puis à la publication, ne fonctionne jamais aussi bien ni aussi rapidement que prévu. À chaque étape, des efforts d'interprétation sont requis. Ce processus est fastidieux et propice aux erreurs. Déceler chaque erreur, revoir les spécifications et modifier le code prend du temps. La productivité en pâtit. La justesse n'est jamais complètement garantie. Il arrive que le cycle ne converge jamais et que les projets n'aboutissent pas.

Les utilisateurs métier devraient donc contrôler les parties des systèmes qui implémentent leur logique métier. Les règles métier devraient être exprimées de manière à ce que ces utilisateurs puissent les comprendre et les écrire. Elles devraient également pouvoir être converties automatiquement dans le code d’un système plus large. Ce serait une solution idéale. C'est le concept du Business Rules Environment.

En effet, le Business Rules Environment (BRE) de la solution Ab Initio permet aux analystes métier de spécifier leurs règles sous une forme qui leur est familière, à savoir des feuilles de calcul tabulaires. Dans le BRE, les règles sont créées en termes métier, non techniques et avec des expressions connues des utilisateurs Microsoft Excel. Par conséquent, les règles peuvent être spécifiées rapidement et de manière précise, et elles sont mieux comprises par d'autres membres du personnel métier.

Par ailleurs, dans le BRE, les utilisateurs métier sont chargés de la vérification des règles métier. Ces utilisateurs peuvent insérer les règles directement dans le système et immédiatement en examiner le résultat sur des données de test. S'ils ne sont pas satisfaits, ils peuvent apporter toutes les modifications nécessaires. Le gain de temps est énorme.

Le Business Rules Environment d'Ab Initio n'est pas un outil isolé.

Les moteurs de règles classiques sont des outils autonomes. Ainsi, ils requièrent de nombreux efforts pour être en mesure de fonctionner avec d'autres produits et avec le reste de l'infrastructure informatique. Ils sont limités en termes de performances et d'évolutivité. Ils ne peuvent traiter que des structures de données simples. Leur perspective est réduite quant aux règles qu'ils acceptent, si bien qu'ils ne peuvent pas tracer le lignage dans des systèmes entiers.

En revanche, avec le BRE Ab Initio, tous ces problèmes et toutes ces limitations n'existent pas car le BRE fonctionne en étroite relation avec le Co>Operating System et avec les technologies de métadonnées. Il a été structuré et implémenté de cette manière. Ce n'est pas un produit de second ordre ajouté dans une optique de marketing, comme le font souvent de nombreuses entreprises informatiques.

  • Les règles du BRE peuvent être exécutées telles quelles dans des applications batch, continues, de services Web et en temps réel.
  • Les règles du BRE sont exécutées de manière extrêmement efficace et peuvent évoluer pour fonctionner sur plusieurs unités centrales et plusieurs serveurs. L'évolutivité des systèmes créés avec Ab Initio est sans limite.
  • Les règles du BRE peuvent traiter des données hiérarchiques existantes complexes. Tout ce qui peut exister dans un environnement hérité (notamment EBCDIC, packed decimal, formats internationaux, XML, Copybooks Cobol) peut être traité, en mode natif, par l'action conjointe du BRE et du Co>Operating System.
  • Les règles du BRE sont exécutées de manière semblable sur toutes les plates-formes proposées par le Co>Operating System (Unix, Linux, Windows, z/OS et z/Linux).
  • Le BRE bénéficie de toutes les fonctions de performances du Co>Operating System, notamment le traitement des erreurs et les points de reprise.

Qu'est-ce qu'une règle métier ?

Le BRE prend en charge trois différents types de règles métier : les règles d'aide à la décision, celles de validation et celles de mapping. Bien que ces règles soient fondamentalement similaires, les utilisateurs métier préfèrent les classer par catégorie.

En fonction du type d'entreprise, les règles peuvent être simples et brèves ou extrêmement longues et complexes. Le BRE peut aisément gérer ces deux extrêmes. Actuellement, les jeux de règles les plus importants du BRE comportent plus de 50 000 règles.

Voici l'exemple d'une règle métier de décision très simple dans le BRE. Il s'agit du calcul de l'impôt sur les revenus américain (formulaire 1040) :

Cette règle comporte deux entrées, Filing status (Statut marital) et Taxable income line 43, (Revenu imposable) et calcule un résultat unique appelé Tax (ligne 44). Dans le BRE, il existe un opérateur AND implicite entre les colonnes, et un opérateur ELSE implicite entre les lignes. Les premières lignes de cette règle sont les suivantes :

SI Filing status est Single ET Taxable income line 43 est inférieur ou égal à 100000, ALORS Tax (line 44) est le résultat de la recherche de Taxable income line 43 dans la table Tax from Table pour les contribuables de statut Single.

SINON SI Filing status est Single ET Taxable income line 43 est supérieur à 100000 et inférieur ou égal à 171550, ALORS Tax (line 44) est égal à Taxable income line 43 multiplié par 0,28 moins 6280.

SINON SI Filing status est Single ET Taxable income line 43 est supérieur à 171550, … …

… et ainsi de suite …

Voici maintenant un exemple de règle de validation. Elle permet de valider plusieurs entrées dans la même règle et définit plusieurs sorties dans chaque cas :

Voici enfin un exemple de règle de mapping d'une source vers une cible. Pour ce type de règle, le BRE affiche à gauche une liste des valeurs d'entrée potentielles (colonne "Entrées") telles que les champs, les variables, les constantes et les valeurs calculées. Au centre, se trouve une liste de champs cible (colonne "Nom de sortie"). À droite de chaque champ cible se trouve une colonne ("Expression/Règle") dans laquelle l'utilisateur peut faire glisser des valeurs de la colonne "Entrées" ou créer une expression pour calculer ce résultat. (La colonne "Valeur obtenue" sera expliquée par la suite.)

Les règles du BRE peuvent inclure une logique arbitrairement complexe.

La logique des règles du BRE peut être simple, comme dans les exemples précédents. Or, dans la réalité, les utilisateurs métier ont souvent affaire à des règles complexes. Avec des technologies non-Ab Initio, ces règles ne peuvent pas être implémentées dans le produit des règles métier. Elles requièrent, à la place, un codage manuel dans des langages de programmation tels que C++ ou Java. L'utilisabilité et la productivité peuvent en être considérablement affectées. Nous revenons ainsi au cycle néfaste spécification-interprétation-code-test-correction, vouant les projets à l'échec.

Il n'en va pas de même avec le BRE Ab Initio qui bénéficie entièrement des capacités de traitement du Co>Operating System. Autrement dit, les centaines de fonctions du Co>Operating System sont exploitables dans le BRE, ainsi que les structures de logique complexe.

Il n'existe, par conséquent, aucune limite de taille ni de complexité des règles et des expressions au sein de ces règles. De même, le nombre de règles d'un jeu de règles est illimité.

La fonctionnalité de test intégrée permet aux utilisateurs métier de vérifier eux-mêmes les règles.

Un avantage clé de l’utilisation du Business Rules Environment Ab Initio pour le développement de règles métier est la fonctionnalité de test intégrée du BRE : les règles développées au sein du BRE peuvent être exécutées sur des données de test sans jamais quitter l'environnement d'édition. Pendant les tests, le BRE indique les résultats obtenus pour chaque enregistrement ainsi que les états de chaque variable et calcul intermédiaires. Un utilisateur du BRE peut vérifier les enregistrements de sortie, puis cliquer sur une des valeurs obtenues pour savoir exactement comment cette valeur a été calculée et pourquoi :

Pour chaque enregistrement de test, le BRE affiche le ou les cas qui se sont déclenchés (en jaune), et assombrit également les cellules dont la comparaison a échoué. Le BRE calcule également le nombre de déclenchements d'une règle ("Nombre d’activations" dans la capture d'écran). Ces informations peuvent servir à trouver les cas de test manquants ou les règles mal construites (si un cas ne se déclenche jamais).

Les tests de création peuvent être pratiqués à tout moment au cours du développement des règles, permettant ainsi une approche incrémentielle pour les jeux de règles de large envergure. Il est inutile d'attendre que toutes les règles soient entrées pour commencer à en évaluer le comportement.

Les résultats d'un test peuvent être enregistrés comme référence pour une comparaison automatique lors de prochains tests. Lorsque les règles sont modifiées, au cours du développement ou à la conception des modifications, toutes les différences de comportement entre les règles modifiées et les résultats de référence pourront être identifiées. Cette fonction est primordiale pour évaluer l'impact d'une modification. Sans le BRE Ab Initio, les utilisateurs métier opèrent souvent au hasard lorsqu'ils modifient leurs règles.

En outre, les détails de l'exécution des règles sont également disponibles dans les jeux de règles exécutés en production. Les utilisateurs peuvent définir le degré d'informations de suivi à enregistrer. Ces informations peuvent être limitées aux cas de règle (ou lignes) déclenchés pour chaque valeur d'entrée ou contenir toutes les valeurs : celles d'entrée, de référence, mais aussi les valeurs intermédiaires et finales. Cela permet aux analystes d'étudier le comportement des règles au fil du temps, ce qui conduit souvent à des améliorations des résultats grâce à l'ajustement de la logique métier. Ces détails peuvent également se révéler indispensables pour mieux comprendre certaines décisions prises par le passé.

Transparence : la logique métier enfin dévoilée

Les systèmes embarquant des règles métier complexes et de grande envergure peuvent comporter de nombreuses règles ayant été implémentées sur la base d'autres règles. Pour les utilisateurs métier, il est indispensable de comprendre comment ces règles sont liées et de quelle manière les données évoluent entre les règles. Malheureusement, il est très rare que ces utilisateurs puissent examiner comment fonctionnent leurs systèmes.

En revanche, avec le BRE, les utilisateurs métier bénéficient d'une visibilité totale de leurs systèmes. En effet, le transit des données dans les règles interconnectées, indépendamment de la taille et de la complexité de ces règles, est représenté sous forme de diagramme. En outre, le lignage graphique peut s’afficher pour les applications comportant de nombreux jeux de règles susceptibles d'être répartis sur l'ensemble d’une application, voire plusieurs.

La figure suivante représente un exemple de lignage simple du jeu de règles illustré plus haut, qui calcule les impôts sur le revenu d'après le formulaire américain 1040 EZ. Les blocs ovales verts représentent les règles (calculs) et les blocs rectangulaires à angles arrondis correspondent aux variables. En mode de test, les valeurs d'essai apparaissent sous chaque nom de variable, avec tous les calculs intermédiaires. Au-dessous du schéma de lignage complet se trouve une section agrandie montrant dans quelle mesure le calcul des charges déductibles (ligne 5) influence le remboursement ou le montant dû final.

La fonctionnalité de lignage du BRE permet aux utilisateurs métier de bien comprendre le fonctionnement des grands jeux de règles complexes.

Absence de l'algorithme de RETE

Qu'est-ce que RETE ? Avec le BRE, il est inutile de le savoir. Avec les produits classiques, cependant, les règles sont exécutées selon un ordre déterminé par « l’algorithme de RETE ». Cela signifie qu'une personne métier doit comprendre un concept relativement complexe d’informatique/intelligence artificielle (reportez-vous à http://fr.wikipedia.org/wiki/Algorithme_de_Rete pour une définition en français ou à http://en.wikipedia.org/wiki/Rete_algorithm pour une définition plus complète en anglais).

Dans la pratique, il est particulièrement difficile de comprendre les conséquences des modifications apportées à une règle lors de l'utilisation de la méthode RETE, dans la mesure où une règle peut avoir un impact sur d'autres règles se trouvant très loin dans les spécifications. Les performances sont également très difficiles à ajuster, étant donné que de simples changements peuvent avoir des conséquences importantes et inattendues.

Dans le BRE, les règles sont exécutées dans l'ordre que vous avez spécifié. Les performances sont nettement supérieures et elles sont prévisibles. Les règles sont faciles à comprendre pour les utilisateurs métier.

Comment fonctionne le BRE avec le Co>Operating System ?

Ce fonctionnement est simple. Le BRE prend les règles créées par l'utilisateur et les place dans un composant d'un graphe exécuté par le Co>Operating System. Des informations supplémentaires sur les composants, les graphes et le Co>Operating System sont disponibles sur ce site.

Les règles métier étant exécutées dans le Co>Operating System, elles bénéficient de toutes ses fonctionnalités. Elles fonctionnent avec tout type de données source ou cible, indépendamment de leur volume. Elles peuvent être exécutées en mode batch et/ou en temps réel, de manière répartie sur plusieurs serveurs exécutant eux-mêmes des systèmes d'exploitation différents, le tout avec une grande fiabilité. Le Co>Operating System dispose de toutes les fonctionnalités nécessaires pour créer et exécuter des applications stratégiques robustes. Le BRE hérite de toutes ces qualités.

Voici un exemple de graphe (application) du Co>Operating System dans lequel un composant clé contient des règles spécifiées avec le BRE :

Gestion et gouvernance complètes des règles

Toutes les règles sont stockées dans l'Enterprise Meta>Environment (EME) de la solution Ab Initio, qui est doté de fonctionnalités de gestion du code source, y compris le contrôle de version. Par conséquent, les utilisateurs du BRE ont le choix entre deux méthodes de déploiement :

  • Considérer les règles comme d'autres éléments de l'application. Cela signifie qu'elles doivent passer par toutes les étapes de promotion de code standard : développement, test et enfin promotion vers l'environnement de production. Bien que cette méthode efficace n'ait aucun secret pour les développeurs informatiques, le nombre d'étapes risque de prolonger la procédure. Néanmoins, les tests intégrés du BRE rationalisent et raccourcissent l'ensemble du processus.
  • Considérer les règles comme des données de code de référence dans une base de données opérationnelle. Les utilisateurs métier sont souvent en mesure d'apporter des modifications (ajouts, mises à jour et suppressions) à des codes de référence sans les exécuter dans l'ensemble du processus de promotion du code d'application, ce qui leur permet de répondre rapidement aux besoins de l'entreprise.

Ab Initio ne privilégie pas de méthode particulière ; nous permettons simplement à nos utilisateurs de choisir l'approche la plus adaptée à leurs besoins.

Enfin, dans la mesure où l'EME permet un contrôle de version robuste, les utilisateurs peuvent facilement configurer leur environnement pour permettre le déploiement de règles de type "champion / challenger". Le principe consiste à exécuter deux versions des mêmes règles côte à côte afin de comparer et de différencier leurs résultats. Les utilisateurs déterminent ensuite des processus visant à examiner ces différences et à améliorer leurs règles jusqu'à l'obtention des résultats escomptés.

Harmonisation de l'entreprise grâce à une technologie unifiée

Grâce à des tests intégrés interactifs et à la création automatique de modules exécutables prêts pour la production, le BRE permet aux utilisateurs métier de participer directement au développement des applications en venant compléter l'expertise du personnel informatique. En présentant la logique métier de telle sorte que les utilisateurs métier puissent l'exprimer et la comprendre, le BRE élimine les risques et l'incertitude généralement associés au développement et au déploiement de nouvelles applications.

Les règles du BRE et les applications qu'elles pilotent sont exécutées par le Co>Operating System, ce qui signifie qu'elles peuvent être très complexes, tout en maintenant d'excellentes performances d'exécution et une complète évolutivité. Les mêmes règles peuvent être exécutées dans des applications batch et dans des applications de services Web, sans recodage. Tous les avantages du Co>Operating System transparaissent dans le BRE. En effet, le BRE a été conçu avec la même technologie unifiée que celle du Co>Operating System. Le BRE et le Co>Operating System participent ensemble à harmoniser l’entreprise, de manière transparente.

English
Langue :
Français
Español
Deutsch
简体中文
日本語