Cours avec exemples sur le Framework Drools pour Java

Participez au vote ☆☆☆☆☆★★★★★

Cours PDF avec exemples sur le Framework Drools pour Java

Chapitre 1 Introduction

1.1. introduction

L'année écoulée a été occupée depuis la dernière version de la série 5.x. L'une des principales plaintes de la série 5.x concernait le manque de méthodologie de déploiement définie. Le mécanisme utilisé par Drools et jBPM était très flexible, mais trop flexible. L’objectif principal de la version 6.0 était de rationaliser les aspects construction, déploiement et chargement (utilisation) du système. La construction et le déploiement s'alignent maintenant sur Maven et l'utilisation est désormais axée sur la convention et la configuration, et non sur la programmation, avec une configuration par défaut pour minimiser la configuration. L'atelier a été entièrement reconstruit, inspiré d'Eclipse, pour fournir une solution flexible et mieux intégrée. avec des panneaux et des perspectives via des plugins. Le plan de travail de base a été transformé en un projet autonome appelé UberFire, de sorte que tout le monde peut désormais créer des établis de haute qualité basés sur le Web. À plus long terme, cela facilitera l'installation personnalisée de Drools et jBPM par l'utilisateur.

Git remplace JCR en tant que référentiel de contenu, offrant un stockage back-end rapide et évolutif pour le contenu bénéficiant d'une prise en charge puissante de l'outillage. Les bases de données ont été recentrées sur la simplicité, dans le but de stocker chaque signe sous forme de fichier texte, même les métadonnées ne sont qu'un fichier. La base de données est là pour fournir une indexation rapide et une recherche via Lucene. Cela permettra aux dépôts maintenant d'être synchronisés et publiés avec des infrastructures établies, comme GitHub. jBPM a été considérablement renforcé, grâce à l’acquisition de Polymita, avec des tâches manuelles, des créateurs de formulaires, des modélisateurs de classes, des serveurs d’exécution et une gestion de l’exécution. Tous entièrement intégrés dans le nouvel établi. OptaPlanner est maintenant un projet de premier niveau qui retient toute l'attention.

Un nouveau nom générique, KIE (Knowledge Is Everything), a été introduit pour rassembler nos technologies associées sous un même toit. C'est également le noyau partagé de nos projets. Attendez-vous donc à le voir souvent.

1.2. Être impliqué

On nous demande souvent "Comment puis-je participer". Heureusement, la réponse est simple: il suffit d'écrire du code et de le soumettre :) Il n'y a pas d'obstacles à franchir ni de poignées de main secrètes. Nous demandons une "surcharge" très minime pour permettre un développement de projet évolutif. Vous trouverez ci-dessous un aperçu général des outils et du "flux de travail" que nous demandons, ainsi que des conseils généraux.

Si vous faites du bon travail, n'oubliez pas de bloguer à ce sujet :)

1.2.1. Inscrivez-vous sur jboss.org

…

1.2.2. Signer l'accord de contributeur

Le seul formulaire à signer est l’accord de contribution, entièrement automatisé via le Web.

Comme le montre l'image ci-dessous "Cela établit les conditions générales de vos contributions et garantit que le code source peut être concédé sous licence de manière appropriée"

…

1.2.3. Soumission de problèmes via JIRA

Pour pouvoir interagir avec l'équipe de développement principale, vous devez utiliser JIRA, l'outil de suivi des problèmes. Cela garantit que toutes les demandes sont consignées et attribuées à un calendrier de publication et à toutes les discussions capturées au même endroit. Les rapports de bogues, les corrections de bogues, les demandes de fonctionnalités et les soumissions de fonctionnalités doivent tous être placés ici. Les questions générales doivent être posées sur les listes de diffusion. Les envois de code mineurs, tels que les corrections de format ou de documentation, n'ont pas besoin de créer un problème JIRA associé.

1.2.4. Fork GitHub

Avec l'accord de contributeur signé et vos demandes soumises à JIRA, vous devriez maintenant être prêt à coder :) Créez un compte GitHub et branchez l'un des dépôts Drools, jBPM ou Guvnor. La fork en créera une copie dans votre propre espace GitHub sur lequel vous pourrez travailler à votre rythme. Si vous faites une erreur, ne vous inquiétez pas, faites-la disparaître et fourchette à nouveau. Notez que chaque référentiel GitHub vous fournit l'URL de clone (paiement), GitHub vous fournira des URL spécifiques à votre fork.

