TRANSFORMACIONES DE FORMATOS CON 'MFL' EN OSB

Usualmente en BPEL se acostumbra utilizar el 'File Adapter' para leer archivos NO XML y transformarlos a formato XML, pero en OSB junto con el adaptador de archivos también existe otra forma NO muy conocida de realizar dicha tarea. Esta se conoce como MFL y la podemos utilizar para transformar datos NO XML a datos XML y viceversa.

En este post se procederá a mostrar cómo transformar los datos NO XML a datos XML utilizando MFL. Para mostrar este funcionamiento, se ha preparado un dummy de un Servicio Virtual que consistirá en lo siguiente:

"Se ingresará una trama (Formato: NO XML) en una ubicación específica, que será procesada por el OSB. Esta trama procederá a ser transformada en formato XML para ser enviada de Request contra el WS. El Response del WS será transformado a formato NO XML (Trama), para ser finalmente depositado en una ubicación de salida como archivo generado".

DUMMY:

1. Considerando que la Trama INPUT tendrá este formato y será ubicado en una ruta local (especificada en el Proxy Service más adelante):

2. Definir y crear una RUTA BASE, que contendrá 4 directorios:

- TEMP: Directorio encargado de procesar los archivos de manera temporal.

- ERROR: Directorio encargado de almacenar los archivos con error en el proceso.

- INPUT: Directorio donde se ubicarán las tramas a procesar.

- OUTPUT: Directorio donde se generarán las tramas de respuesta del proceso.

3. Definir la estructura de directorios de muestro proyecto OSB:

4. Creamos un BusinessService que referencie y controle por medio del WSDL incrustado en el proyecto al WebService: 'http://localhost:8090/mockDatosClienteService?wsdl',(Un MockServices que he iniciado por medio de SOAPUI):

5.  Crear los archivos MFL (sobre el proyecto: new/MFL), tal como se explicó por medio de estos archivos se configurarán las transformaciones NO XML a XML y XML a NO XML. Con esta lógica ya podremos definir el MFL INPUT: encargado de transformar TRAMA a REQUEST y el MFL OUTPUT: encargado de transformar RESPONSE a TRAMA:

Para esto se debe de conocer antes de definir las tramas, los datos REQUEST/RESPONSE del WS a consumir:

5.1. Crear el archivo: DatosCliente_IN.mfl, para la transformacion INICIAL,considerando la configuración mostrada considerando los valores de los DELIMITADORES, sobre todo el del salto de linea del campo final (\n):

5.2. Crear el archivo: DatosCliente_OUT.mfl, para la transformacion FINAL, considerando la configuración mostrada considerando los valores de los DELIMITADORES, sobre todo el del salto de linea del campo final (\n):

6. Crear los XQuery consideranto las transformaciones que se manejaran:

6.1.  DatosCliente_IN.xq: Encargado de transformar la Trama (NO XML) hacia el REQUEST del WS: 

6.2.  DatosCliente_OUT.xq: Encargado de transformar la el RESPONSE del WS hacia la Trama (NO XQML) a generar:  

7. Crear un BusinessService de tipo Messaging Service que referencie y controle un MFL (Trama):

Definir el directorio donde se generarán las tramas de respuesta (OUTPUT) al finalizar procesamiento:

 

Definir parte del nombre de los archivos que se generarán para cada procesamiento, así mismo la extensión de los archivos de salida propiamente:

8.  Crear un ProxyService que controle los mensaje INPUT (Trama), que se dejarán en la ruta configurada:

Definir la ruta INPUT donde se depositará la trama:

Configurar tiempo, intervalo, formato y directorios (rutas) de control con relación a las tramas INPUT:

Creamos desde Message Flow los nodos que soportarán el funcionamiento del Servicio Virtual:

Con esto tenemos el Servicio Virtual completado, para las pruebas simplemente bastaría con depositar la trama INPUT en el directorio definir y automáticamente el flujo del Servicio Virtual se activará y a nivel de consola se visualizará el resultado:

PRUEBA:

1. Ubicar la trama en la ruta INPUT definida (C:\Ficheros\MFL\INPUT):  

2. El Servicio Virtual en un tiempo determinado procesará el mensaje (Trama):

