Solución de alta performance para el ingreso de datos en un depósito en tiempo real, Parte 2: Explore las opciones de integración con las tablas de representación y mensajes de WebSphere MQ

Integración de InfoSphere Replication Server y InfoSphere DataStage para ingresar poco a poco datos al depósito

El ingreso de datos en un depósito con cambios desde la base de datos fuente puede ser muy caro. Si la extracción sólo se realiza con SQL, no hay forma de identificar fácilmente las filas que han sido modificadas. IBM InfoSphere™ Replication Server puede detectar los datos modificados simplemente leyendo el registro de la base de datos. Esta series le muestra cómo utilizar InfoSphere Replication Server para extraer de modo eficaz sólo los datos modificados y cómo transferir los cambios a IBM InfoSphere DataStage® para ingresarlos al depósito de datos. Part 1 de la serie de dos partes suministró una visión general de estos productos y de cómo estos pueden trabajar en conjunto. En esta Parte 2, explore dos opciones de integración: el uso de mensajes de WebSphere® MQ con InfoSphere Event Publisher y el uso de tablas de representación.

Anand Krishniyer, Staff Software Engineer, InfoSphere Replication, IBM

Anand Krishniyer photoAnand Krishniyer trabaja como ingeniero de servicios de staff de la InfoSphere Replication development organization. Como miembro del equipo de administración, sus responsabilidades abarcan el desarrollo de elementos de línea, así como el suministro de asistencia técnica a los clientes con respecto a la instalación y la configuración de Replication Server. Anteriormente, Arand trabajó como jefe de proyectos para el Integration and Tools team de una compañía de administración de procesos, Savvion (ahora parte de Progress Software).



James Yau, Technical Solution Architect, InfoSphere Information Server, IBM

James Yau photoJames Yau trabaja como arquitecto senior certificado de soluciones del producto InfoSphere Information Server DataStage. Actualmente, forma parte de la organización InfoSphere Technology Enablement responsable del desarrollo y el suministro de contenido de Information Server Boot Camp. James posee muchos años de experiencia en el asesoramiento de la Suite de productos de Information Server, incluyendo InfoSphere DataStage, QualityStage, Information Analyzer, y FastTrack. Anteriormente, James formaba parte de un equipo de habilitación técnica de asociados de negocios, en el cual era el administrador de los programas técnicos de InfoSphere Information Server. Entre sus tareas se encontraban el desarrollo y el suministro del contenido de los cursos que se dictaban de diversas formas, como capacitación impartida por instructores, en línea y de auto aprendizaje. Anteriormente a esto, James tuvo diversos roles, que abarcaron desde el desarrollo de software hasta la administración de marketing, tanto dentro como fuera de IBM.



Tony Lee, Technical Solution Architect, IBM

Tony Lee trabaja como especialista senior certificado de IT en el InfoSphere Replication Center of Competency (COC), un equipo de la organización de desarrollo de InfoSphere Replication. Como miembro del COC, Tony ha brindado asistencia técnica a los clientes y asociados empresariales sobre tecnologías de replicación de InfoSphere. Tony posee muchos años de experiencia en el asesoramiento de diversas tecnologías de replicación de IBM, incluyendo la replicación de SQL replicación Q, y la más reciente, InfoSphere Change Data Capture. Anteriormente, Tony suministró asistencia técnica sobre la administración de información a clientes y asociados por casi una década, abarcando una amplia gama de temas, desde el ajuste de DB2, hasta el servidor de información y la administración de datos maestros. Antes de convertirse en asesor, Tony tuvo varios puestos diferentes en el área de la administración de la información, que abarcaron desde la administración hasta el desarrollo.



31-03-2014

Antes de comenzar

Sobre este tutorial

El artículo Part 1 de esta serie trató el tema de las tecnologías de los productos InfoSphere Replication Server y DataStage, y de las diferentes formas de integrar los dos para ingresar datos al depósito. Tambié abarcó los pros y los contras de las diversas opciones de integración. En este tutorial Part 2, explore las dos opciones de integración específica: el uso de mensajes de MQ y el uso de tablas de representación. Este tutorial lo guía en la configuración de cada una de estas opciones de integración con capturas de pantalla e instrucciones paso a paso. Este tutorial no profundiza sobre los detalles de cómo escribir una tarea DataStage o sobre cómo configurar la replicación, sino que se centra en las técnicas de integración.

Prerrequisitos

Los escenarios descriptos en el tutorial pueden desarrollarse en el siguiente entorno:

Sistema operativo y hardware
  • AIX®, Version 5.3, sistema operativo con hardware de arquitectura de Common Hardware Reference Platform (CHRP) de 64 bits
  • Windows XP Professional Service Pack 3 con procesador Intel de 32 bits
Software
  • IBM InfoSphere Replication Server 9.7
  • IBM Information Server 8.1 Server for AIX (con Connectors rollup patch 2 para conector de DB2® )
  • IBM Information Server 8.1 Client for Windows® (con Connectors rollup patch 2 para conector de DB2)
  • WebSphere MQ, Version 7 (para escenario MQ)

Integración en tiempo real con InfoSphere Event Publisher

Configuración de Event Publisher

En la Part 1 se analizaron las tecnologías de los productos InfoSphere Replication Server y InfoSphere DataStage y las diferentes formas de integrar ambos para ingresar datos al depósito. También se proporcionaron los pros y los contras de las diversas opciones de integración. De ser necesario vuelva a leer este artículo antes de comenzar a configurar las opciones de integración.

En la Figura 1 se muestra una configuración de muestra en tiempo real. La configuración de Event Publisher en la cual la fuente de datos reside en un sistema Windows svl-akrishni2. El operational data store (ODS) en el cual se ejecuta InfoSphere DataStage se encuentra en un sistema AIX scoobydoo. La ubicación del depósito de datos no es importante y puede configurarse en un sistema completamente diferente.

Figura 1. Detalles de la integración de Event publication

El programa Q Capture captura las modificaciones en las tablas de origen Product and Inventory desde el registro y las publica en una cola de WebSphere MQ. A esta cola nos referimos como la cola send SALES_DATA_TO_DATASTAGE) y se define en un administrador de colas QMEP en el sistema svl-akrishni2 de Windows. Este administrador de colas QMEP envía los mensajes a través de una cola al sistema AIX. A esta cola nos referimos como la cola receive (SALES_DATA_TO_DATASTAGE, la cual tiene el mismo nombre que la cola send) y es definida en un administrador de colas QMDS en el sistema AIX.