1.2.5. Tests d'écriture

Lorsque vous écrivez des tests, essayez de les garder minimes et autonomes. Nous préférons conserver les fragments DRL dans le test, car cela permet une révision plus rapide. S'il existe un grand nombre de règles, l'utilisation d'une chaîne n'est pas pratique. Dans ce cas, placez-les dans des fichiers DRL distincts au lieu d'être chargées à partir du chemin d'accès aux classes. Si vos tests doivent utiliser un modèle, essayez d’utiliser ceux qui existent déjà pour d’autres tests unitaires. tels que personne, fromage ou ordre. S'il n'existe aucune classe contenant les champs dont vous avez besoin, essayez de mettre à jour les champs des classes existantes avant d'ajouter une nouvelle classe.

……

1.2.6. S'engager avec les conventions correctes

Lorsque vous vous engagez, veillez à utiliser les conventions appropriées. Le commit doit commencer par l'identifiant du problème JIRA, tel que JBRULES-220. Cela garantit que les validations sont référencées via JIRA afin que nous puissions voir toutes les validations pour un problème donné au même endroit. Après l’identifiant, le titre du problème devrait venir ensuite. Utilisez ensuite une nouvelle ligne, mise en retrait avec un tiret, pour fournir des informations supplémentaires relatives à ce commit. Utilisez une nouvelle ligne et un tiret supplémentaires pour chaque point distinct que vous souhaitez faire valoir. Vous pouvez ajouter des références croisées JIRA supplémentaires au même commit, si cela convient. En général, essayez d'éviter de combiner des problèmes non liés dans le même commit. N'oubliez pas de modifier votre base de données locale à partir du maître d'origine, puis repoussez vos commits vers votre base de données.

…

1.2.7. Soumettre des demandes de tirage

Avec votre code rebasé à partir du maître d'origine et poussé vers votre zone GitHub personnelle, vous pouvez maintenant soumettre votre travail sous forme de demande d'extraction. Si vous regardez le haut de la page dans GitHub pour votre zone de travail, il s'agira d'un bouton "Demande d'extraction". En sélectionnant cette option, vous obtiendrez une interface utilisateur pour automatiser la soumission de votre demande d'extraction.

La demande d'extraction est ensuite placée dans une file d'attente que tout le monde peut voir et commenter. Ci-dessous, vous pouvez voir une demande de tir typique. Les demandes d'extraction permettent les discussions et affichent tous les validations associées et les différences pour chaque validation. Les discussions impliquent généralement des révisions de code qui fournissent des suggestions utiles pour des améliorations et nous permettent de laisser des commentaires en ligne sur des parties spécifiques du code. Ne soyez pas découragé si nous ne fusionnons pas tout de suite, il peut souvent falloir plusieurs révisions avant d'accepter une demande d'extraction. Heureusement, avec GitHub, il est très facile de revenir à votre code, de faire d'autres commits, puis de mettre à jour votre demande d'extraction à la dernière et à la perfection. Nous pouvons avoir besoin de temps pour répondre aux demandes reçues, alors soyez patient. Les tests soumis accompagnant un correctif seront généralement appliqués assez rapidement, alors que de simples tests seront souvent utilisés jusqu'à ce que nous ayons le temps de le soumettre également avec un correctif. N'oubliez pas de redéfinir votre requête et de la soumettre à nouveau de temps en temps, sinon, il y aura des conflits de fusion et les principaux développeurs les ignoreront.

1.3. Installation et configuration (Core et IDE)

1.3.1. Installer et utiliser

Drools fournit un IDE basé sur Eclipse (facultatif), mais à la base, seul Java 1.5 (Java SE) est requis.