3. Finalmente, por cada registro en la trama se generarpa y consumirá un REQUEST del WS y así mismo generará un archivo OUTPUT por cada RESPONSE:

Para los interesados se pueden descargar las fuentes del Dummy (OSB 11g - '11.1.1.7') desde aquí:  http://www.mediafire.com/download/fdz82c149nt8yfq/DummyNoXml_To_Xml.jar

'TEMPLATEs' & 'REUSE PROJECT' IN OSB 12c

Una característica muy resaltante e importante que brinda ‘Oracle Service Bus 12c’ (OSB), es la capacidad de definir y manejar Templates para diferentes tipos de proyectos OSB, en los cuales uno puede estandarizar dichos Templates en un SVN por ejemplo y compartirlos con el equipo de desarrollo para que realicen las implementaciones de los ‘Servicios Virtuales’ requeridas. Esto es importante ya que todo lo definido en los Templates se ajustan a reglas y directrices (estándares) del proyecto, esto significa eliminar la costumbre común de copiar y pegar de ciertas nodos del OSB (versión anterior 11g), y favorece la reutilización al 100%. OSB 12c cumple con tener un entorno de desarrollo mucho más integrado (vía Enterprise Manager) y con un más fácil modo de instalación como parte de todo la SOA Suite 12c.

En este artículo trataré de mostrar cómo utilizar esta nueva funcionalidad a base de Templates en OSB 12c, que tal como se comentó facilitará la construcción y reutilización de una gran cantidad de servicios a través de diferentes proyectos. Así mismo, comentaré son la reutilización de proyectos por referencia para manejar todo lo relacionado a recursos utilitarios de diferentes tipos a nivel general.

I. TEMPLATE:

El manejo de Templates se puede manejar de diferentes formas que son las siguientes:

A. En base a un proyecto existente:
En base a un proyecto existente, se puede generar un Template de la manera mostrada en la imagen, pero esto puede problemas y errores debido a las dependencias con Xquerys y archivos los cuales se tenga dependencia a nivel de rutas.

B. Definiendo Template desde cero:
El Template es creado desde cero desde la barra de menú:

Se define la ruta donde se almacenará el Template:

Dependiendo como se desee manejar el .WSDL a futuro, se define este punto. En mi caso recomiento manejarlo como WSDL SOAP (independiente de la versión), para que cuando se autogenere se exija el manejo del TopDown.

RECOMENDACIÓN:

Una recomendación que daría para el manejo de Templates, es de la siguiente manera:

Definir formalmente (estandarizar) Templates específicando, como se requieren manejar con relación a su implementación de los 'Servicios Virtuales' en sus organizaciones:

En mi caso he definido 3 posibles Templates:

- VirtualServiceAgnosticSOAP_Template.ptx:
Plantilla para AUTOGENERAR la estructura de un 'Servicio Virtual' con comunicacion AGNÓSTICA (Sin Transformación), el .WSDL debe ser reutilizado para la creación del 'Business Service' como para el 'Proxy Service'.

- VirtualServiceTransformSOAP_Template.ptx:
Plantilla para AUTOGENERAR la estructura de un 'Servicio Virtual' SIN comunicacion AGNÓSTICA (Con Transformación), el .WSDL requiere de modificaciones (campos extras) y/o modificación a nivel de Namespace. Debido a ellos los .WSDL's del 'Business Service' como para el 'Proxy Service', deben ser diferentes y america una transformación intermedia.

- VirtualServiceTransformGeneric_Template.ptx:
Plantilla para AUTOGENERAR la estructura de un 'Servicio Virtual' genérico, con espacio para para una implementación de tipo Secuencial.

- IMPORTANTE:
Los servicios en paralelos basados en 'Split-Join', NO pueden ser trabajados con Plantillas. En este caso deberán ser desarrollados como 'Servicios Virtuales' a medida.

El manejo recomendada a base de Templates, puede implementarse fácilmente tal como se muestra en la imágen, todos en un mismo proyecto y manejada la estructura, tal como se recomendó en un post anterior. Esto asegurará un correcto, rápido y estandarizado manejo con la organización.

II. REUSE PROJECT:

El manejo de reutilización de proyectos OSB, por referencia se maneja para casos como el que procederé a explicar.