La publicación del evento se configura de modo que el mensaje se encuentre en formato comma-separated value (CSV), y cada mensaje contenga una operación de fila sencilla, como INSERT, UPDATE, o DELETE. En el Listado 1 se muestra un mensaje MQ de muestra en la cola.

Listado 1. Mensaje MQ de muestra en la cola

10,"IBM","2009355","021255984000","AKRISHNI","PRODUCT","REPL","0000:0000:0000:0000:5ae5",
"0000:87a0:c204:0000:0000","2009-12-21-10.12.52",,0000,"100-201-01","Ice Scraper, 
Windshield 4
inch",3.99,,,,,"100-201-01","Ice Scraper1, Windshield 4inch",3.99,,,," <product
pid=""100-201-01"" ><description><name>Ice Scraper,Windshield 4
inch</name><details> Basic Ice Scraper 4 inches wide, foam handle
</details><price>3.99</price></description></product>"

Como se describió en la Part 1, las primeras 12 columnas en el mensaje son encabezados de replicación, y las columnas restantes son los datos modificados capturados de la tabla fuente. Los encabezados de las columnas 6 y 7 son importantes para su configuración. El encabezado en la columna 6 es el nombre de la tabla fuente, y el encabezado en la columna 7 es un código de 4 caracteres para la operación SQL que causa la modificación en la fila. El código de cuatro caracteres ISRT indica insert. REPL indica update. DLET indica las operaciones delete. Si desea una explicación detallada de todos los encabezados del mensaje, consulte la información sobre IBM InfoSphere Event Publisher en el DB2 V9.7 Information Center (vea Resources).

La tarea DataStage hace lo siguiente:

  1. Lee los mensajes de la cola receive en el sistema AIX
  2. Analiza la gramática de los mensajes
  3. Transforma los datos
  4. Ingresa datos en los conjunto de datos, que son archivos del sistema operativo creados por el escenario del conjunto de datos

Los datos modificados correspondientes a cada uno de los tipos de los tres tipos de operaciones sobre las filas de una tabla de origen particular (INSERT, UPDATE, o DELETE) son ingresados en diferentes conjuntos de datos. De modo que por cada tabla de origen, la tarea DataStage genera tres conjunto de datos con los respectivos insert, update, o delete data.

Nota: El ejemplo supone que no hay dependencias entre los mensajes, como restricciones referenciales. La orden de procesar un mensaje INSERT puede ser distinta a la orden de procesar un mensaje DELETE. Si hay dependencias en los mensajes, todos los mensajes deben ingresarse en un único conjunto de datos para preservar la orden, y la tarea de DataStage debe asegurarse de que los mensajes sean procesados en el orden correcto.

Configuración de Event Publisher

Los pasos de alto nivel para la configuración de Event Publisher son los siguientes:

  1. Creación de los objetos de DB2 (las tablas fuente)

    Nota: Este primer paso sólo es necesario para este escenario de ejemplo; no es un paso en la configuración. Normalmente, los objetos de DB2 ya existirían, y usted identificaría las tablas fuente y determinaría el subconjunto de datos a replicar.
  2. Creación de la configuración de Event Publisher mediante los siguientes pasos:
    1. Configuración de MQ
    2. Configuración de Event Publisher
    3. Ejecución de Event Publisher
  3. Creación de la configuración de DataStage mediante los siguientes pasos:
    1. Configuración de MQ Connector
    2. Configuración del primer escenario de transformación
    3. Configuración del segundo escenario de transformación
    4. Configuración de los escenarios de conjunto de datos
  4. Verificación en tiempo real de la configuración mediante los siguientes pasos:
    1. Inicio de Event Publisher
    2. Importación de la tarea DataStage
    3. Compilación de la tarea DataStage
    4. Ejecución del script de prueba para incorporar una modificación en los datos de origen
    5. Ejecución de la tarea DataStage
    6. Verificación de los datos en los conjuntos de datos para mostrar que tenían contenido

Las siguientes secciones describen el ejemplo en detalle. Todos los scripts necesarios para configurar esta muestra están incluidos en este tutorial en la sección Download.

Creación de los objetos de DB2

Para la configuración de prueba, utilizará una base de datos que se le proporcionará denominada SALES e importará las tablas PRODUCT e INVENTORY, las cuales son archivos ixf suministrados con la descarga. Estas son las tablas de origen para el escenario. Como alternativa, usted puede utilizar las tablas PRODUCT y INVENTORY que vienen la base de datos de muestra de DB2 V9.7, o puede importar las tablas a otra base de datos elegida por usted.

Para importar las tablas Product e Inventory, cambie los directorios por setupDB en el archivo adjunto descargado, donde encontrará el archivo product.ixf y el archivo inventory.ixf. Abra una ventana de comandos de DB2 ingresando db2cmd, y ejecute los siguientes comandos:

import from product.ixf of ixf create into product import from inventory.ixf of
                    ixf create into inventory

Configuración del administrador de colas de WebSphere MQ h

Comience a crear la configuración de Event Publisher configurando MQ de la siguiente forma:

  1. Cree el administrador de colas QMEP de WebSphere MQ en el sistema de origen svl-akrishni2 ingresando el comando Crtmqm.exe QMEP.
  2. Inicie el administrador de colas ingresando el comando Strmqm.exe QMEP.
  3. Cree el resto de los objetos MQ en el sistema de origen ingresando el comando runmqsc.exe QMEP < mqObjectsPublisher.in

    El script mqObjectsPublisher.in se encuentra disponible en el directorio RealTimeInt\setupEP de la descarga. Este script crea todos los objetos MQ en el sistema de origen (colas, canal, y oyente).

  4. Cree el administrador de colas y los objetos MQ en el sistema destino (subscriptor) ingresando lo siguiente:
     Createmqm QMDS Strmqm QMDS Runmqsc QMDS <
                                mqObjectsSubscriber.in

    El script mqObjectsSubscriber.in se encuentra disponible bajo el directorio RealTimeInt\setupEP de la descarga que encontrará junto a este tutorial.

Configuración de Event Publisher

Complete los siguientes pasos para configurar el EP.

  1. Cree los objetos de la replicación ejecutando los siguientes scripts usando el programa ASNCLP (la herramienta de administración de la replicación de la línea de comando) en una ventana de comando de DB2 : asnclp -f crtCtlTables.in
  2. Cree todas las tablas de control necesarias para la configuración de la aplicación ingresando asnclp -f crtQMapAndPublications.in

    Los scripts crtCtlTables.in y crtQMapAndPublications.in se encuentran disponibles en el RealTimeInt\setupEP de la descarga. Estos scripts crean una correlación de cola (una correlación de objetos MQ para objetos de replicación Q) y las publicaciones para las tablas Product e Inventory.

