Esta sección describe cómo los metadatos mejoran la flexibilidad del conector, y proporciona una descripción general del proceso de los objetos comerciales y de la notificación de sucesos.
El conector está gobernado por metadatos. En el entorno de IBM WebSphere Business Integration Adapter, los metadatos son datos específicos de la aplicación que se almacenan en objetos comerciales y que ayudan al conector en su interacción con la aplicación. Un conector gobernado por metadatos maneja cada objeto comercial compatible de acuerdo con metadatos que están codificados en la definición del objeto comercial, en lugar de hacerlo basándose en instrucciones codificadas en el conector.
Los metadatos de objeto comercial incluyen la estructura de un objeto comercial, los valores de sus propiedades de atributos y el contenido de su información específica de la aplicación. Debido a que el conector está gobernado por metadatos, puede manejar objetos comerciales nuevos o modificados sin necesitar modificaciones en el código del conector.
El conector ejecuta sentencias de SQL o procedimientos almacenados para recuperar o cambiar datos en la base de datos/aplicación. Para crear sentencias de SQL dinámico o procedimientos almacenados, el conector utiliza metadatos específicos de la aplicación. Estas sentencias de SQL y procedimientos almacenados realizan las acciones necesarias de recuperación o cambio en la base de datos/aplicación para el objeto comercial y para el verbo que el conector está procesando. Para obtener información sobre el uso de información específica de la aplicación, consulte el Descripción de los objetos comerciales en su relación con el conector.
Esta sección proporciona una visión general de cómo el conector procesa peticiones de objetos comerciales y sucesos de aplicación. Para obtener información más detallada, consulte Procesos de verbos de objeto comercial.
Cuando el conector recibe una petición para efectuar una operación de aplicación, el conector procesa recursivamente objetos comerciales jerárquicos; es decir, efectúa los mismos pasos para cada objeto comercial hijo hasta que ha procesado todos los objetos comerciales individuales. El orden en el que el conector procesa los objetos comerciales hijo y el objeto comercial de nivel superior depende de si los objetos comerciales hijo están contenidos con o sin propietario y de si están contenidos con cardinalidad simple o cardinalidad múltiple.
Cuando un intermediario de integración solicita al conector que recupere un objeto comercial jerárquico de la base de datos, el conector intenta devolver un objeto comercial que coincida exactamente con la representación actual de ese objeto comercial en la base de datos. Es decir, todos los atributos simples de cada objeto comercial individual devuelto al intermediario de integración coinciden con el valor del campo correspondiente de la base de datos. Además, el número de objetos comerciales individuales en cada matriz contenida por el objeto comercial devuelto coincide con el número de hijos en la base de datos para esa matriz.
Para realizar una recuperación, el conector utiliza los valores de clave primaria del objeto comercial de nivel superior para descender recursivamente por los datos correspondientes de la base de datos.
Cuando un intermediario de integración solicita al conector que recupere un objeto comercial jerárquico basándose en valores de atributos no de clave del objeto comercial de nivel superior, el conector utiliza el valor de todos los atributos no nulos como criterio para recuperar los datos.
Cuando un intermediario de integración solicita al conector que cree un objeto comercial jerárquico en la base de datos, el conector efectúa estos pasos:
Cuando un intermediario de integración solicita al conector que actualice un objeto comercial jerárquico en la base de datos, el conector efectúa estos pasos:
Cuando un intermediario de integración solicita al conector que suprima un objeto comercial jerárquico de la base de datos, el conector efectúa estos pasos:
El conector maneja los sucesos Crear, Actualizar y Suprimir generados por la aplicación de la manera descrita a continuación.
Cuando el conector encuentra un suceso Crear en la tabla de sucesos, crea un objeto comercial del tipo especificado por el suceso, establece los valores de clave para el objeto comercial (utilizando las claves especificadas en la tabla de sucesos) y recupera el objeto comercial de la base de datos. Después de recuperar el objeto comercial, el conector lo envía junto con el verbo Crear al intermediario de integración.
Cuando el conector encuentra un suceso Actualizar en la tabla de sucesos, crea un objeto comercial del tipo especificado por el suceso, establece los valores de clave para el objeto comercial (utilizando las claves especificadas en la tabla de sucesos) y recupera el objeto comercial de la base de datos. Después de recuperar el objeto comercial, el conector lo envía junto con el verbo Actualizar al intermediario de integración.
Cuando el conector encuentra un suceso Suprimir en la tabla de sucesos, crea un objeto comercial del tipo especificado por el suceso, establece los valores de clave para el objeto comercial (utilizando las claves especificadas en la tabla de sucesos) y envía el objeto comercial junto con el verbo Suprimir al intermediario de integración. Todos los valores excepto los valores de clave se establecen en CxIgnore. Si alguno de los campos que no son de clave son importantes en su sitio, modifique el valor de los campos según sea necesario.
El conector maneja las operaciones lógicas y físicas de Suprimir que son desencadenadas por la aplicación del conector. En el caso de las supresiones físicas, el mecanismo SmartFiltering elimina todos los sucesos no procesados del objeto comercial (tales como Crear o Actualizar) antes de insertar el suceso Suprimir en la tabla de sucesos. En el caso de las supresiones lógicas, el conector inserta un suceso Suprimir en la tabla de sucesos sin eliminar otros sucesos para el objeto comercial.
La Recuperación de un objeto comercial para el proceso de sucesos puede realizarse de dos maneras. La primera es la Recuperación basada en atributos de clave de un objeto comercial. La segunda es la Recuperación basada en atributos de clave y atributos no de clave. En este caso, el objeto comercial necesita ser compatible con el verbo RetrieveByContent y debe utilizar el par nombre_valor para las claves de objeto.
El mecanismo de detección de sucesos del conector utiliza una tabla de sucesos, una tabla de archivado, procedimientos almacenados y desencadenantes de base de datos. Debido a la existencia de posibles puntos de error asociados al proceso de sucesos, el proceso de gestión de sucesos no suprime un suceso de la tabla de sucesos hasta que se ha insertado en la tabla de archivado.
Los desencadenantes de base de datos añaden datos a una tabla de sucesos cada vez que se produce un suceso de interés en la base de datos. El conector sondea esta tabla según un intervalo regular configurable, recupera los sucesos y los procesa primero por orden de prioridad y luego secuencialmente. Cuando el conector ha procesado un suceso, se actualiza el estado del suceso.
El valor de la propiedad ArchiveProcessed del conector determina si el conector archiva un suceso en la tabla de archivado después de actualizar el estado del suceso. Para obtener más información sobre la propiedad ArchiveProcessed, consulte Configuración del conector.
La Tabla 1 muestra cómo se realiza el archivado dependiendo del valor de la propiedad ArchiveProcessed.
Valor de ArchiveProcessed | Razón para suprimir de la tabla de sucesos | Acción del conector |
---|---|---|
true o sin valor | Procesado con éxito | Archivado con estado de Sent to InterChange |
Procesado sin éxito | Archivado con estado de Error | |
No existe ninguna suscripción para el objeto comercial | Archivado con estado de Unsubscribed | |
false |
Procesado con éxito | No se archiva y se suprime de la tabla de sucesos |
Procesado sin éxito | Permanece en la tabla de sucesos con el estado de Error | |
No existe ninguna suscripción para el objeto comercial | Permanece en la tabla de sucesos con el estado de Unsubscribed |
SmartFiltering es un mecanismo dentro de los desencadenantes de base de datos que minimiza el volumen de proceso que deben realizar el intermediario de integración y el conector. Por ejemplo, si una aplicación ha actualizado 15 veces el objeto comercial Contrato desde la última vez que el conector comprobó la existencia de sucesos, SmartFiltering guarda esos cambios como un único suceso de Actualizar.
Existen muchas razones para perder una conexión de base de datos. Si se produce esta pérdida, el conector concluye su ejecución. La especificación JDBC no proporciona un mecanismo para detectar conexiones perdidas. Debido a que el conector puede trabajar con bases de datos diferentes, no existe una única definición de código de error para una conexión perdida con una base de datos.
Se utiliza la propiedad PingQuery para gestionar esta detección. Si se produce un error durante una petición de llamada de servicio, el conector ejecuta PingQuery para verificar que el error no se debió a una conexión perdida con una base de datos. Si la operación PingQuery falla y la propiedad AutoCommit tiene el valor "false", el conector intentará crear una nueva conexión con la base de datos. Si el conector logra establecer una nueva conexión con la base de datos, continuará el proceso; en caso contrario, el conector devuelve el código de retorno APPRESPONSETIMEOUT, que hace que concluya la ejecución del conector.
Se ejecuta PingQuery si se produce un error al acceder a una base de datos para cualquier tipo de transacción. Por ejemplo:
El conector se ha internacionalizado para que pueda trabajar con juegos de caracteres de doble byte y emitir mensajes en el idioma especificado. Cuando el conector transfiere datos desde una ubicación a otra que hace uso de un juego de códigos de caracteres diferente que la ubicación de origen, el conector realiza una conversión de caracteres para preservar el significado de los datos.
El entorno de ejecución Java(TM) de la Máquina Virtual Java (Java Virtual Machine, JVM) representa los datos utilizando el juego de códigos de caracteres Unicode. Unicode contiene codificaciones de caracteres para la mayoría de juegos de códigos de caracteres conocidos (tanto de un sólo byte como de varios bytes). La mayoría de los componentes del sistema WebSphere Business Integration están escritos en Java. Por tanto, para la mayoría de los componentes del sistema WebSphere Business Integration, no hay necesidad de realizar una conversión de caracteres cuando se transfieren datos entre los componentes.
Para registrar mensajes de error e informativos utilizando el idioma adecuado y para el país o territorio apropiado, configure la propiedad de configuración estándar Locale para su entorno. Para obtener más información sobre estas propiedades, consulte el Apéndice A. Propiedades de configuración estándar para conectores.