Sustitución de los objetos de datos de servicio (SDO) físicos de Eclipse Modeling Framework (EMF) con el SDO de Eclipselink vinculado con Java Persistence API (JPA)

HCL Commerce Servicio Documento de objeto de negocio (Business Object Document - BOD)

Cuando un cliente envía una solicitud de servicio Documento de objeto de negocio (BOD) al servidor, la infraestructura de servicio BOD del servidor la pasará al mediador del componente correspondiente. Si se trata de una solicitud de cambio o proceso, el área de datos en el BOD es un objeto de datos de servicio (SDO) lógico. El mediador la convertirá en una lista de SDO físicos y JDBCDataMediator de la capa de servicio de datos (DSL) enviará esos SDO físicos a IBM JDBCMediator para que se conserven. Si se trata de una solicitud de lectura, el mediador de lectura obtendrá el XPath y el perfil de acceso en el BOD y lo enviará a la DSL. La DSL obtendrá los SQL relevantes y el JDBCDataMediator en HCL Commerce antes de enviar los SQL a IBM JDBCMediator para recuperar el contenido de la base de datos. IBM JDBCDataMediator creará un gráfico SDO físico basado en el resultado de la consulta proporcionado desde la base de datos y, a continuación, devolverá este gráfico a JDBCDataMediator. Cuando el mediador del componente obtiene el gráfico SDO físico, lo convertirá nuevamente en el SDO lógico y la infraestructura de servicio de BOD creará un BOD y lo enviará de regreso al cliente.

En el diagrama siguiente se muestra el flujo de trabajo para el servicio BOD de Commerce existente:

SDO de EMF

Actualmente, los SDO físicos utilizados en el servicio BOD son SDO de EMF. La capa de persistencia se basa en IBM JDBCMediator para leer y conservar los datos en la base de datos. Como se trata de tecnología propiedad de IBM y no de código abierto, el SDO de EMF se sustituye por el SDO de EclipseLink y la capa de persistencia se sustituye por Java Persistence API (JPA).

SDO de Eclipselink con JPA

EclipseLink proporciona una solución de persistencia de Java de código abierto que incluye compatibilidad con JPA y SDO. Para obtener más información, consulte EclipseLink/Examples/SDO/JPA. Con EclipseLink, cada SDO se vinculará con un objeto de JPA. Los cambios que se realicen en el SDO se reflejarán en el JPA vinculado, y el gestor de entidades JPA lo conservará. El SDO y el JPA se pueden generar mediante un archivo de definición de esquema XML (XSD) que define las interfaces de SDO.

HCL Commerce Servicio BOD

En los siguientes diagramas se muestra el nuevo flujo de trabajo para el servicio de BOD:

Servicio BOD original con el SDO de EMF:
Servicio BOD con el SDO de Eclipselink:
JDBCMediator se ha sustituido por JPADataMediator e IBM JDBCMediator se ha sustituido por el gestor de entidades de JPA.

Pasos para permitir que todos los componentes utilicen el mediador de JPA

Actualizar el archivo wc-server.xml en el directorio xml\config añadiendo un atributo DataServiceMediatorType a la etiqueta Instance.

Por ejemplo:

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

Los valores aceptables para el tipo de mediador de datos son JPA o JDBC. Cualquier otro valor se ignorará.

Personalización

Supongamos que un cliente ha realizado una personalización basada en la guía de aprendizaje sobre garantía para ampliar la herramienta de catálogo en el centro de gestión, antes de habilitar el nuevo SDO de EclipseLink vinculado con JPA. En ese caso, deberá migrar su personalización a ese nuevo entorno. También necesita migrar sus SDO de EMF personalizados al SDO de EclipseLink vinculado con JPA.HCL Commerce proporciona una herramienta para que los clientes puedan generar el nuevo SDO personalizado vinculado con JPA.