Imaginemos que tal como se recomendó seguimos un estándar a nivel de estructura de directorios, y tenemos gran cantidad de 'Servicios Virtuales' que manejan de similar y repetida manera: (Xquery. Jar, Xsd, etc). Debido a este motivo es necesario definir y estandarizar también un mecanismo que permita reutilizar entre todos los proyectos lo mencionado.

Para ello es importante crear un estándar de proyecto OSB a modo utilitario donde se maneje todo lo explicado anteriormente. La propuesta de manejo sería la siguiente: 

Un directorio OSB en mi caso: UTILITY_OSB, que contenga en su interior los recursos:

• ALERT: Alertas por nivel para ser referenciadas desde el interior de todos los proyectos. 
• JAR: Librerías Java para ser referenciadas estáticamente para lo que son Log y Properties externos.
• TEMPLATE: Plantillas base estándar para la generación de proyectos OSB por tipo.
• XQUERY: Archivos de tipo XQuery para ser referenciadas desde el interior de todos los proyectos.
• XSD: Archivos de tipo Xsd para el manejo de Auditoría, para ser incrustado a modo import/include en los .wsdl creados de todos los proyectos.

Este tipo de proyecto utilitario debe ser desplegado en el servidor (Cluster y Nodos), ya que la referencia será manejada a modo local, desarrollo como en los demás ambientes existentes en el servidor Weblogic.

No olvidar que las referencias todos los Templates estandarizados, deben estar totalmente documentados, para poder uno como desarrollador saber y tener conocimiento lo que ya está definido y falta agregar para implementar. Así mismo, todas las Templates están directamente relacionados con el tema de: Reuse Project, ya que sus recursos reutilizables referencian a lo existente en dicho proyecto utilitario OSB.  

 

Finalmente, se debe recordar tanto el manejo de: Templates, como el manejo de Reuse Project y el de Estructura de Directorios en OSB, es un tema también considerado como buenas prácticas en lo relacionado a estandarizar todo el proyecto, esto para llevar un mejor control de tal así como favorecer el desarrollo y mantenimiento respectivamente.

Para los interesados en los Templates propuestos, estos se pueden descargar desde aquí:

https://www.mediafire.com/folder/dyz2j9044r0qd/OSB

DEFINICIÓN DE ESTRUCTURA DE DIRECTORIOS EN OSB 12c

El manejo de los estándares en todo tipo de proyectos es importante, ya que permite definir un mismo modo de trabajo (un estándar), con relación a todo el equipo de desarrollo. Estos estándares pueden ser aplicados a prácticamente todo, desde fuentes, documentación etc.

A nivel de Oracle Service Bus (OSB), esto también es recomendable que se aplique, para la creación de los proyecto OSB relacionados los Servicios Virtuales: (Exposiciones, Virtualizaciones, etc). En esta oportunidad mostraré una forma de cómo estandarizar la Estructura de Directorios del proyecto OSB propiamente, con relación al manejo de un proyecto mediano/grande a nivel departamental. Dicha estructura de directorios debe ser capaz de soportar ser lo más ordenado y reutilizable posible, pensando en la gran cantidad de Servicios Virtuales que manejará internamente, así mismo como facilitar la segmentación y mantenimiento de estos.

La Estructura de Directorios propuesta, para este tipo de proyectos OSB de mediano/grande envergadura, así como la extensión de los archivos manejados por directorios, son las que se muestran en imagen:

Cada Estructura de Directorios tiene una finalidad con relación a lo que manejará en su interior. Esta estructura está bien detallada:

El contenido de los archivos deberán tener así como una ubicación fija (directorio), una nomenclatura estándar con relación al nombre del proyecto/servicio/operación manejado. La propuesta es la siguiente:

Finalmente, como se visualizaría dicha Estructura de Directorios estándar propuesta, a nivel de la herramienta sería de la siguiente forma: (Los nombres de empresa, servicios, etc, son subjetivos)

Así mismo, desde la consola OSB el agrupamiento departamental de los proyectos/servicios de tipo OSB, deberían visualizarse de la siguiente manera:

Espero que este post haya sido de gran importancia para eliminar duda alguna existente anteriormente, sobre la definición para el manejo de una correcta Estructura de Directorios en OSB.

CATCHING & LOAD BALANCING EN OSB

