Présentation : Modèle d'objet métier (BOM) et modèle d'objet d'exécution (XOM)
Vous pouvez construire le XOM à partir de différentes sources de données.
Le modèle d'objet d'exécution (XOM) est le modèle sur lequel vous exécutez des règles. Il référence les objets et les données de l'application et est l'implémentation de base du modèle d'objet métier (BOM). Il est référencé par les projets de règles.
Grâce au XOM, le moteur de règles peut accéder aux objets et méthodes de l'application, qui peuvent être des objets Java™ , des données XML ou des données provenant d'autres sources. En phase d'exécution, les règles écrites par rapport au BOM sont exécutées sur le XOM.
Chaque élément du BOM (élément métier) doit avoir un élément correspondant dans le XOM (élément d'exécution). Il n'est pas nécessaire que la correspondance entre les éléments d'exécution et les éléments métier soit biunivoque (un à un). Lorsqu'un élément métier provient d'un élément d'exécution, vous n'avez pas besoin de spécifier de mappage explicite. Lorsqu'un élément métier ne provient pas d'un élément d'exécution, vous devez spécifier un mappage BOM-XOM.
Il existe certaines règles internes pour le mappage BOM-XOM implicite lorsque vous générez un BOM à partir d'un XOM. Par exemple, une classe BOM est implicitement mappée à une classe XOM portant le même nom.
Conception d'un BOM pour un modèle Java
Lorsque votre modèle de données est en Java, vous pouvez générer une nomenclature directement à partir de ce modèle d'objet d'exécution Java (XOM), voir Mappage d'une nomenclature créée à partir d'un XOM Java. Vous pouvez utiliser des annotations XOM pour configurer la génération de BOM, voir Annotations XOM. Si vous souhaitez étendre le BOM avec des classes et des méthodes métier, vous pouvez mapper ces éléments métier à des éléments XOM à l'aide du mappage de BOM vers XOM dans l'éditeur de BOM. Vous disposez de deux moyens pour spécifier le mappage de nomenclature à nomenclature : le mappage d'extender ou le mappage d'ARL, voir Langage de règles et mappage d'extender. Les utilisateurs métier peuvent alors créer des règles métier sans se soucier de la plateforme et des types de données sous-jacents.
Lors du déploiement, si votre application est une application Java ou Web, le XOM Java est intégré à l'application et aucune étape de déploiement spécifique n'est nécessaire pour le XOM. Vous pouvez mettre en package les règles et la définition de mappage BOM-to-XOM dans une archive d'ensemble de règles, qui est ensuite disponible pour votre application appelante via l'environnement d'exécution de règles, Rule Execution Server.
Si vous ne disposez pas d'une application d'appel Java ou Web, soit parce que vous souhaitez le déployer sur un serveur de test pour test et simulation, soit parce que vous souhaitez exposer vos règles en tant que service de décision transparent hébergé (HTDS), vous devez déployer le XOM Java dans la base de données Rule Execution Server .
Lorsque vous testez et simulez l'exécution d'une règle, Decision Runner accède à Rule Execution Server pour l'exécution, et Rule Execution Server récupère le XOM dans la base de données.
Lorsque vous générez un HTDS, Rule Execution Server extrait le XOM de la base de données de la même manière (voir Téléchargement d'un fichier WSDL HTDS).
Considérations relatives à l'exécution de XOM
Si vous utilisez un ou plusieurs XOM Java avec votre service de décision et que vous prévoyez d'utiliser l'application web HTDS (hosted transparent decision service), vous devez concevoir vos XOM avec soin. Vos XOM sont utilisés dans l'ensemble du HTDS et font l'objet d'une introspection et d'une sérialisation/désérialisation :
- La sérialisation de Java vers JSON ou XML a lieu lorsque vous générez des exemples de requêtes REST ou fournissez des réponses SOAP ou REST.
- La désérialisation de JSON ou XML vers Java a lieu lorsque vous traitez des requêtes SOAP ou REST.
- L'introspection du modèle a lieu lors de la génération d'un descripteur d'API ( OpenAPI, WADL ou WSDL).
Par conséquent, vous devez respecter les exigences de sérialisation standard lorsque vous concevez vos XOM :
- Assurez-vous que vos classes Java peuvent être instanciées par les moteurs de sérialisation. Définissez des constructeurs sans paramètre pour les classes Java, ainsi que des getters et setters pour tous les champs requis, ou utilisez des annotations pour guider les moteurs de sérialisation lorsque vous créez des objets à partir de vos classes Java.
- Évitez les cycles dans votre modèle.
- (Recommandé) Utilisez des annotations pour ignorer les champs et les propriétés qui ne sont pas utiles à votre service de décision.
- (Facultatif) Annotez vos classes et/ou méthodes Java avec des annotations Jackson pour JSON ou des annotations JAXB pour XML afin d'influencer la sérialisation et la désérialisation des paramètres du service de décision et la génération des descripteurs API.
Conception d'un BOM pour un modèle XML
Lorsque votre modèle de données est en XML, vous pouvez générer une nomenclature directement à partir de ce XOM dynamique, voir Vue d'ensemble : Modèle d'objet d'exécution dynamique (XOM) et Types simples intégrés. Si vous souhaitez étendre le BOM avec des classes et des méthodes métier, vous pouvez mapper ces éléments métier à des éléments XOM à l'aide du mappage de BOM vers XOM dans l'éditeur de BOM. Vous spécifiez ce mappage avec le mappage ARL, voir Langage de règles et mappage de l'extenseur. Les utilisateurs métier peuvent alors créer des règles métier sans se soucier de la plateforme et des types de données sous-jacents.
Lors du déploiement, les fichiers de mappage Dynamic XOM et BOM-to-XOM sont fournis avec les règles de l'archive d'ensemble de règles, qui est ensuite disponible pour votre application appelante via l'environnement d'exécution de règles, Rule Execution Server.
