Couche service de données
La couche service de données (DSL) fournit une couche d'abstraction pour l'accès aux données, indépendante du schéma physique.
L'objet de la couche service de données est de fournir une interface cohérente (dénommée façade de service de données) indépendante de l'infrastructure de mappage objet-relationnel (telle que EJB, DAS ou JPA) pour l'accès aux données. A son tour, l'infrastructure de mappage abstraite est utilisée pour convertir les données extraites de la base de données en une collection d'objets Java. Ces objets sont implémentés sous forme d'objets SDO physiques.
La couche service de données effectue des transformations bidirectionnelles entre objets SDO physiques et logiques. Elle vous permet de créer, récupérer, mettre à jour et supprimer des opérations sur les objets SDO logiques. La couche de service de données vous permet également d'effectuer des opérations de création, de récupération, de mise à jour et de suppression directement sur les données physiques, en contournant complètement le schéma logique.
XPath est utilisé comme langage de requête sur le schéma logique. La couche service de données mappe les requêtes XPath avec des modèles ou des instructions SQL. Ces modèles sont utilisés pour générer les instructions SQL effectives qui accèdent à la base de données.
Elle permet également d'intégrer dans les modèles des variables du contexte métier auxquelles sont substituées des valeurs lorsque les instructions SQL sont générées. Par conséquent, les requêtes XPath envoyés par le client peuvent produire différentes requêtes SQL concrètes en fonction des valeurs des propriétés du contexte métier. Les instructions sont stockées dans un fichier de modèle de requête séparé qui isole la logique d'exécution du code de la requête SQL.
Le fichier de modèle de requête fournit un mécanisme pour un mappage facile entre la requête dans votre modèle logique, votre requête XPath, et une ou plusieurs instructions SQL. Ces instructions sont utilisées pour l'extraction des données physiques de la base de données.
Ce fichier permet également d'isoler les instructions SQL du code Java d'exécution, facilitant ainsi la maintenance de ce code. Il est aussi utile aux administrateurs de la base de données quand ils désirent localiser et analyser des requêtes. Les modifications des requêtes SQL ne nécessitent pas de recompilation Java.
Le diagramme suivant présente les différentes couches du modèle de programmation de HCL Commerce et la place de la couche de service de données dans ce modèle :
La couche de service de données DSL se compose de trois éléments : le service de médiation d'objet métier, le service de persistance physique et la façade du service de données.
Le service de médiation d'objet métier initialise des médiateurs. Il s'agit de classes opérant une transformation entre les représentations logiques et physiques du modèle du domaine. Ceci permet à la couche de logique métier de ne manier que la représentation logique des données.
Chaque module de service fournit ses propres médiateurs qui peuvent être de deux type : médiateurs de lecture et de changement. Médiateurs de lecture et de changement. Ils sont recensés dans le fichier de configuration BOM. Les médiateurs de lecture sont utilisés pour le traitement des requêtes Get d'OAGIS. Les médiateurs de changement traitent les requêtes OAGIS Change, Process et Sync.
Les médiateurs accèdent aux données physiques via le service de persistance physique. Ce service convertit les requêtes XPath en requêtes SQL.
La façade de service de données est une couche étroite fournissant un point d'entrée unique dans la couche service de données. Elle fournit des interfaces pour travailler avec les données physiques et les données logiques et délègue le traitement au service de médiation d'objet métier ou au service de persistance physique. Elle permet également à chaque module de service de s'enregistrer avec la couche service de données et charge les fichiers de configuration spécifiques au module de service.
Pour les opérations de lecture, la façade de la couche service de données reçoit une requête de la couche de logique métier. La requête consiste d'une expression XPath et d'un profil d'accès, extraits à partir du verbe OAGIS GET. La couche service de données fait suivre cette requête au médiateur d'objet métier, lequel la transmet à son tour au service de persistance. Ce dernier identifie le modèle SQL approprié pour la requête et l'utilise afin de générer une ou plusieurs instructions SQL. Il exécute ensuite ces instructions et mappe leurs jeux de résultats avec des objets SDO physiques. Ce mappage entre le schéma de base de données (tables et colonnes) et les classes SDO est défini par l'élément XML dénommé Métadonnées objet-relationnel. Enfin, les objets SDO physiques sont renvoyés au médiateur d'objet métier. La configuration du médiateur d'objet métier décrit comment instancier les médiateurs requis. Ces médiateurs sont renvoyés à la couche logique métier. Le médiateur lui-même est renvoyé et non pas seulement l'objet SDO. Le médiateur contient les données de l'objet SDO physique. Il contient également la logique destinée à la conversion de l'objet SDO physique en objet SDO logique (c'est-à-dire la représentation Java d'un nom OAGIS).
Pour les opérations de changement (création, mise à jour et suppression) la façade de la couche service de données reçoit en entrée les noms OAGIS et les transmet au service de médiation de l'objet métier. Ce service instancie les médiateurs de changement appropriés. A leur tour, ces médiateurs obtiennent la représentation physique des noms depuis un service nommé service de médiation d'objet physique. Le médiateur d'objet métier renvoie ensuite les médiateurs à la couche de logique métier. Ces médiateurs sont alors appelés avec des actions spécifiques pour créer, mettre à jour ou supprimer des noms et des parties de nom. La logique à l'intérieur des médiateurs convertit ces actions en opérations sur les objets SDO physiques. Une requête de création, par exemple, crée de nouveaux objets physiques et les alimentera avec des valeurs de noms. Après avoir effectué toutes ses modifications, la couche de logique métier indique au médiateur de changement de nom d'enregistrer les objets SDO physiques mis à jour. Le médiateur appelle un service de persistance d'objet physique pour mettre à jour la base de données.
Limitations de la couche service de données
- Toutes les tables doivent comporter une clé primaire.
- Les clés primaires multicolonnes ne sont pas prises en charge pour les tables de base.
- Le composeur de graphique par défaut ne peut fusionner les jeux de résultats des instructions SQL d'association SQL que s'ils n'extraient pas des enregistrements identiques de tables autres que la table de base.
- Lorsque vous utilisez un processus en deux étapes pour localiser les objets par clés primaires, puis pour extraire toutes les données en fonction de ces clés, il n'est pas toujours possible de trier les résultats de la requête finale. Vous ne pouvez pas trier les résultats de la requête XPath to SQL puis propager ce tri sur le résultat de la requête SQL d'association. Si le tri du résultat est nécessaire, il est recommandé d'utiliser une requête à une seule étape. Une instruction order by est requise lors du classement d'une pagination de niveau sous-nom lorsqu'une seule instruction SQL d'association est utilisée avec une instruction XPath to SQL.
- Les paramètres de pagination sont toujours requis pour le service de pagination de niveau sous-nom. Les paramètres de pagination sont facultatifs pour le service de pagination de niveau nom.
- Les extensions de modules de service SOI (modules utilisant des commandes avec paires nom-valeur) ne doivent pas utiliser la couche service de données.
- Les extensions de modules de service BOD doivent utiliser exclusivement la couche service de données.
- Les requêtes de recherche paramétrique doivent utiliser des requêtes en deux étapes (localisation des objets par clés primaires, puis extraction de toutes les données d'après ces clés primaires).
- Les modèles de persistance EJB et couche service de données ne doivent pas être utilisés dans la même transaction.
- Vous ne devez jamais lire ou mettre à jour les mêmes données à l'aide de JDBCQueryService et de PhysicalDataContainer dans la même transaction. Si vous le faites, il est possible que vous lisiez des données périmées ou que des données corrompues parviennent à la base de données.