Un moyen simple de commencer consiste à télécharger et à installer le plug-in Eclipse. Pour ce faire, le framework Eclipse GEF doit également être installé (voir ci-dessous, si vous ne l'avez pas déjà installé). Cela vous fournira toutes les dépendances dont vous avez besoin pour commencer: vous pouvez simplement créer un nouveau projet de règles et tout sera fait pour vous. Reportez-vous au chapitre sur Rule Workbench et IDE pour obtenir des instructions détaillées à ce sujet. L'installation du plug-in Eclipse est généralement aussi simple que de décompresser un fichier dans votre répertoire de plug-in Eclipse.

L'utilisation du plug-in Eclipse n'est pas requise. Les fichiers de règles ne sont que des entrées textuelles (ou des feuilles de calcul, selon le cas) et l'IDE (également connu sous le nom de Rule Workbench) est simplement une commodité. Les gens ont intégré le moteur de règles à bien des égards, il n’existe pas de solution unique.

Vous pouvez également télécharger la distribution binaire et inclure les fichiers JAR pertinents dans le classpath de vos projets.

1.3.1.1. Dépendances et JAR

Drools est divisé en quelques modules, certains sont nécessaires lors du développement / de la compilation des règles, et certains au moment de l'exécution. Dans de nombreux cas, les utilisateurs voudront simplement inclure toutes les dépendances au moment de l'exécution, ce qui est bien. Cela vous permet d'avoir le plus de flexibilité. Cependant, certains préfèreront peut-être réduire leur "exécution" au strict minimum, car ils déploieront des règles sous forme binaire - c'est également possible. Le moteur d'exécution principal peut être assez compact et ne nécessite que quelques 100 kilo-octets sur 3 fichiers JAR.

Ce qui suit est une description des bibliothèques importantes qui composent JBoss Drools.

knowledge-api.jar - fournit les interfaces et les usines. Cela aide également à montrer clairement ce qui est conçu comme une API utilisateur et ce n'est qu'une API moteur.
knowledge-internal-api.jar - fournit des interfaces internes et des usines.
drools-core.jar: il s'agit du composant d'exécution du moteur principal. Contient à la fois le moteur RETE et le moteur LEAPS. Il s'agit de la seule dépendance à l'exécution si vous pré-compilez des règles (et déployez via des objets Package ou RuleBase).
drools-compiler.jar - contient les composants du compilateur / constructeur pour prendre la source de la règle et créer des bases de règles exécutables. Il s’agit souvent d’une dépendance de votre application au moment de l’exécution, mais ce n’est pas nécessairement le cas si vous pré-compilez vos règles. Cela dépend de bave-core.
drools-jsr94.jar - il s'agit de la mise en œuvre compatible JSR-94, il s'agit essentiellement d'une couche recouvrant le composant drools-compiler. Notez qu'en raison de la nature de la spécification JSR-94, toutes les fonctionnalités ne sont pas facilement exposées via cette interface. Dans certains cas, il sera plus facile d'accéder directement à l'API Drools, mais dans certains environnements, la JSR-94 est obligatoire.
drools-decisiontables.jar - il s'agit du composant 'compilateur' des tables de décision, qui utilise le composant drools-compiler. Cela prend en charge les formats d’entrée Excel et CSV.

Les composants ci-dessus requièrent beaucoup d'autres dépendances, dont la plupart concernent le module drools-compiler, drools-jsr94 ou drool-decisiontables. Certains points clés à noter sont "POI" qui fournit la capacité d'analyse de la feuille de calcul et "antlr" qui fournit l'analyse du langage de règles lui-même.

REMARQUE: si vous utilisez Drools dans J2EE ou des conteneurs de servlets et que vous rencontrez des problèmes de chemin de classe avec "JDT", vous pouvez passer au compilateur janino. Définissez la propriété système "drools.compiler":

Par exemple: -Ddrools.compiler = JANINO.

Pour obtenir des informations à jour sur les dépendances dans une version, consultez les POM publiés, disponibles dans le référentiel Maven.

1.3.1.2. Utiliser avec Maven, Gradle, Ivy, Buildr ou Ant

Les fichiers JAR sont également disponibles dans le référentiel central Maven [http: //search.maven.org/#search | ga | 1 | org.drools] (et également dans le référentiel JBoss Maven [/ index.html # nexus-search; gav ~ org.drools ~~~~]).

Si vous utilisez Maven, ajoutez les dépendances KIE et Drools dans le fichier pom.xml de votre projet, comme suit: