Remplacement des objets SDO (Service Data Objects) physiques Eclipse Modeling Framework (EMF) par des SDO Eclipselink liés à l'API Java Persistence (JPA)

HCL Commerce Service Business Object Document (BOD)

Lorsqu'un client envoie une demande de service Business Object Document (BOD) au serveur, le framework de service BOD du serveur la transmet au médiateur de composant correspondant. S'il s'agit d'une demande de processus ou de modification, la zone de données dans le BOD est un SDO logique. Le médiateur le convertira en une liste de SDO physiques et le JDBCDataMediator de la couche de service de données (DSL) enverra ces SDO physiques au service JDBCMediator d'IBM à des fins de persistance. S'il s'agit d'une demande de lecture, le médiateur de lecture obtiendra le XPath et le profil d'accès dans le BOD et les enverra à la DSL. La DSL obtiendra les SQL pertinentes et le service JDBCDataMediator dans HCL Commerce avant d'envoyer les SQL au service JDBCMediator d'IBM pour qu'il récupère le contenu de la base de données. Le service JDBCDataMediator d'IBM créera un graphique SDO physique basé sur le résultat de la requête fourni par la base de données, puis renverra ce graphique au service JDBCDataMediator. Quand le médiateur de composants obtiendra le graphique SDO physique, il le reconvertira vers le SDO logique et le framework de service BOD construira un BOD et le renverra au client.

Le diagramme suivant illustre le flux de travail du service BOD existant de Commerce :

SDO EMF

Actuellement, les SDO physiques utilisés dans le service BOD sont des SDO EMF. La couche de persistance s'appuie sur le JDBCMediator d'IBM pour lire et garantir la persistance des données dans la base de données. Puisqu'il s'agit d'une technologie propriétaire d'IBM et qu'elle n'est pas open source, le SDO EMF est remplacé par le SDO EclipseLink et la couche de persistance est remplacée par l'API Java Persistence (JPA).

SDO Eclipselink avec JPA

EclipseLink fournit une solution de persistance Java open source qui inclut la prise en charge des formats JPA et SDO. Pour plus d'informations, voir EclipseLink/Examples/SDO/JPA. Avec EclipseLink, chaque SDO sera lié à un objet JPA. Quelles que soient les modifications apportées au SDO, elles se refléteront dans le JPA lié et le gestionnaire d'entité JPA assurera le processus de persistance. Le SDO et le JPA peuvent être générés par un fichier de définition de schéma XML (XSD) qui définit les interfaces SDO.

HCL Commerce Service BOD

Les diagrammes suivants illustrent le nouveau flux de travail pour le service BOD :

Le service BOD original avec SDO EMF :
Le service BOD avec SDO Eclipselink :
Le service JDBCMediator a été remplacé par le service JPADataMediator et le service JDBCMediator d'IBM a été remplacé par le gestionnaire d'entité JPA.

Etapes à suivre pour autoriser tous les composants à utiliser le médiateur JPA

Mise à jour du fichier wc-server.xml dans le répertoire xml\config en ajoutant un attribut DataServiceMediatorType à la balise Instance.

Par exemple :

<Instance ... DataServiceMediatorType="JPA" />

Les valeurs acceptables pour le type de médiateur de données sont JPA ou JDBC. Toutes les autres valeurs seront ignorées.

Personnalisation

Supposons qu'un client ait procédé à une personnalisation basée sur le Tutoriel de garantie afin d'étendre l'outil de catalogue dans le Centre de gestion, puis ait activé le nouveau SDO EclipseLink lié à JPA. Le cas échéant, il doit migrer sa personnalisation vers ce nouvel environnement. Il doit également migrer ses SDO EMF personnalisés vers le SDO EclipseLink lié à JPA.HCL Commerce fournit un outil aidant les clients à générer le nouveau SDO personnalisé lié à JPA.

Dans l'environnement de développement Commerce (kit d'outils), les clients disposent de la personnalisation. Les fichiers de configuration personnalisés ont déjà été générés dans le répertoire : WC > xml > config > com.ibm.commerce.catalog-ext. Les clients doivent exécuter generateCustomSdoJpa.bat afin de générer les fichiers SDO et JPA EclipseLink personnalisés. Le fichier generateCustomSdoJpa.bat se trouve dans le répertoire bin. Le script prend deux paramètres :