Ejecución de Event Publisher

Inicie el EP (programa Q Capture) ingresando el siguiente comando en una ventana de comandos de DB2: asnqcap CAPTURE_SERVER=SALES CAPTURE_SCHEMA=ASN

Esto inicia el programa Q Capture, el cual comienza a publicar las modificaciones en las tablas Product e Inventory. Usted puede además utilizar el script startQCapture.bat proporcionado en el directorio RealTimeInt\setupEP de la descarga de este tutorial.

Configuración de las tareas de DataStage

En las tareas de DataStage, usted utiliza un conector de WebSphere MQ para leer los mensajes de la cola receive y dos escenarios de transformación para analizar gramaticalmente los mensajes, como se observa en la Figura 2. El primer escenario de transformación se utiliza como un control de selección para separar los mensajes relacionados con una publicación particular, como una tabla de origen particular. El segundo escenario de transformación es utilizado como control de selección para separar el mensaje relativo a una operación particular, como insert, update, o delete, en cada tabla. Los datos separados, los cuales corresponden a cada fila en la tabla de origen, se ingresan en el conjunto de datos correspondiente (correspondiente a las operaciones insert, update, o delete). Use el escenario del conjunto de datos para ingresar los datos procesados correctos, porque los conjuntos de datos son formatos de archivo nativos que consisten de un único archivo de cabecera que hace referencia a los datos actuales que pueden dividirse en múltiples particiones paralelas de DataStage. Este formato, por lo tanto ya puede ser utilizado por DataStage para ser ejecutado en entornos paralelos, y por lo tanto este formato brinda la mejor performance.

Figura 2. Tarea DataStage de Event Publication

El procesamiento de la trasformación actual que realiza la tarea DataStage principal puede utilizar estos datos como entrada. Generalmente el procesamiento de DataStage separa los datos en base a la operación de la fila (insert, update, o delete). Sin embargo, si hay restricciones referenciales de los datos de origen, los datos modificados deben ser ingresados en un único conjunto de datos, en lugar de tres conjuntos de datos diferentes.

Las siguientes secciones describen en mayor detalle los pasos para configurar la tarea DataStage.

Configuración de MQ Connector

La siguiente lista muestra la configuración del MQ Connector:

  • Propiedades de la conexión
    • Modo = servidor
    • Administrador de colas = QMDS
    • Nombre de usuario = db2inst1
  • Propiedades de uso
    • Nombre de la cola = SALES_DATA_To_DATASTAGE
    • Modo de acceso = el mismo que en la definición de la cola
    • Tiempo de espera = 1
    • Cantidad de mensajes = -1
    • Modo de lectura del mensaje = Delete

A continuación encontrará algunas notas sobre los elementos de la configuración:

Tiempo de espera
Use esta propiedad para especificar la cantidad máxima de segundos para esperar la llegada de un nuevo mensaje a la cola input. El valor por omisión es -1, el cual especifica una cantidad indefinida de tiempo. Para el ejemplo, fije el valor en 1 segundo.
Cantidad de mensajes
Use esta propiedad para especificar la cantidad de mensajes (no filas) a recuperar de la cola input. Para el ejemplo, fije el valor en -1. Un valor de -1 especifica una cantidad indefinida de mensajes. Un valor de 0 especifica ningún mensaje. Usted puede especificar números enteros entre -1 y 999999999 para la cantidad de mensajes. Para el ejemplo, la cantidad de mensajes es -1 y el tiempo de espera es 1 de modo que el MQ Connector puede traer todos los mensajes que hayan llegado a la cola.
Modo de lectura de mensajes
Use esta propiedad para especificar cómo se leen los mensajes en la transacción actual. Para el ejemplo, fije esta opción en Delete (lectura destructiva). Usted puede además elegir la opción Move to work queue de la lista desplegable si los mensajes deben preservarse.

Cree una columna denominada PayLoad de tipo Varchar con tamaño 1000, como se muestra en la Figura 3. Dado que este es un mensaje de texto, el tamaño se refiere a la cantidad de caracteres. Para el ejemplo, sólo la porción de mensajes que siguen al mensaje de cabecera es importante.

Figura 3. configuración del MQ Connector

Configuración del primer escenario de transformación

Configuración del escenario de transformación SeparatePayLoad_Based_On_TableName como se observa en la Figura 4.

Figura 4. Configuración del primer escenario de transformación

Tenga en cuenta lo siguiente sobre la configuración de ejemplo:

  • Defina una variable de escenario denominada SCHEMANAME, y establézcala en la quinta columna de la entrada PayLoad.
  • Defina una variable de escenario denominada TABLENAME, y establézcala en la sexta columna de la entrada PayLoad.
  • En la Figura 4, hay dos enlaces de salida desde el escenario de transformación SeparatePayLoad_Based_On_TableName. Dado que cada uno de estos enlaces va a otro escenario de transformaci´n, use la variable de escenario SCHEMANAME y TABLENAME como control de selección para separar mensajes relacionados a las tablas Product e Inventory.

Configure las restricciones del escenario, como se observa en la Figura 5.

Figura 5. Las primeras restricciones del escenario de transformación

Tenga en cuenta que todos los datos no numéricos en los mensajes se encuentran entre comillas. De modo que cuando usted compare el uso de la variable de escenario TABLENAME, encierre el nombre de la tabla actual (tablas PRODUCT e INVENTORY) en un nuevo par de comillas.

Este nivel transformer separa los mensajes de acuerdo al nombre de la tabla de origen. El mensaje de muestra se puede observar en el Listado 2.

Listado 2. Mensaje de muestra

10,"IBM","2009355","021255984000","ADMIN","PRODUCT","REPL","0000:0000:0000:0000:5ae5",
"0000:87a0:c204:0000:0000","2009-12-21-10.12.52",,0000,"100-201-01","Ice Scraper, 
Windshield 4 
inch",3.99,,,,,"100-201-01","Ice Scraper1 Windshield 4inch",3.99,,,,"
<productpid=""100-201-01""><description><name>Ice Scraper,
Windshield 4 inch</name><details>Basic Ice Scraper 4 inches wide, foam
handle</details><price>3.99</price></description></product>"

Tenga en cuenta el siguiente mensaje de muestra:

  • La variable de escenario SCHEMANAME está definida como Field(Read_MQPayLoad.PayLoad, ",",5). La quinta columna en un mensaje es el nombre de la tabla.
  • La variable de escenario TABLENAME está definida como Field(Read_MQPayLoad.PayLoad, ",",6). La sexta columna en un mensaje es el nombre de la tabla.
  • Todos los datos no numéricos en los mensajes están encerrados entre comillas. De modo que cuando defina la restricción SCHEMANAME o TABLENAME, coloque los nombres entre un par adicional de comillas.
  • La séptima columna en un mensaje es siempre el tipo de operación: ISRT, REPL, o DLET para insert, update, o delete, respectivamente.
  • Los datos de origen comienzan en la Columna 13.

Configuración del segundo escenario de transformación

Después de separar los mensajes relacionados a las tablas PRODUCT e INVENTORY, configure los niveles transformer SeparatePayLoad_Based_On_I_U_D_Operation1 y SeparatePayLoad_Based_On_I_U_D_Operation2 para analizar gramaticalmente los datos de las operaciones de las filas (insert, update y delete). La Figura 6 muestra cómo el escenario de transformación SeparatePayLoad_Based_On_I_U_D_Operation1 se configura para analizar gramaticalmente las columnas de la tabla PRODUCT.

Figura 6. Configuración del segundo escenario de transformación

Tenga en cuenta lo siguiente sobre la configuración del segundo escenario de transformación:

  • Defina una variable denominada OPERATION, y establézcala en la séptima columna de la entrada PayLoad.
  • Tiene tres enlaces de salida desde el escenario de transformación SeparatePayLoad_Based_On_I_U_D_Operation1, como se observa en la Figura 2. Dado que cada uno de estos enlaces va al escenario de un conjunto de datos, use la variable OPERATION como control de selección para separar los mesajes relativos a las operaciones insert, update, y delete.
  • Defina todas las columnas en la tabla Product, y correlaciónelas con las columnas individuales en el PayLoad. Por ejemplo, para la operación insert, correlacine las columnas PID, NAME, PRICE, PROMOPRICE, PROMOSTART, y PROMOEND con las columnas en el PayLoad, comenzando en la posición 19.
  • Para la operación insert, los valores anteriores de todas las columnas en la tabla Product están vacíos, de modo que las columnas 13 a 18 están vacías.
  • Para la operación delete, los valores posteriores para todas las columnas están vacíos, de modo que la columnas 19 y las siguientes están vacías.
  • Las operaciones actualizadas tienen valores anteriores y posteriores.
  • Los valores no numéricos de las columnas están encerrados entre comillas en el mensaje MQ.

La Figura 7 muestra la correlación de las columnas para la operación update

Figura 7. Correlación de las columnas para operación update

Tenga en cuenta lo siguiente sobre la correlación de columnas para la operación update:

  • La Figura 7 muestra correlaciones de columnas para la operación update (palabra clave de las operaciones REPL).
  • Las posiciones 13 a 18 en PayLoad tienen los valores anteriores y las posiciones 19 a 24 tienen los valores posteriores.

La Figura 8 muestra cómo los datos de las operaciones están separados en la tabla Inventory.

Figura 8. Separación de los datos de las operaciones en la tabla Inventory

Tenga en cuenta que la configuración del escenario de transformación SeparatePayLoad_Based_On_I_U_D_Operation2 separa los datos de las operaciones en la tabla Inventory.

Configuración de los escenarios de los conjuntos de datos

Complete los conjuntos de datos insert, update y delete para la tabla Inventory como se describe en esta sección. La Figura 9 muestra cómo establecer las propiedades de los conjuntos de datos.

Figura 9. Propiedades de los conjuntos de datos

Tenga en cuenta lo siguiente sobre la configuración de las propiedades de los conjunto de datos:

  • La Figura 9 muestra las propiedades del escenario de los conjuntos de datos para los datos desde la operación insert en la tabla Product.
  • La política de actualización está determinada como Append. Asegúrese de que la política de actualización para todos los conjunto de datos esté establecida como Append.
  • Establezca la propiedad del archivo como el nombre adecuado con ruta completa.
  • El archivo en la propiedad del archivo será creado si no existe. Sin embargo, los directorios especificados en la ruta ya deberían existir en el sistema de archivos.

La Figura 10 muestra la configuración de las columnas del escenario del conjunto de datos Inserts_DataSet1.

Figura 10. Configuración de las columnas del conjunto de datos insert

La Figura 11 muesta la configuración de las columnas del conjunto de datos update.

Figura 11. Configuración de las columnas del conjunto de datos update

Tenga en cuenta lo siguiente sobre la configuración de las columnas del conjunto de datos update:

  • La Figura 11 muestra la configuración de las columnas del escenario del conjunto de datos Update_DataSet1.
  • Los valores de imágenes anteriores y posteriores son capturados para las operaciones update.

La Figura 12 muestra la configuración de las columnas del conjunto de datos delete

Figura 12. Configuración de las columnas del conjunto de datos deletes

Tenga en cuenta lo siguiente sobre el conjunto de datos delete:

  • La Figura 12 muestra las definiciones de las columnas para Deletes_DataSet1.
  • Estos son valores de imágenes anteriores en la tabla Product.

Los pasos para probar la configuración en tiempo real

Los siguientes pasos describen en un nivel superior lo que se necesita para probar la configuración en tiempo real. Los pasos se describen con mayor detalle en las siguientes secciones.

  1. Inicio de Event Publisher
  2. Importación de la tarea de DataStage
  3. Compilación de la tarea de DataStage
  4. Ejecución del script de prueba para incorporar una modificación en los datos de origen
  5. Ejecución de la tarea de DataStage
  6. Verificación de los datos en los conjuntos de datos para mostrar que están completos

Inicio de Event Publisher

Complete los siguientes pasos para iniciar Event Publisher.

  1. Abra una ventana de comandos de DB2 y cambie de directorio a RealTimeInt\setupEP desde la descarga.
  2. Inicie Event Publisher ejecutando el script startQCapture.bat .
  3. Asegúrese de recibir el mensaje ASN0572I que el programa inicializó exitosamente, como se observa en la Figura 13.
Figura 13. Inicio de Q Capture en la ventana de comandos de DB2

Importación de la tarea de DataStage

Complete los siguientes pasos para importar la tarea de DataStage.

  1. Inicie DataStage Designer, e importe la tarea RealTimeDataInt.dsx navegando hasta el directorio RealTimeInt desde la descarga.
  2. Haga clic en OK en la ventana Import de DataStage para completar la importación de la tarea como se observa en las Figuras 14 y 15.
Figura 14. Importación de la tarea de DataStage
Figura 15. Tarea de DataStage More Import

Compilación de la tarea de DataStage