En post anteriores he explicado sobre la importancia del manejo del Cache en las aplicaciones y servicios por medio del framework Ehcache. En esta oportunidad daré detalles de cómo manejar dos temas muy importantes que son el Catching, así mismo como el Balanceo de Carga a nivel de Oracle Service Bus 12c.

Este artículo se ha creado para ayudar a aquellos que quieren poner en marcha el almacenamiento en caché por medio de OSB, ya que en él se describe cómo utilizar esta funcionalidad por medio de un ejemplo de cómo el cache maneja dicho almacenamiento y como distribuir la carga existente por medio del balanceo de carga, para mejorar el rendimiento por medio del caché y la configuración de equilibrio de carga en OSB. Así mismo,  OSB proporciona una funcionalidad que viene ya integrada, que es el soporte de caché por medio de Oracle Coherence, que brinda muchas estrategias de almacenamiento en caché, a continuación se procederá con la explicación.

Antes que nada, es necesario para el dummy preparado crear un Web Service con JaxWS, para ejecutarlo a modo local sin necesidad de desplegarlo en un servidor. Este Web Service expondrá dos servicios con diferente puerto simulando dos server distintos:

• http://localhost:8098/ServidorWS_JAXWS_Generado/UsuarioDAOImpl?wsdl
• http://localhost:8099/ServidorWS_JAXWS_Generado/UsuarioDAOImpl?wsdl

Luego, en la operación: sumar, hemos ingresado una línea para aplicar un delay de 10 segundos en la respuesta de dicho servicio, esto para probar posteriormente la eficacia del cache configurado.

Finalmente, crearemos en el OSB un Servicio Virtual de dicho servicio, en base al .wsdl (TopDown) ya expuesto. La URL de este servicio virtual será: 

• http://localhost:7101/Operaciones_SB/Pipeline/OperacionesWS?wsdl

I. CATCHING:

Para el manejo del Caching en OSB, realizaremos la configuración en el: BusinessService (Operaciones_BS) previamenete ya creado. Luego, vamos a la opción: Performance y habilitamos el check: Enable Result Caching. Después, configuramos en: Expiration Time, a nivel de: Días, Hora, Minutos y Segundos, que se requiere que el Cache almacene la información para posteriormente refrescar con la nueva info. Esto se debe configurar en base a la información que proporcione el negocio en escenarios donde la información NO variará, esto para agilizar la respuesta y evitar consultas a BD y/o servicios por gusto.

Para este escenario del dummy, configuraremos solo la parte de los segundos (20 segundos), para que se refresque dicho cache en ese tiempo.

Desplegamos el Servicio Virtual dummy e iniciamos la consola de pruebas, tal como se muestra en imagen.

Verificamos que al ser ejecutado el Servicio Virtual, demora exactamente 10 segundos en mostrar la respuesta (ANTES de aplicar la configuración del cache).

Posteriormente, a la configuración del Cache, el tiempo de 10 segundos para la respuesta del Servicio Virtual, será aplicado solo la primera vez que se ejecute. Ya que a la siguiente vez automáticamente se activará el Cache configurado e iniciará el conteo de tiempo de 20 segundos configurado. Esto efecto se puede apreciar desde la consola misma de pruebas, ya que la primera vez demorará y luego de ello, uno puede ejecutar varias veces y la respuesta demorará menos de un segundo en responder, ya que se obtendrá del Cache respectivamente, durante el delay configurado.

II. LOAD BALANCING:

Para el manejo del Load Balancing en OSB, realizaremos la configuración en el: BusinessService (Operaciones_BS) previamente ya creado. Luego, vamos a la opción: Transport y seleccionamos el Algoritmo que más nos acomode (en este caso: round-robin). Luego, agregamos la segunda URL que al inicio del post definimos (con diferente puerto) a la lista y finalmente, el máximo número de reintentos posibles y el intervalo entre cada uno de estos.

Finalmente, volvemos a desplegar el Servicio Virtual en la consola OSB y validamos el efecto ya con todo el Balanceo de Carga configurado.

Esperemos que el post haya sido de su agrada y lo puedan aplicar de la mejor manera en sus proyectos OSB. Para los interesados en descargar las fuentes (Eclipse & OSB) lo pueden hacer aquí:

http://www.mediafire.com/download/76562h6mo37731o/Dummy_Caching_%26_LoadBalancing.zip