Définition d'une hiérarchie de projets
Vous créez une hiérarchie en établissant les interdépendances des projets. Utilisez des hiérarchies de projets de règles afin de séparer et partager les règles et le BOM entre différents projets, d'autant plus que votre application devient plus complexe. L'utilisation de différents projets de règles permet de faciliter la maintenance, de tester de manière indépendante les différents composants de la logique et d'organiser divers points de décision. Vous pouvez ensuite configurer les projets pour qu'ils se référencent mutuellement.
Organiser la structure des projets de règles
Les services de décision sont conçus pour faciliter la création de la structure de projet. Lorsque vous créez un service de décision, vous créez un projet de règles principal tenant lieu de premier niveau dans la hiérarchie des projets de règles. Si le projet contient de nombreuses règles, vous devez créer d'autres types de projets afin de grouper ces règles par domaine ainsi que pour stocker le BOM. Ensuite, vous définissez les interdépendances des projets. Tous les projets référencés directement ou indirectement par le projet principal deviennent partie intégrante du service de décision. Par exemple, un projet de décision principal peut référencer deux projets de règles standard, qui à leur tour font tous deux référence à un projet qui contient le BOM. Ensemble, les quatre projets forment alors le service de décision.
- Sélectionnez Projet de règles principal pour créer un projet constituant le point d'entrée du service de décision et qui peut faire référence à d'autres projets.
- Sélectionnez Projet de règles standard afin de créer un ou plusieurs projets en vue d'y stocker vos règles.
- Sélectionnez Projet de règles avec un BOM afin de créer un projet pour y stocker le BOM.
Il est possible de modifier le type d'un projet pour le transformer en projet principal ou inversement, dans . Lorsqu'un projet de règles n'est pas référencé par un autre projet, vous pouvez le changer en projet de règles principal. Le changement d'un projet peut nécessiter certains changements dans le mode de référencement mutuel des projets et avoir une incidence sur le déploiement et la synchronisation du projet.
Dans Rule Designer, de nombreuses opérations sont effectuées au niveau du service de décision, telles que la génération, les requêtes, la restructuration et l'extraction d'ensemble de règles. En conséquence, le fait de grouper les projets de règles dans des services de décision séparés limite la portée de ces opérations.
Le diagramme suivant montre une organisation possible pour les projets de règles d'un service de décision. Le projet principal contient un flux d'exécution de règles qui utilise des règles de projets de la hiérarchie, ces derniers partageant un BOM conservé dans un projet à part. Les quatre projets font tous partie du même service de décision, car les projets de règles 2, 3 et 4 sont référencés directement ou indirectement par le projet de règles principal.
Organiser la structure des projets pour plusieurs ensembles de règles
Si l'application client appelle différents points de décision, vous devez organiser votre structure de projets pour plusieurs ensembles de règles.
Si une opération et ses règles nécessitent seulement une partie du BOM, vous pouvez conserver ces règles et cette partie du BOM dans une hiérarchie de projets de règles distincte, spécifiant le vocabulaire utilisable dans ces règles. Un BOM de grande taille peut nuire à la facilité d'emploi et aux performances. Pour réduire le nombre d'entrées dans les éditeurs de règles et les rendre plus pertinentes pour vos règles, utilisez des catégories afin d'organiser votre vocabulaire en sous-ensembles.
Vous pouvez empaqueter toutes les opérations de décision, flux d'exécution et règles dans le même service de décision. Le diagramme suivant montre un service de décision conçu pour distribuer les points de décision dans des projets de règles distincts. Il présente également une stratégie pour diviser le BOM pour plus d'efficacité.