Complete los siguientes pasos para compilar la tarea de DataStage.

  1. Si usted utilizó un Q Manager o el nombre de cola receive es diferente, cambie estos valores en el escenario de MQ Connector haciendo doble clic en el escenario para llegar a la página de propiedades.
  2. Si ejecuta la tarea en una plataforma Windows,® cambie las propiedades de archivo de todos los escenarios del conjunto de datos: Inserts_DataSet1, Updates_DataSet1, Deletes_DataSet1, Inserts_DataSet2, Updates_DataSet2, y Deletes_DataSet2.
  3. Compile la tarea de DataStage haciendo clic en Compile en el menú DataStage Designer, como se observa en la Figura 16.
Figura 16. Compilación de la tarea de DataStage

Ejecución del script de prueba para la incorporación de modificaciones en los datos de origen

Complete los siguientes pasos para ejecutar el script de prueba.

  1. Abra una ventana de comandos de la DB2, y cambie de directorio a RealTimeInt\setupEP.
  2. Ejecute el script updateSourceTables.sql. Este script realiza una insert, update, y delete en las tablas Product e Inventory.

Ejecución de la tarea de DataStage

Complete los siguientes pasos para ejecutar la tarea de DataStage.

  1. Inicie el DataStage Director haciendo clic en el acceso directo All Programs > IBM Information Server > IBM WebSphere DataStage y QualityStage Director .
  2. Ejecute la tarea haciendo clic en el ícono Run en el menú DataStage Director, como se observa en la Figura 17.
Figura 17. Ejecute la tarea de DataStage

Verificación de los datos en los conjuntos de datos para mostrar que están completos

Visualice el registro de estado de la tarea haciendo clic con el botón derecho en la tarea y haciendo clic en View Log de DataStage Director, como se observa en la Figura 18.

Figura 18. Visualice el registro de la tarea

Usted puede también verificar que su tarea se ha ejecutado exitósamente desde Designer, el cual muestra el color del flujo de datos en verde con la cantidad de filas procesadas entre los diferentes stages. La Figura 19 muestra que había 6 mensajes procesados y un mensaje por cada operación: insert, update, y delete para la tabla Product e Inventory.

Figura 19. Verificación del estado de las tareas

Usted puede visualizar el conjunto de datos haciendo clic con el botón derecho en el conjunto de datos y haciendo clic en View data. La Figura 20 muestra los datos en Updates_DataSet1 para la tabla Product.

Figura 20. Actualizaciones de los conjuntos de datos

De modo similar usted puede verificar los datos modificados propagados visualizando los datos en cada uno de los conjunto de datos.


Integración de datos en el escenario con replicaicón SQL

Configuración de la replicación SQL

En el ejemplo de configuración de integración en escenario, la configuración de la replicación SQL que contiene los datos de origen se encuentra en un sistema Windows (svl-akrishni2). El operational data store (ODS) en el cual se ejecuta InfoServer DataStage se encuentra en el sistema AIX scoobydoo. La configuración del depósito de datos no se muestra en la configuración. La posición del depósito de datos no es importante y puede configurarse en un sistema completamente diferente.

El programa SQL capture captura los cambios en las tablas de origen (las tablas Product and Inventory de la base de datos SALES en la configuración de ejemplo) del registro y completa la tabla change data (CD) en la misma base de datos fuente SALES. La solicitud SQL lee la tabla change data desde la base de datos origen y completa la tabla de representación (tabla CCD) en la base de datos destino STAGEDB. La base de datos SALES y la captura SQL están en el sistema Windows (svl-akrishni2), y STAGEDB y el programa SQL apply están en el sistema AIX. La conexión a la base de datos SALES está catalogada en el sistema destino (el sistema scoobydoo AIX). La solicitud SQL está configurada para ser conducida por eventos. La solicitud SQL aplica los cambios en la tabla CCD de origen en respuesta a un evento, como una fila en la tabla de control IBMSNAP_SUBS_EVENT con una marca de tiempo actualizada.

La tarea DataStage que se está ejecutando en el sistema AIX extrae desde la tabla CCD en la base de datos STAGEDB y escribe a tres conjuntos de datos diferentes, dependiendo de si la operación es de tipo insert, update, o delete. Si la extracción de la tabla CCD es exitosa, la tarea procede a cortar la tabla CCD. Si todas las extracciones y cortes son exitosos en todas las tablas CCD, el evento en la tabla IBMSNAP_SUBS_EVENT que dispara la solicitud SQL es actualizada de modo que la solicitud SQL pueda procesar otro ciclo de replicación.

Tenga en cuenta que el programa de solicitudes SQL se activa cada cinco minutos para verificar las actualizaciones en la tabla IBMSNAP_SUBS_EVENT. De modo que si usted programa la tarea Staged Integration DataStage para ejecutar automáticamente a través de un programador (DataStage Director o un programador externo), debería haber un intervalo de cinco minutos entre los ciclos consecutivos. Un intervalo menor a cinco minutos entre dos ciclos de tareas consecutivas Staged Integration DataStage podría dar como resultado pérdida de datos, porque la tarea DataStage podría cortar la tabla CCD mientras que el programa SQL apply está aplicando los cambios a la misma.

Configuración de la replicación SQL

Los pasos de alto nivel para la configuración de replicación SQL son los siguientes:

  1. Creación de objetos DB2

    Nota: Este primer paso es necesario solo para este escenario de ejemplo; no es un paso para la configuración. Normalmente, los objetos de DB2 ya existirían, y usted identificaría las tablas de origen y determinaría el subconjunto de datos a replicar.
  2. Configuración de la replicación SQL y creación de los objetos de replicación SQL
  3. Operación de la captura y de la solicitud SQL
  4. Configuración de DataStage

Las siguientes secciones describen el ejemplo en detalle. Todos los scripts necesarios para configurar esta muestra están incluido con este tutorial en la sección Download .

Creación de los objetos de la DB2

Para la configuración de muestra, usted utilizará una base de datos suministrada denominada SALES e importará las tablas PRODUCT y INVENTORY, que son archivos ixf suministrados con la download. Estas son las tablas de origen para el escenenario. Otra alternativa es utilizar las tablas PRODUCT e INVENTORY que vienen con la base de datos de muestra DB2 V9.7, o puede importar las tablas a otra base de datos de su elección.

Para importar las tablas Product e Inventory, cambie los directorios a setupDB en el documento adjunto descargado, donde encontrará el archivo product.ixf y el archivo inventory.ixf. Abra una ventana de comando de DB2 ingresando db2cmd, y ejecute los siguientes comandos:

 import from product.ixf of ixf create into product import from inventory.ixf of
    ixf create into inventory

