Oracle BPEL PM + Oracle Data Integrator
3
En muchos escenarios de integración se requiere pasar altos volúmenes de información de uno o varios repositorios hacia un destino que también puede ser múltiple.
Con herramientas de orquestación de procesos, y con los mismos ESBs puede llegar a ser ésto complicado, sobretodo cuando se tratan de volumenes que se van por arriba de los 10MB de información, y además cuando las transacciones son muy constantes.
Para dicho propósito podemos pensar que una buena opción es utilizar una herramienta de ETL tradicional, el único inconveniente es la dependencia alta sobre el uso de Bases de datos y el uso de servidores intermedios que hagan dicho trabajo.
Oracle ofrece una herramienta de nombre Oracle Data Integrator, que hace una modificación al esquema tradicional de ETL, pues en realidad realiza un ELT (Extract->Load and Transform). La gran diferencia es que la transformación de los datos se puede dar en el mismo destino, lo cual aumenta el peformance y más si pensamos que lo va a hacer de manera nativa con el propio lenguaje que tenga el repositorio destino.
En un ambiente Orientado a Servicios, es altamente probable que la extracción y carga de datos no sea únicamente en Bases de Datos, sino también en Aplicaciones. Esto nos lleva a la necesida de tener un producto que resuelva muy bien la conectivdad a repositorios Relacionales y Multidimensionales tradicionales, pero que también pueda interactuar con Servicios Web y Aplicaciones Empresariales.
Ahora, qué sucede si combinamos la tecnología, pensando en que un Arquitectura Orientada a Servicios tiene un sustento muy importante en el uso de un motor de orquestación de procesos. Si un proceso (pensemos en Oracle BPEL PM) que orquesta esta carga de datos, pero en realidad él no lo hace, él simplemente manda un mensaje al ETL para que se inicie; pero nos interesa saber en todo momento en qué paso se encuentra, pues si no podemos llegar a perder visibilidad de la transacción y gobernabilidad.
Bien, pues Oracle Data Integrator permite publicar Servicios Web y consumirlos. Así Oracle BPEL PM es el orquestador de servicios de integración de datos que publique Oracle Data Integrator (ODI).
De esta manera sabremos exactamente lo que sucede en la extracción de datos, su transformación y carga. Podemos monitorear los tiempos de ejecución, podemos así monitorear SLAs y publicar Tableros de Control en donde se de visiblidad sobre toda esta información. Y estando ésto siendo orquestado se puede correlacionar la información con cualquier otro paso de un proceso de Negocio.
Oracle Data Integrator puede ser descargado del sitio de Tecnología de Oracle (http://www.oracle.com/technology/products/oracle-data-integrator/index.html).
Es una herramienta basada en java que requiere únicamente de tener previamente instalada una BD (que bien pudiera ser Oracle XE si están en modo de pruebas).
Una vez instado el producto, recomendamos que le den una mirada al tutorial (http://www.oracle.com/technology/products/oracle-data-integrator/index.html) de inicalización. Esto les dará una buena idea de qué hace el producto.
La publicación de WS en Oracle Data Integrator es bastante simple, se requiere:
* OC4J - aquí se publicarán dichos servicios. Puedes utilizar el OC4J donde estés ejecutando Oracle BPEL PM
* AXIS 2.0 - tecnología de Apache que permite la publicación de Web Services (http://ws.apache.org/axis2/). Básicamente es publicar un WAR.
* Publicar el paqute de Oracle Data Integrator a través de la consola de Axis (éste lo encuentras en $OH\oracledi\tools\web_services\odi-public-ws.aar)
Para tener las instrucciones detalladas de dicha configuración, pueden consultar la guía de instalación que viene como parte de la instalación del producto.
Una vez instalado Axis2, y haciendo el deployment del paquete (odi-public-ws.aar) de ODI (Oracle Data Integrator), se tiene la posibilidad de revisar el WSDL en la siguiente ubicación:
http://rcarrasc-mx:8888/axis2/services/OdiInvoke?wsdl.
Supongamos que tenemos un proceso en Oracle BPEL PM, que en determinado momento requiere mover grandes volumenes de información entre 3 bases de datos. Oracle Data Integrator hará éste trabajo de mover la información entre éstos
repositorios. Lo primero que hará será consultar la información del repositorio A (Base de datos) y lo pasará al repositorio B (otra Base de datos), y por último pasará lo que tiene en B a un tercero llamado C.
Dado que son millones de registros, hacer uso de los adaptadores de BPEL PM tal vez no sea tan eficiente, pues al transformalo a un formato XML, provocará una gran volumen de datos manejados en memoria, y no será tan peformante.
En ODI, se conocen como escenarios, adentro de los cuales existen interfaces, las cuales son las que en realidad hacen el trabajo de mover los datos y transformarlos.
Supongamos el siguiente escenario de ODI y el flujo BPEL de las imágenes de abajo (haz click en cualquier imagen para que puedas verla en un tamaño más grande):
El flujo BPEL realiza primero una serie de asignaciones de valores que son los necesarios para iniciar el escenario en ODI, se debe crear un mensaje similar al siguiente:
Con estos valores se hace la invocación al Partnerlink (ODIScenario), que inicia la ejecución de ODI.
ODI lo primero que hace es recibir un valor (ID - en el mensaje XML tiene el valor 769) que es el que servirá para correlacionar la instancia con el flujo en BPEL PM. Después se ejecuta una interface que mueve y transforma datos de una BD A a una B, posteriormente envía un mensaje de vuelta al proceso de BPEL que lo inició para informarle que ya terminó la primera interface. BPEL lo recibe en la actividad que en la imagen aparece como receiveIntermediate.
ODI continua su ejecución ejecutando ahora la interface "InterfaceRolando3", y finalmente envia un mensaje al mismo proceso BPEL, el cual lo recibe en la actividad "receiveFinal".
La correlación, como se había comentado, se lleva acabo a través del valor del ID, así el escenario de ODI se puede comunicar con BPEL. En realidad hay un flujo BPEL intermedio que es el que recibe la invocación de ODI, y es el que comunica al proceso BPEL que inicia todo. ¿Esto por qué? Porque ODI en su versión actual no puede consumir procesos asíncronos.
De esta forma mostramos la integración entre ambos productos, y la gran capacidad que se logra al unir ambas tecnologías.