L'ID du composant. Par exemple, l'ID du composant catalog est com.ibm.commerce.catalog.
Le répertoire de sortie dans lequel les fichiers SDO et JPA EclipseLink seront générés. Il peut s'agir par exemple du répertoire \output.

Exécutez les étapes suivantes :

Exécutez la commande suivante :
```
bin> generateCustomSdoJpa.bat com.ibm.commerce.catalog \output
```
Les fichiers SDO et JPA sources seront générés dans le répertoire \output. Un fichier XSD catalog-ext.xsd est également généré dans le répertoire WC > xml > config > com.ibm.commerce.catalog-ext.
Copiez les fichiers source générés dans le répertoire \output vers le projet WebSphereCommerceServerExtensionsData dans l'espace de travail. Autrement dit, copiez-le vers le répertoire : WebSphereCommerceServerExtensionsData > ejbModule.
Pour corriger les erreurs de compilation pour les SDO et JPA personnalisés générés, vous devez ajouter le fichier JAR suivant dans le chemin de génération Java : WC > Foundation-SDO-JPA.jar.

Note: N'exécutez pas le script pour générer le code source SDO et JPA directement dans le répertoire WebSphereCommerceServerExtensionsData > ejbModule. Le cas échéant, le script nettoierait le répertoire de sortie et pourrait supprimer certains des fichiers existants qu'il contient et que vous pourriez vouloir conserver. Générez donc toujours les fichiers dans un nouveau répertoire ou un répertoire vide, puis copiez tous les fichiers générés dans le répertoire WebSphereCommerceServerExtensionsData > ejbModule.

Vous pouvez maintenant tester votre personnalisation avec les SDO et JPA EclipseLink activés dans votre boîte à outils.

Vous pouvez également déployer votre personnalisation vers le conteneur Docker ts-app afin de vérifier si la personnalisation y fonctionne également avec les SDO et JPA EclipseLink activés. Le déploiement de la personnalisation dans le conteneur Docker ts-app nécessite d'empaqueter le fichier WebSphereCommerceServerExtensionsData.jar dans celui-ci. Vous devez également déployer le fichier catalog-ext.xsd dans le conteneur Docker ts-app en le copiant dans le répertoire : /opt/WebSphere/AppServer/profiles/default/installedApps/localhost/ts.ear/xml/config/com .ibm.commerce.catalog-ext

L'outil qui génère les SDO et JPA EclipseLink est également disponible dans le conteneur Docker ts-utils. Le nom du fichier de script est generateCustomSdoJpa.sh. Les paramètres du script sont les mêmes que dans le kit d'outils. Avant d'appeler le script, vous devez copier vos fichiers de configuration personnalisés SDO EMF existants vers le conteneur Docker ts-utils dans le répertoire suivant : /opt/WebSphere/AppServer/profiles/default/installedApps/localhost/ts.ear/xml/config/ com.ibm.commerce.catalog-ext

Note: Assurez-vous qu'aucun des codes de personnalisation n'utilise aucune des classes d'implémentation Java du SDO. Dans le cas contraire, vous devez modifier le code de personnalisation afin d'utiliser plutôt les classes d'interface Java du SDO.

Migration de base de données pour les tables personnalisées

Le champ OPTCOUNTER ne peut pas avoir une valeur nulle, selon JPA. Avec la migration vers la V9, toutes les tables standard comportent désormais la colonne OPTCOUNTER avec une valeur par défaut de 0. Il devient nécessaire également de créer une colonne OPTCOUNTER contenant des valeurs non nulles pour toutes les tables personnalisées. Par exemple, il est possible d'utiliser les tables personnalisées XWARRANTY et XCAREINSTRUCTION avec les instructions SQL suivantes :

UPDATE XWARRANTY SET OPTCOUNTER = 0 WHERE OPTCOUNTER IS NULL;

UPDATE XCAREINSTRUCTION SET OPTCOUNTER = 0 WHERE OPTCOUNTER IS NULL;

Pour plus d'informations sur OPTCOUNTER, voir Verrouillage optimiste.