Usted puede crear una base de datos destino STAGEDB en el sistema destino, como el scoobydoo de ejemplo en un sistema AIX, o puede utilizar una base de datos de su elección como la base de datos destino de replicación SQL.

Configuración de la replicación SQL y creación de objetos de replicación SQL

Usted puede configurar la configuración de replicación SQL utilizando la herramienta de administración de replicación GUI (el centro de replicación) o utilizando la herramienta de línea de comando asnclp. Los siguientes pasos describen cómo establecer la replicación SQL usando la herramienta de línea de comando.

  1. Para crear los objetos de replicación SQL, catalogue la conexión a la base de datos de origen SALES en el sistema destino, el cual es el sistema scoobydoo AIX .
  2. Ejecute todos los scripts desde el sistema destino. Para el ejemplo, catalogue la conexión a la base de datos SALES en el sistema destino ingresando los siguientes comandos en el sistema destino:
     db2 catalog tcpip node srcnode remote IPADDRESS server DB2_PORT
            db2 catalog db sales as sales at node srcnode

    IPADDRESS es la dirección IP del sistema de origen, como svl-akrishni2, y DB2_PORT es el número de puerto de la instancia del administrador de la base de datos en el sistema de origen.

  3. Ingrese asnclp –f crtCtlTablesCaptureServer.asnclp en una ventana de comandos de DB2 en el sistema destino. El script crtCtlTablesCaptureServer.asnclp crea las tablas de control de captura en la base de datos de origen SALES.
  4. Ingrese asnclp –f crtCtlTablesApplyCtlServer.asnclp en una ventana de comandos de DB2 en el sistema destino. El script crtCtlTablesApplyCtlServer.asnclp crea las tablas de control de aplicaciones en la base de datos destino STAGEDB.
  5. Ingrese asnclp –f crtRegistration.in en una ventana de comandos de DB2 en el sistema destino. El script crtRegistration.asnclp registra las tablas de origen Product y Inventory.
  6. Ingrese asnclp –f crtSubscriptionSetAndAddMembers.in en una ventana de comandos de DB2 en el sistema destino. El script crtSubscriptionSetAndAddMembers.asnclp crea un conjunto de suscripciones e incorpora los dos miembros (uno por cada tabla de origen).

Ejecución de la captura y solicitud SQL

Complete los siguientes pasos para ejecutar la captura y solicitud SQL.

  1. Inicie el servidor de capturas ingresando asncap CAPTURE_SERVER=SALES en una ventana de comandos de DB2 en el sistema de origen. El programa de capturas SQL comienza a capturar las modificaciones en las tablas Product e Inventory. En su lugar, usted puede utilizar el script startSQLCapture.bat suministrado en el directorio StagedInt\setupSQLRep de la descarga.
  2. Inicie el servidor de capturas SQL ingresando asnapply CONTROL_SERVER=STAGEDB APPLY_QUAL=AQ00 en una ventana de comandos de DB2 en el sistema destino. El programa de solicitudes SQL comienza a aplicar las modificaciones de las tablas Product e Inventory en las tablas CCD. De otro modo, puede utilizar el script startSQLApply.sh o startSQLApply.bat suministrado en el directorio StagedInt\setupSQLRep de la descarga.

Configuración de DataStage

Para el ejemplo, la tarea de DataStage para la integración en el escenario utiliza una tarea en secuencias, como se observa en la Figura 21, para encadenar diferentes tareas (tareas paralelas y comandos de sistema operativo) para extraer y cortar tablas CCD y para disparar solicitudes SQL.

Figura 21. Integración en el escenario: tarea de DataStage

El escenario de actividades de la tarea Extract_From_StagedTable1 y Extract_From_StagedTable2 (uno para cada tabla CCD) llama una tarea paralela que extrae desde una tabla CCD y agrega los datos a tres conjuntos de datos diferentes basados en el tipo de operaciones insert, update, o delete. Si la tarea de extracción es exitosa, un escenario de comando execute es utilizado para ejecutar un script que corta la tabla CCD. Si el paso cortar es exitoso en todas las tablas CCD, un escenario de comando execute puede ejecutar un script que actualiza el evento en la tabla de control IBMSNAP_SUBS_EVENT en la base de datos destino STAGEDB. Un stage secuenciador asegura esto. Si la tarea de extracción o la tarea de corte no tiene éxito, un escenario de terminación detiene todas las tareas.

StageDataIntSQLRep es la tarea de secuencia maestra que controla que el flujo de todas las tareas en la integración en el escenario. La secuencia de la tarea comienza con dos escenarios de actividades de la tarea: Extract_From_StagedTable1 y Extract_From_StagedTable2. Estos escenarios de actividades de tareas llaman a las tareas paralelas extractFromProduct_CCD y extractFromInventory_CCD, repectivamente, para extraer datos de las tablas CCD.

Complete los siguientes pasos para completar la secuencia del escenario.

  1. Ingrese dos disparadores de expresión tipo condicional OK y por otra parte, respectivamente, en la etiqueta Job del escenario de la actividad de la tarea. El disparador Extract_OK lleva al paso corte, y el disparador Extract_Not_OK lleva a la terminación de la tarea. La Figura 22 muestra la etiqueta triggers de la actividad de la tarea Extract_From_StagedTable1.
Figura 22. Etiqueta Triggers del escenario de la actividad de la tarea
  1. Seleccione la opción Send STOP requests to all running jobs para este escenario, como se observa en la Figura 23. Todas las tareas están finalizadas.
Figura 23. Actividad terminación
  1. Ejecute el script prune_ProductCCDTable.sh, como se observa en el Listado 3, para cortar la tabla destino CCD para el Product de origen. Tenga en cuenta que usted debe establecer DB2PATH en el directorio de instalación de DB2 antes de utilizar la versión de Windows del script prune_ProductCCDTable.bat en la descarga del directorio StagedInt\scripts\Win .

Listado 3. Ejecución del script de la actividad de comando

 cd /home/db2inst1 . ./sqllib/db2profile db2 connect to STAGEDB user admin using
    temp4fvt db2 "delete from admin.PRODUCT_CCD"

como con el paso de extracción, el paso de corte tiene dos disparadores. El disparador Prune_OK1 lleva al paso de la señal del evento a través de un escenario de secuenciación de tareas, y Prune_Not_OK conduce a la finalización de la tarea. La Figura 24 muestra dos disparadores de expresión de tipo condicional OK y por otro lado, respectively.

Figura 24. Disparadores para el paso recortar

