HCL Commerce infrastructure de commandes BOD
La structure de commande Business Object Document (BOD) encapsule la couche de logique commerciale de HCL Commerce. Dans la version 9, elle est largement remplacée par l'API Java Persistance (JPA).
L'architecture de la structure de commande BOD de HCL Commerce utilise des interfaces bien définies pour découpler l'implémentation de la couche de présentation, la couche de logique commerciale et la couche de persistance. Depuis la perspective de la couche de logique métier, des messages OAGIS sont utilisés en tant qu'interface pour l'envoi de requêtes d'extraction de données métier ou pour l'appel de la logique métier. L'infrastructure de commande BOD a la capacité de traiter ces requêtes BOD et leurs réponses.
- Les commandes BOD opèrent sur des objets de données au lieu de paires nom-valeur.
- Les BOD peuvent représenter une requête complexe effectuant plusieurs actions au lieu d'une seule.
- Les commandes BOD interagissent avec une interface de persistance dénommé couche service de données à l'aide d'un objet nommé médiateur d'objet métier et sont indépendantes de la technologie de persistance.
L'application est divisée selon les couches suivantes :
- Couche de présentation
- La première couche est la couche de présentation qui fait office de service d'interaction qui agglomère la logique métier pour constituer une application. La couche de présentation interagit avec la logique métier par le biais de services définis dans OAGIS et ne contient pas elle-même de logique métier à proprement parler. L'extraction de données métier ou l'exécution de logique métier doit être effectuée via les services OASIS d'un module de service. La couche de présentation ne peut pas interroger directement la base de données en vue d'extraire des données métier mais doit interagir avec les composants métier. Le HCL Commerce Management Center est un exemple de couche de présentation.
- Couche de logique métier
- La couche de logique métier fournit des services pour le renvoi de données ou l'exécution de la logique métier. La logique métier est organisée dans l'infrastructure de commande BOD en modules de service (parfois dénommés composants). Ces modules de service, et les services qu'ils hébergent, sont exploités par la couche de présentation afin d'afficher des données ou d'appeler un processus métier.
La partie gauche du diagramme précédent illustre une approche sous laquelle les services transforment les messages OAGIS (BOD) en paires nom-valeur pour leur traitement par des commandes sur des paires nom-valeur. Cela contribue à faciliter l'intégration avec des commandes HCL Commerce existantes ou personnalisées. On parle ici d'intégration orientée service, ou SOI (Service-Oriented Integration). Cette approche est appropriée lorsque la logique métier que vous souhaitez exécuter est déjà rédigée sous forme de commande sur paire nom-valeur.
La partie droite du diagramme illustre une approche sous laquelle les services transforment les messages OAGIS (BOD) en objets Java dénommés objets SDO (Service Data Objects). Les commandes BOD utilisent ces objets en tant qu'interface pour représenter le BOD. La commande utilise ensuite un objet dénommé médiateur d'objet métier (BOM) pour accepter des objets du service de données et gérer le mappage entre ces objets et leur mode de persistance. La logique métier n'a jamais à prendre en compte la technologie retenue pour assurer la persistance des données. La couche de logique métier transmet les objets SDO au mécanisme de persistance sans être elle-même liée à la technologie de persistance.
Les objets SDO font partie du modèle de programmation IBM SOA. Pour plus d'informations sur les objets SDO, suivez les liens ci-dessous :Les patterns de traitement de l'infrastructure de commande BOD sont les suivants :
- Pattern de traitement de la commande BOD Get
- Schéma de traitement de la commande BOD Process
- Pattern de traitement de la commande BOD Change
- Pattern de traitement de la commande BOD Sync
Les deux implémentations de logique commerciale, à savoir la structure de commande sur paire nom-valeur et la structure de commande BOD, sont complètement prises en charge et peuvent coexister dans un site HCL Commerce.
- Couche de persistance
- La couche de logique métier interagit avec la couche de persistance pour extraire et stocker des données. La couche de persistance dispose de deux implémentations différentes : EJB et la couche de service de données.
Sur le côté gauche du diagramme, les commandes de traitement de HCL Commerce sur des paires nom-valeur utilisent EJB pour la persistance. Il s'agit de l'approche utilisée lors de l'intégration à l'aide de l'intégration orientée services (SOI).
Sur le côté droit du diagramme, les commandes extraient et stockent les données via un objet dénommé médiateur d'objet métier (BOM). Ce médiateur accepte et renvoie des données sous forme d'objets SDO logiques. La couche de persistance mappe ces objets avec l'implémentation de persistance afin d'effectuer l'extraction ou la mise à jour des données. Toutes les ressources spécifiques à la persistance, comme les requêtes SQL, sont isolées dans la couche service de données. Avantage de cette approche : la couche de logique métier ignore totalement l'implémentation et la technologie de persistance.
Les deux implémentations de persistance coexistent et accèdent aux mêmes données. Cependant, un modèle mixte (par exemple, paires nom-valeur utilisant la couche de service de données ou bien commandes de traitement BOD utilisant EJB) n'est pas pris en charge.