Règles dans les applications Pega
Lorsque vous jouez aux échecs, vous et votre adversaire convenez de respecter un ensemble précis d’instructions. Ces instructions régissent le jeu, notamment la façon dont chaque pièce se déplace sur l’échiquier. Par exemple, lors de son premier mouvement, le pion peut avancer d’une ou deux cases. Ces instructions de base constituent les règles des échecs.
De même, lorsque vous modélisez un type de dossier (Case Type) dans une application Pega Platform™, vous devez configurer l’application avec des instructions pour créer, traiter et clôturer un dossier (Case). Ces instructions constituent les règles (Rules) du type de dossier.
Les règles sont les composants de base d’une application Pega, que l’équipe projet peut configurer pour créer une solution métier pour l’organisation cliente et ses propres clients. Pega Platform utilise des règles pour générer du code d’application Java en arrière-plan. Les applications Pega Platform contiennent de nombreux types de règles qui spécifient différents types de comportement d’application. Les règles sont flexibles et réutilisables, ce qui permet à l’équipe projet de concevoir des fonctionnalités d’application plus efficacement pour les implémenter dans plusieurs types de dossier et applications.
Dans cette rubrique, vous allez examiner les règles plus en détail.
Création de règles automatisée dans App Studio
L’approche low-code de Pega permet aux utilisateurs d’effectuer une grande partie du travail de conception d’une application dans App Studio, en particulier au début du processus de développement. Avec l’ajout d’une automatisation des workflows dans App Studio, Pega Platform crée et gère automatiquement les règles sous-jacentes dans Dev Studio. Par exemple, lorsque vous configurez un type de dossier (Case Type) dans App Studio, vous utilisez le Case Life Cycle Designer et les volets de configuration (configuration panes) pour ajouter une vue (View) à une étape de collecte d’informations (Collect information step). En arrière-plan, Pega Platform crée et gère les règles qui définissent les flux de processus et l’interface utilisateur.
Au centre de l’image ci-dessous, faites glisser la ligne verticale pour voir le cycle de vie du dossier (Case Life Cycle) avec un processus créé dans App Studio, ainsi que la règle de flux du processus que le système crée en arrière-plan :
Note: Chaque étape (Step) du cycle de vie du dossier correspond à une forme (shape) de la règle de flux (Flow Rule). Un connecteur de flux (Flow connector) relie une forme à une autre et représente la tâche (Assignment) que les utilisateurs doivent effectuer pour passer d’une forme (étape) à la suivante.
La possibilité de créer des règles complexes grâce à l’interface conviviale d’App Studio est la clé de la fonctionnalité low-code de Pega Platform.
Pendant que des développeurs de tous niveaux de compétence technique travaillent dans App Studio pour créer des automatisations de workflow à l’aide de la modélisation visuelle low-code, Pega Platform travaille en arrière-plan pour créer les règles techniques correspondant à ces automatisations. Par conséquent, les Business Architects et les autres développeurs moins techniques de l’équipe projet, tels que les Citizen Developers, peuvent se concentrer sur la définition des tâches métier plutôt que sur le code.
Note: Les règles techniques sont accessibles aux développeurs techniques plus avancés via Dev Studio. Les règles plus techniques créées par les développeurs dans Dev Studio peuvent être mises à la disposition des utilisateurs dans App Studio.
Vérifiez vos connaissances avec l’interaction suivante :
Modularité de l’application grâce aux règles
L’utilisation de règles individuelles rend une application modulaire. En décrivant le comportement du dossier à l’aide de règles modulaires axées sur les tâches, il est possible de combiner et de réutiliser les règles selon les besoins. Par exemple, une règle est créée pour décrire le contenu d’un e-mail à envoyer à un client concernant le statut d’un changement d’adresse. En créant le message en tant que règle distincte, plutôt que de l’intégrer dans le cycle de vie du dossier, il est possible de mettre à jour le contenu de l’e-mail sans affecter le reste du processus métier.
Cette modularité offre trois avantages importants : la gestion des versions, la délégation et la réutilisation.
| Gestion des versions | Les développeurs créent la nouvelle version d’une règle chaque fois qu’un comportement de dossier doit être modifié. Pega Platform conserve un historique des modifications d’une règle afin de permettre aux développeurs de consulter l’historique des modifications et d’annuler des modifications au besoin. Comme chaque règle décrit un comportement de dossier spécifique, le reste du dossier reste inchangé. | Par exemple, un développeur met à jour un formulaire de l’interface utilisateur en ajoutant des instructions et en supprimant un champ essentiel. Vous pouvez consulter l’historique du formulaire et revenir à la version antérieure aux modifications, sans modifier les autres règles de l’application. |
|---|---|---|
| Délégation | Les développeurs délèguent les règles aux utilisateurs métier pour leur permettre de mettre à jour le comportement d’un dossier à mesure que les conditions métier évoluent. L’utilisateur métier met à jour la règle déléguée, alors que les autres parties de l’application restent inchangées. | Prenons l’exemple d’une entreprise où les notes de frais d’un montant de 25 euros ou moins sont automatiquement approuvées. Vous créez une règle pour déterminer si une note de frais est inférieure ou égale à 25 euros et déléguez cette règle au service comptable. Le service comptable peut ensuite mettre à jour la règle afin que le seuil d’approbation automatique augmente et passe à 50 euros, sans soumettre de demande de modification (change request) de l’application. |
| Réutilisation | Les développeurs réutilisent des règles dès qu’une application doit intégrer un comportement de dossier existant. Sinon, il serait nécessaire de reconfigurer ce comportement à chaque fois que vous en avez besoin. | Supposons, par exemple, que vous créez un formulaire d’interface utilisateur pour collecter des informations sur le titulaire d’une police d’assurance automobile dans le cadre d’une déclaration de sinistre. Vous pourrez ensuite réutiliser ce formulaire d’interface utilisateur pour des déclarations de vols. |
Note: Pour apprendre à déléguer une règle, consultez la rubrique Delegating a rule or data type. Pour accroître la réutilisation d’une règle, utilisez la paramétrisation pour gérer la logique de la règle en utilisant des valeurs transmises en tant que paramètres et non des données codées en dur. La paramétrisation permet de réduire la duplication du code et le temps d’implémentation des spécialisations de règles. Pour plus d’informations sur le paramétrage, consultez la rubrique Defining the input parameters of a rule.
Organisation des règles
Bien que vous ne travailliez pas directement avec des règles d’application dans Dev Studio, il est impératif de collaborer avec votre Lead System Architect pour comprendre l’organisation des règles de votre application.
Dans Dev Studio, les règles sont regroupées en classes et en Rulesets afin de pouvoir être facilement utilisées pour développer des applications.
Classes
Chez Pega, une classe décrit un ensemble de règles que le système regroupe en fonction de leur capacité de réutilisation. Chaque application comprend les trois types de classe suivants :
- Work : la classe Work contient les règles qui définissent le « travail » de bout en bout de traitement des dossiers, tels que les processus, les données et les interfaces utilisateur.
- Data : la classe Data contient les règles qui définissent les data objects utilisés par votre application.
- Integration : la classe Integration contient les règles qui définissent les interactions entre l’application et les systèmes d’enregistrement externes (external system of record), tels qu’une base de données externe gérée par le client.
Classes parent et enfant
Une classe peut contenir d’autres classes. Une classe qui contient une autre classe est une classe parent, tandis qu’une classe incluse dans une autre classe est une classe enfant. Une classe enfant peut réutiliser (hériter de) toutes les règles qui sont définies pour sa classe parent.
Dans l’image suivante, cliquez sur les icônes + pour en savoir plus sur les classes parent et enfant :
Note: Pour plus d’informations sur les classes dans les applications Pega, voir Organizing Rules into classes.
Vérifiez vos connaissances avec l’interaction suivante :
Rulesets
Les règles sont organisées en Rulesets pour identifier, stocker et gérer l’ensemble complet des règles qui définissent une application. Les Rulesets stockent les fonctionnalités réutilisables que vous pouvez migrer d’une application Pega à une autre. Par exemple, vous pouvez créer un Ruleset pour stocker les règles de contrat de niveau de service (SLA). Vous pouvez réutiliser le ruleset SLA dans n’importe quelle application qui traite des dossiers (Cases) exigeant les mêmes SLA. La possibilité d’enregistrer et de réutiliser des Rulesets accélère le développement d’applications pour le client et en réduit le coût.
Chaque Ruleset porte un nom, généralement celui de votre application, et un numéro de version. Lorsque vous créez un nouveau Ruleset, la version par défaut est 01-01-01. Un exemple de combinaison de nom et de version de Ruleset est GoGoRoad 01-01-01.
Le numéro de version est composé de trois éléments : une version majeure, une version mineure et une version patch. Chaque élément est un numéro à deux chiffres compris entre 01 et 99. La numérotation des versions d’un Ruleset commence à 01-01-01.
Dans l’image suivante, cliquez sur les icônes + pour en savoir plus sur la convention de gestion des versions pour les Rulesets :
À partir de 2023, les versions des produits Pega Infinity suivent le format Année.Mineure.Patch. Pour Pega Infinity ’23, la version du produit est 23.1.1. La règle sémantique des versions des Rulesets Pega suit le format Majeure-Mineure-Patch. Pour Pega Infinity ’23, la version du Ruleset est 08-23-02.
Note: Pega Infinity™ ’23 est la dernière version mineure. Pour plus d’informations sur la convention de dénomination des produits Pega Infinity, voir Pega software maintenance program.
Rulesets verrouillés et déverrouillés
Lorsqu’un Ruleset est créé, il est désigné comme verrouillé (locked) ou déverrouillé (unlocked). Les développeurs travaillent dans des Rulesets déverrouillés, et les verrous des rulesets empêchent les développeurs d’apporter des modifications accidentelles. Les développeurs doivent saisir un mot de passe avant de déverrouiller et de modifier un Ruleset verrouillé.
Note: Pour plus d’informations sur les Rulesets dans les applications Pega, voir Organizing Rules into Rulesets.
Le Lead System Architect (LSA) gère à la fois le contrôle des versions et le verrouillage de tous les Rulesets liés à une application pendant le processus de développement. Consultez le LSA de votre projet en cas de questions relatives aux règles et aux Rulesets.
Vérifiez vos connaissances avec l’interaction suivante :
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?