El disparador Prune_OK desde el comando execute Prune_From_StagedTable1 conduce a un secuenciador de tarea en All mode, como se observa en la Figura 25. Este secuenciador asegura que el disparador del evento es disparado solamente si los paso de extracción y corte de todas las tablas CCD para todos los miembros de un conjunto de suscripciones sean exitosas.

Figura 25. Disparador de recorte OK para el paso corte

El Listado 4 muestra el script del disparador del evento continueSQLApply.sh que dispara el SQLApply. Tenga en cuenta que necesita establecer DB2PATH para el directorio de instalación de la DB2 antes de usar la versión de Windows del script prune_ continueSQLApply.bat en la descarga en el directorio StagedInt\scripts\Win.

Listado 4. El script continueSQLApply.sh

 cd /home/db2inst1 . ./sqllib/db2profile db2 connect to STAGEDB user db2inst1 using
    temp4now db2 "update ASN.IBMSNAP_SUBS_EVENT set EVENT_TIME=CURRENT_TIMESTAMP,
    END_OF_PERIOD=CURRENT_TIMESTAMP WHERE EVENT_NAME=' DSEXTRACTDONE'"

Creación de una tarea paralela para la extracción desde CCD

Las tareas paralelas extractFromProduct_CCD y extractFromInventory_CCD extraen desde las tablas del escenario un conector de DB2. Las tareas utilizan un escenario de transformación para separar las filas basadas en la operación insert, update, o delete que se realizó en los datos. Las tareas escribir los datos en tres conjuntos de datos diferentes: uno para cada uno: insert, update y delete.

Se espera que las aplicaciones que consumen los datos desde la tarea de DataStage consuman estos conjuntos de datos. Generalmente el procesamiento de DataStage separa los datos en base a las operaciones de filas insert, update, o delete. Sin embargo, si hay restricciones referenciales en los datos de origen, los datos modificados deben ingresarse en un solo conjunto de datos en lugar de tres conjuntos de datos diferentes.

La Figura 26 muestra la tarea paralela utilizada en el ejemplo.

Figura 26. Tarea paralela que extrae desde la tabla Product CCD

Las siguientes secciones describen los pasos para que usted cree la tarea paralela.

Creación de definiciones de tabla