En el entorno de desarrollo de Commerce (kit de herramientas), los clientes cuentan con la personalización. Los archivos de configuración personalizados ya se han generado en el directorio: WC > xml > config > com.ibm.commerce.catalog-ext. Los clientes deben ejecutar generateCustomSdoJpa.bat para generar los archivos de SDO y JPA de EclipseLink personalizados. El archivo generateCustomSdoJpa.bat se puede encontrar en el directorio bin. El script toma dos parámetros:

El ID del componente. Por ejemplo, el ID del componente de catálogo es com.ibm.commerce.catalog.
El directorio de salida donde se generarán los archivos de SDO y JPA de EclipseLink. Por ejemplo, puede ser \output.

Lleve a cabo los siguientes pasos:

Ejecute el mandato siguiente:
```
bin> generateCustomSdoJpa.bat com.ibm.commerce.catalog \output
```
Los archivos de origen SDO y JPA se generarán en el directorio \output. También genera un archivo XSD catalog-ext.xsd en el directorio WC > xml > config > com.ibm.commerce.catalog-ext.
Copie los archivos de origen generados en \output en el proyecto WebSphereCommerceServerExtensionsData del espacio de trabajo. Es decir, cópielo en el directorio: WebSphereCommerceServerExtensionsData > ejbModule.
Para corregir los errores de compilación para el SDO y JPA personalizados generados, debe añadir el siguiente archivo jar en la vía de acceso de compilación de Java: WC > Foundation-SDO-JPA.jar.

Note: No ejecute el script para generar el código fuente de SDO y JPA directamente en el directorio WebSphereCommerceServerExtensionsData > ejbModule. El script limpiará el directorio de salida y puede eliminar algunos archivos existentes del directorio de salida, que quizás desee conservar. Por lo tanto, genere siempre los archivos en un directorio nuevo o vacío y, a continuación, copie todos los archivos generados en el directorio WebSphereCommerceServerExtensionsData > ejbModule.

Ahora puede probar su personalización con el SDO y JPA de Eclipselink habilitados en su kit de herramientas.

También puede desplegar la personalización en el contenedor de Docker ts-app para probar si la personalización también funciona en el contenedor de Docker ts-app con el SDO y JPA de EclipseLink habilitados. Para desplegarla en el contenedor de Docker ts-app, debe empaquetar WebSphereCommerceServerExtensionsData.jar en el contenedor de Docker ts-app. También debe desplegar catalog-ext.xsd en el contenedor de Docker ts-app copiando el archivo en el directorio: /opt/WebSphere/AppServer/profiles/default/installedApps/localhost/ts.ear/xml/config/com.ibm.commerce.catalog-ext

La herramienta que genera el SDO y JPA de EclipseLink también está disponible en el contenedor Docker ts-utils. El nombre del archivo de script es generateCustomSdoJpa.sh. Los parámetros del script son los mismos que los del kit de herramientas. Antes de llamar al script, debe copiar los archivos de configuración personalizados del SDO de EMF existentes en el contenedor Docker ts-utils en el siguiente directorio: /opt/WebSphere/AppServer/profiles/default/installedApps/localhost/ts.ear/xml/config/ com.ibm.commerce.catalog-ext

Note: Asegúrese de que ninguno de los códigos de personalización utilice ninguna de las clases de implementación de Java del SDO. Si es así, debe cambiar el código de personalización para que ahora utilice las clases de la interfaz Java del SDO.

Migración de la base de datos para tablas personalizadas

El campo OPTCOUNTER no puede tener un valor nulo, según JPA. Con la migración a la versión V9, todas las tablas estándar ahora cuentan con la columna OPTCOUNTER con un valor predeterminado 0. También necesita crear una columna OPTCOUNTER con valores no nulos para cualquier tabla personalizada. Por ejemplo, las tablas personalizadas XWARRANTY y XCAREINSTRUCTION se pueden utilizar con las siguientes sentencias SQL:

UPDATE XWARRANTY SET OPTCOUNTER = 0 WHERE OPTCOUNTER IS NULL;

UPDATE XCAREINSTRUCTION SET OPTCOUNTER = 0 WHERE OPTCOUNTER IS NULL;

Para obtener más información sobre OPTCOUNTER, consulte Bloqueo optimista.