Cómo actúa el conector

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 y los metadatos

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.

Proceso de objetos comerciales

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.

Proceso de peticiones de objetos comerciales

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.

Nota:
El término objeto comercial jerárquico hace referencia a un objeto comercial completo, incluidos todos los objetos comerciales hijo que el objeto contiene a cualquier nivel. El término objeto comercial individual hace referencia a un sólo objeto comercial, con independencia de los objetos comerciales hijo que pueda contener o en los que esté contenido. El término objeto comercial de nivel superior hace referencia al objeto comercial individual situado en lo más alto de la jerarquía y que no tiene ningún objeto comercial padre.
Recuperación de objetos comerciales

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.

Recuperación de objetos comerciales por contenido

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.

Creación de objetos comerciales

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:

  1. Crea recursivamente cada objeto comercial hijo de cardinalidad simple contenido con propietario en la base de datos.
  2. Procesa cada objeto comercial hijo de cardinalidad simple contenido sin propietario.
  3. Crea el objeto comercial de nivel superior en la base de datos.
  4. Crea los objetos comerciales hijo de cardinalidad simple que guardan la relación padre/hijo en el hijo.
  5. Crea cada objeto comercial hijo de cardinalidad múltiple.
Modificación de objetos comerciales

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:

  1. Utiliza los valores de clave primaria del objeto comercial de origen para recuperar la entidad correspondiente de la base de datos.
  2. Actualiza recursivamente todos los hijos de cardinalidad simple del objeto comercial de nivel superior.
  3. Para los objetos comerciales hijo de cardinalidad simple que guardan la relación padre/hijo en el padre, el conector establece cada valor de clave foránea del padre en el valor de la clave primaria del correspondiente objeto comercial hijo de cardinalidad simple.
  4. Actualiza todos los atributos simples del objeto comercial recuperado, excepto aquéllos cuyo atributo correspondiente en el objeto comercial de origen contiene el valor CxIgnore.
  5. Establece todos los valores de clave foránea de cada hijo que guarda la relación padre/hijo en el hijo (tanto de cardinalidad simple como múltiple) en el valor de clave primaria del correspondiente objeto comercial padre.
  6. Procesa todas las matrices del objeto comercial recuperado.
Supresión de objetos comerciales

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:

  1. Suprime los hijos de cardinalidad simple.
  2. Suprime los hijos de cardinalidad múltiple.
  3. Suprime el objeto comercial de nivel superior.

Proceso de sucesos de aplicación

El conector maneja los sucesos Crear, Actualizar y Suprimir generados por la aplicación de la manera descrita a continuación.

Notificación para Crear

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.

Notificación para Actualizar

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.

Notificación para Suprimir

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.

Recuperación de objetos comerciales para el proceso de sucesos

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.

Nota:
Si la clave de objeto no utiliza el par nombre_valor, las claves contenidas en el campo de claves de objeto deben seguir el mismo orden que las claves contenidas en el objeto comercial.

Notificación de sucesos

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.

Nota:
El usuario debe añadir los desencadenantes a la base de datos como parte del procedimiento de instalación.

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.

Tabla 1. Maneras de realizarse el archivado
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.

Manejo de conexiones perdidas de base de datos

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:

Proceso de datos dependientes del entorno local

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.

Nota:
Para habilitar juegos de códigos de caracteres diferentes, consulte la documentación de Manugistics.

Copyright IBM Corp. 1997, 2004