Complete los siguientes pasos para crear una definición de tabla.

  1. Cree una definición de tabla para las tablas PRODUCT_CCD y INVENTORY_CCD (CCD destino para las tablas de origen Product y Inventory seleccionando Import > Table Definitions > Start Connector Import Wizard, como se observa en la Figura 27.
Figura 27. Creación de una definición de tabla: inicio del asistente de importación de conector
  1. En el asistente de importación del conector, seleccione la opción DB2 Connector , como se observa en la Figura 28.
Figura 28. Creación de una definición de tabla: conector de DB2
  1. En la ventana de detalles de conexión, ingrese el nombre de la instancia, el nombre de la base de datos, la ID de usuario, y la contraseña, como se observa en la Figura 29.
Figura 29. Creación de definición de tabla: detalles de la conexión
  1. Si quiere pruebe la conexión para asegurarse de que los valores que ingresó son correctos.
  2. En el cuadro de diálogo de la fuente de datos, seleccione el nombre de la base de datos desde el menú desplegable, como STAGEDB (db2inst1), tal como se observa en la Figura 30.
Figura 30.Creación de definición de tabla: nombre de la base de datos
  1. Haga clic en el nombre del esquema debajo del cual se crearon las tablas CCD destino PRODUCT_CCD e INVENTORY_CCD, como se observa en la Figura 31.
Figura 31. Creación de la definición de tabla: nombre del esquema
  1. Select la tabla PRODUCT_CCD en el cuadro de diálogo de selección resultante, y haga clic en Import para importar la definición de tabla.
  2. Repita los Pasos para la importación de la definición de tabla para la tabla INVENTORY_CCD.

Configuración del conector de DB2

Complete los siguientes pasos para configurar el conector de DB2.

  1. Abra la ventana de propiedades del conector de DB2, como se observa en la Figura 32.
Figura 32. Propiedades del conector de DB2
  1. Cree la sentencia de selección SQL haciendo clic Build y Build new SQL (DB2 UDB SQL 8.2 Syntax), y deje los valores por omisión para el resto de las propiedades, como se observa en la Figura 33.
Figura 33. Conector de DB2: SQL builder
  1. En la ventana de SQL Builder, navegue hasta Table Definition en el panel de la izquierda, y navegue hasta la tabla PRODUCT_CCD debajo de la base de datos STAGEDB.
  2. Arrastre y suelte la tabla PRODUCT_CCD en el panel de la derecha.
  3. Seleccione Todas las columnas (antes de la imagen, después de la imagen, y las columnas IBMSNAP), y arrastre y suelte al panel Select Columns.
  4. Haga clic en OK para que SQL builder cree la sentencia de selección simple.

Configuración del escenario de transformación Process_I_U_D_Operations_Data

Después de reunir los datos de todas las columnas en la tabla PRODUCT_CCD, configure el escenario de transformación Process_I_U_D_Operations para separar los datos en base a las operaciones de las filas insert, update, o delete. La operación de fila se almacena como I, U, o D en la columna IBMSNAP_OPERATION de la tabla CCD. Usted puede utilizar I, U, o D para separar los datos de la fila.

Complete los siguientes pasos para configurar el escenario de transformación Process_I_U_D_Operations_Data.

  1. Establezca las restricciones en cada uno de los enlaces de salida desde el escenario de transformación para verificar si la operación es I, U, o D para cada dato de fila.
  2. Defina una variable de escenario denominada OPERATION, y establezca la derivación de la columna de entrada IBMSNAP_OPERATION arrastrando la columna IBMSNAP_OPERATION desde la entrada select_from_CCD hasta la columna Derivation de la variable de escenario, como se observa en la Figura 34.
Figura 34. Configuración del escenario de transformación
  1. Defina las restricciones para cada uno de los enlaces de salida desde el escenario de transformación, como se observa en la Figura 35.
Figura 35. Definición de restricciones del stage Transformer
  1. Correlacione las columnas en el escenario de transformación para la tabla PRODUCT_CCD, como se observa en la Figura 36.
Figura 36. Correlación de columnas en el escenario de transformación para la tabla PRODUCT_CCD

Tenga en cuenta lo siguiente sobre la correlación de columnas:

  • Defina todas las columnas desde la tabla PRODUCT como salida, y correlacione las mismas columnas desde el enlace de entrada Select_From_CCD.
  • Los datos de fila para las operaciones update tienen tanto valores de imagen previos como posteriores.
  • Los datos de fila para las operaciones insert tienen valores de imagen posteriores válidos. Las columnas Before-image están vacías.
  • Las operaciones Delete tienen valores before-image válidos.

Configuración de los escenarios de los conjuntos de datos

Complete los siguientes pasos para configurar los escenarios de los conjuntos de datos.

  1. Abra la ventana de propiedades del escenario de los conjuntos de datos para los datos desde una operación insert de la tabla Product. Tenga en cuenta que la política de actualización es Append.
Figura 37. Propiedades de los conjunto de datos para los conjunto de datos insert
  1. Verifique que la política de actualización para todos los conjunto de datos sea Append, como se observa en la Figura 38.
Figura 38. Definiciones de columnas del conjunto de datos insert

La Figura 39 muestra definiciones de columnas del escenario del conjunto de datos Update_DataSet. Tenga en cuenta que los valores before y after-image sean capturados para las operaciones update.

Figura 39. Definiciones de columnas de los conjunto de datos updates

La Figura 40 muestra las definiciones de columna para Deletes_DataSet1. Tenga en cuenta que estos son valores before-image en la tabla Product.

Figura 40. Definiciones de columna del conjunto de datos deletes
  1. Siga los mismos pasos para completar los conjunto de datos insert, update, y delete para la tabla Inventory.

Prueba de la configuración de datos del escenario

Complete los siguientes pasos para probar la configuración de datos del escenario.

  1. Replicación de Start SQL, como se mostró en la Figura 41.
Figura 41. Inicie la ventana de comandos DB2 de SQL Capture

Tenga en cuenta lo siguiente sobre la replicación starting SQL:

  • La consola start capture muestra que dos registraciones están en un estado inactivo.
  • Las registraciones se tornan activas solo cuando el servidor de solicitudes de SQL se inicia y hay un hand-shake entre la captura y la solicitud SQL.
  1. Inicie DataStage Designer, como se observa en la Figura 42.
Figura 42. Inicie la consola de la captura
  1. Importe la tarea DataStage StagedDataInt.dsx navegando al directorio StagedDataInt desde la descarga y haciendo clic en OK en la ventana DataStage Import como se muestra en la Figura 43.
Figura 43. Tarea Import Staged Integration DataStage

Después de importar el archivo dsx, usted verá tres tareas en el directorio StagedInt.

  1. Abra la tarea paralela extractFromProduct_CCD .
  2. Asegúrese de que el nombre de la base de datos (si es diferente a STAGEDB), nombre de usuario, y contraseña en el escenario del conector de la DB2 sean los correctos.
  3. Asegúrese de que los tres conjunto de datos indiquen los archivos actuales con la ruta establecida correctamente.
  4. Guarde y compile la tarea haciendo clic en el ícono verde en el designer.
  5. Abra la tarea paralela extractFromInventory_CCD , y repita el mismo proceso.
  6. Abra la tarea de secuendia StagedDataIntSQLRep.
  7. Asegúrese de que todas las actividades de las tareas y los escenarios de comando exec indiquen las tareas y scripts correctos, respectivamente, como se observa en la Figura 44.
  8. Guarde y compile la tarea.
Figura 44. Compilación de tarea de integración en el escenario
  1. Abra la ventana de comando de la DB2, cambie el directorio a StageDataInt\setupSQLRep y ejecute el script updateSourceTables.sql. Este script realiza un insert, update, y delete en las tablas Product e Inventory.
  2. Abra la ventana de comando de DB2, conéctese a la base de datos destino STAGEDB, e ingrese las siguientes sentencias SQL:
     Db2 select count(*) from ADMIN.PRODUCT_CCD Db2
                                select count(*) from ADMIN.INVENTORY_CCD

    Estas dos sentencias deberían devolver un recuento de tres registros, porque usted introdujo tres modificaciones a los datos de origen insert, update, y delete en ambas tablas de origen.

  3. Ejecute la tarea DataStage haciendo clic en el ícono Run en el menú DataStage Director, como se observa en la Figura 45. Usted puede iniciar el DataStage Director desde el acceso directo All Programs > IBM Information Server > IBM WebSphere DataStage and QualityStage Director .
Figura 45. Ejecute la tarea de integración del escenario
  1. Verifique el estado de la tarea. La Figura 46 muestra que las tareas finalizaron con éxito.
Figura 46. Verificación del estado de la tarea
  1. Visualice los registros de la tarea, como se observa en la Figura 47.
Figura 47. Visualización del registro de la tarea
  1. Visualización de los datos en los conjunto de datos para confirmar que se completaron, como se observa en la Figura 48.
Figura 48. Visualización del conjunto de datos
  1. Visualice los datos en el Updates_DataSet de las actualizaciones en la tabla PRODUCT_CCD (tabla destino CCD de la tabla de origen Product), como se observa en la Figura 49.
Figura 49. Visualización de actualizaciones en conjunto de datos
  1. Verificación de que la tabla END_OF_PERIOD in IBMSNAP_SUBS_EVENT esté actualizada con la marca de tiempo actual, como se observa en la Figura 50.
Figura 50. Verificación de que el evento de solicitud SQL continuo sea actualizado en IBMSNAP_SUBS_EVENT
  1. El archivo de registro del escenario de datos en la Figura 51 muestra que la tarea Execute Command Activity ContinueSQLApply se ejecutó exitósamente.
Figura 51. Registro de tareas

Conclusión

La Part 1 se refiere a las tecnologías de los productos InfoSphere Replication Server y DataStage y las diferentes formas de integrar ambos para ingresar datos al depósito. Esta Parte 2 detalló dos opciones de integración específicas: el uso de mensajes MQ y el uso de tablas de representación. El artículo también analizó las instrucciones para la configuración con capturas de pantalla e instrucciones de las dos opciones de integración. Con la información de esta serie, su empresa puede integrar fácilmente InfoSphere Replication Server e InfoSphere Information Server's DataStage para proporcionar una solución de alta performance para el ingreso de datos al depósito.


Descargar

DescripciónNombretamañoMetodo de descarga
Scripts for sample configurationsscripts-paper-mastercopy.zip486KBHTTP

Información sobre métodos de descarga

Recursos

Aprender

Obtener los productos y tecnologías

  • Cree su próximo proyecto de desarrollo con el IBM trial software, el cual puede descargar directamente desde developerWorks.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt, WebSphere
ArticleID=619266
ArticleTitle=Solución de alta performance para el ingreso de datos en un depósito en tiempo real, Parte 2: Explore las opciones de integración con las tablas de representación y mensajes de WebSphere MQ
publish-date=03312014