Automatización de Deployment de Oracle API Platform Cloud Service

Desde hace algunas semanas he participado en un proyecto de migración hacia Oracle Cloud. El proyecto tiene como objetivo migrar una buena cantidad de servicios a la nube de Oracle. Estos servicios se encuentran actualmente desplegados en Oracle SOA Suite.

Uno de los objetivos de la organización es darle a los servicios el enfoque de APIs, de tal manera que puedan ser usados por varios canales dentro y fuera de la organización. También que la misma organización pueda ejecutar acciones de monitoreo de uso y rendimiento, monetización, seguridad, y algunas otras relacionadas con el proceso de API Management.

La arquitectura utilizada para la implementación es una mezcla de varias nubes de Oracle:

• Oracle API Platform Cloud Service
• Oracle Integration Cloud Service
• Oracle Infrastructure Cloud
• Oracle Developer Cloud Service

Voy a enfocar esta entrada del blog a la automatización de los artefactos creados en Oracle API Platform Cloud Service debido a que la arquitectura contempla un plan de recuperación ante desastres, comúnmente llamado DRP.

Oracle API Platform Cloud Service

Esta es la plataforma de API Management que ofrece Oracle. Proporciona funcionalidades típicas de una plataforma de este estilo. A continuación, se listan algunas de sus capacidades:

• Configuración de proveedores de OAuth 2.0
• Administración de usuarios y grupos
• Administración de roles
• Gateways lógicos y físicos
• Gestión de APIs
• Gestión de planes
• Gestión de cuentas de servicio
• Analíticos
• Portales de desarrolladores
• Administración de aplicaciones

Una de las desventajas de este servicio de Oracle es que no cuenta con opciones para realizar la migración de las APIs y Gateways desplegados, hacia una instancia nueva o distinta. Por ejemplo, en el caso de un desastre, tendríamos que encender la instancia contemplada en el DRP. Sin embargo, no existen capacidades para migrar los artefactos de una instancia a otra de manera natural.

Para mayor detalle del servicio de API Management de Oracle, pueden consultar la documentación en la siguiente liga:

https://docs.oracle.com/en/cloud/paas/api-platform-cloud/index.html

REST API

Afortunadamente, el servicio (como casi todos los servicios de nube) cuenta con APIs de tipo REST que nos ayudarán a automatizar el proceso. Esto evitará la necesidad de construir y sincronizar todo de nuevo en la instancia del DRP.

El alcance de las APIs provistas por Oracle incluyen la interacción con distintos elementos de la plataforma. Algunos de ellos son los siguientes:

• APIs
• Aplicaciones
• Deployments
• Gateways
• Planes
• Políticas
• Cuentas de servicio
• Suscripciones

La seguridad implementada para el uso de las APIs es OAuth 2.0. Esto quiere decir que previo al uso de las APIs, es necesario obtener un token de acceso a través de Oracle Identity Cloud Service. Una vez que el usuario es autenticado y autorizado, se utiliza el token para invocar cualquiera de las APIs.

La documentación completa de la funcionalidad de las APIs, su alcance y ejemplos de uso se encuentra en la siguiente liga:

https://docs.oracle.com/en/cloud/paas/api-platform-cloud/apfrm/index.html

Developer Cloud Service

Para este proyecto inclumos el uso de Developer Cloud Service como un entorno en el que vamos a ejecutar la automatización del despliegue de las APIs generadas. Developer Cloud Service es la plataforma de desarrollo de Oracle en la nube (PaaS). Cuenta con capacidades para desarrollo, colaboración, construcción y despliegue de aplicaciones en Oracle Cloud.

La documentación completa de Oracle Developer Cloud Service la pueden encontrar aquí:

https://docs.oracle.com/en/cloud/paas/developer-cloud/index.html

Proceso de Automatización

Los pasos que seguimos para la automatización del despliegue en Oracle Developer Cloud Service fueron los que se detallan a continuación.

Descriptor

Lo primero que utilizamos es un descriptor de las APIs. Este básicamente es un archivo de tipo JSON que nos indica información importante de las APIs que queremos promover de una instancia a otra.

Básicamente, la información que debe incluir el descriptor es la siguiente:

• Nombre de la API
• Endpoint del servicio del backend

A continuación, se muestra un ejemplo simple del descriptor:

{

    "apis": [

        {

            "name": "Orders API",

            "targetURL": "https://oracleintegrationcloudinstance/ic/ws/integration/v1/flows/soap/"

        },

        {

            "name": "Customers API",

            "targetURL": "https://oracleintegrationcloudinstance/ic/ws/integration/v1/flows/soap/"

        }

    ]

}

Dentro del arreglo de APIs, vamos a colocar todas las APIs que necesitamos mover de una instancia (fuente) a otra (destino).

Una vez creado el descriptor, se debe subir al repositorio de Git para conectar el job que realizará el despliegue automático. Así, cada vez que se decida mover APIs de una instancia a otra, se deberá modificar el descriptor y hacer commit de los cambios al repositorio.

Es hora de crear el job.

Parámetrización del job

Para hacer dinámico el job que automatiza el despliegue, es necesario colocar algunos parámetros que podamos cambiar a la hora de ejecutarlo. De esta forma, si las instancias cambian, la ejecución del job será dinámica y se adaptará a nuestras necesidades. Los parámetros que colocamos son los siguientes:

• Descriptor: nombre del archivo descriptor que se subirá al repositorio. El contenido deberá tener la información de las APIs que se necesitan mover de un ambiente a otro.
• GetTokenURL. URL de la API que utilizaremos para obtener el token de acceso. Normalmente esta es la URL de Oracle Identity Cloud Service.
• ClientCredsSource. Client ID y client secret de la aplicación origen que utilizaremos para consumir las APIs.
• ClientCredsTarget. Client ID y client secret de la aplicación destino que utilizaremos para consumir las APIs.
• UsernameSource. Usuario para obtener el token de acceso en la instancia origen.
• PasswordSource. Password para obtener el token de acceso en la instancia origen.
• ScopeSource. Scope para obtener el token de acceso en la instancia origen.
• URLEnvSource. URL de la API de la instancia origen de Oracle API Platform.
• UsernameTarget. Usuario para obtener el token de acceso en la instancia destino.
• PasswordTarget. Password para obtener el token de acceso en la instancia destino.
• ScopeTarget. Scope para obtener el token de acceso en la instancia destino.
• URLEnvTarget. URL de la API de la instancia destinode Oracle API Platform.
• GatewayID. Identificador del Gateway donde vamos a desplegar las APIs.

Los parámetros anteriores nos ayudan a ejecutar el job con valores dinámicos. Así, si la instancia fuente o destino cambia, lo único que es necesario es cambiar los valores de esos parámetros.

Scripting

La estrategia para realizar la automatización fue ejecutar un bash script. La mayoría de las APIs de Oracle están ejemplificadas con el uso de cURL. Por esta razón decidimos escribir un bash script y ahí encapsular las llamadas a las APIs con el uso de cURL.

Sin embargo, es posible codificar la automatización en cualquier otro lenguaje. Aquí lo importante es que sepamos cómo consumir REST APIs con ese lenguaje. Incluso es posible crear un plugin de Maven o Gradle para este propósito.

Validaciones

Antes de ejecutar la automatización, debemos hacer algunas validaciones. En mi caso las validaciones que hice al contenido del descriptor fueron las siguientes:

• El archivo JSON tiene una estructura válida y cumple con la definición de la estructura del descriptor.
• El archivo incluye la información de al menos una API a desplegar.

Procedimiento de despliegue

Los pasos para realizar el despliegue, después de librar todas las validaciones del archivo, son los siguientes:

• Obtener un token de acceso del ambiente origen: POST /oauth2/v1/token
• Obtener las APIs del ambiente origen: GET /apiplatform/management/v1/apis
• Validar que todas las APIs del descriptor, se encuentran desplegadas y activas en el ambiente origen. Esto es necesario, pues del ambiente origen se va a tomar toda la definición de cada API. Si no están desplegadas o activas, no podemos tomar la definición de ese ambiente: GET /apiplatform/management/v1/apis/{id}/deployments
• Obtener un token de acceso del ambiente destino: POST /oauth2/v1/token
• Obtener las APIs del ambiente destino: GET /apiplatform/management/v1/apis
• Si la API origen existe en el destino: actualizar la definición con el detalle del origen y con el endpoint del descriptor (targetURL): PUT /apiplatform/management/v1/apis/{id}
• Si la API origen no existe en el destino: crear la API en el ambiente destino con el detalle del origen y con el endpoint del descriptor (targetURL): POST /apiplatform/management/v1/apis
• Desplegar la API en el ambiente destino: POST /apiplatform/management/v1/apis/{id}/deployments

Posibles errores

En caso de que exista un error en alguno de los pasos anteriores, el proceso se detiene y se reporta la causa del error. Algunas causas de error pueden ser las siguientes:

• Información de credenciales incorrecta: usuarios, passwords, client credentials
• Las APIs listadas en el descriptor no se encuentran desplegadas y/o activas en el entorno origen
• Hay alguna dependencia en el entorno origen que no está configurada en el entorno destino. Por ejemplo los service account.

Conclusiones

Crear un mecanismo de automatización de despliegue de las APIs desplegadas en Oracle API Platform Cloud Service es una buena idea, pues a menudo se pueden presentar escenarios donde es necesario mover los artefactos de una instancia a otra. Esto puede suceder por distintas razones: se actualizan los servicios de nube, en un escenario de DRP, en caso de tener distintas instancias para distintos ambientes (Dev, Staging, Prod).

La reacción oportuna a alguno de estos escenarios, se verá beneficiada por la automatizacion y evitará el esfuerzo de crear nuevamente cada uno de los artefactos (APIs, Gateways, Planes, entre otros).

El uso de Developer Cloud Service es una buena alternativa para concentrar estas estrategias, pues es una plataforma que podemos utilizar de manera transparente para integrar con distintas nubes de Oracle, ya sea a través del uso de las APIs o a través de la propia CLI de Oracle. Aquí mismo podemos documentar y dar seguimiento al proceso y tareas de automatización. Personalmente he utilizado esta nube para automatización de despliegues de:

• Microservicios (Helidon, Quarkus) hacia Oracle Kubernetes Cluster.
• Oracle SOA Suite (Service Bus y SOA Composites) hacia entornos OnPremise y Cloud.
• APIs en Oracle API Platform Cloud Service
• Integraciones en Oracle Integration Cloud Service
• Funciones en Oracle Functions (FaaS)

Válvulas - File Adapter

Uso de válvulas en el File Adapter

Existe una funcionalidad de pre-procesamiento de archivos que podemos añadir al File Adapter de la Oracle SOA Suite. Personalmente no la conocía, pero me parece muy práctica y es por eso que decidí compartir esta entrada del blog.

El requerimiento es simple. Tal vez sea común trabajar con archivos de tipo CSV, posicionales, de texto plano, etc. En lo primero que pensamos para resolver una situación donde se involucren archivos es en el File Adapter.

Entre sus características están leer el archivo haciendo uso de streaming, utilizar un NXSD para transformar el contenido de manera nativa a XML, o simplemente no leer el contenido y transportar el archivo hacia algún sitio (file system, FTP).

En esta ocasión, la necesidad es un tanto "fuera de lo común": procesar un archivo de Excel.

Si bien el File Adapter no tiene entre sus capacidades nativas procesar un archivo de este tipo (me refiero a leer el contenido), tampoco es ciencia saber cómo resolver el problema. No existe una forma de transformar un archivo Excel mediante un NXSD.

Una de las opciones que puede pasar por nuestra cabeza es leer el archivo con el File Adapter (sin procesar el contenido) y posteriormente con una actividad Java Embedding procesar el contenido. Sin duda esta es una forma de abordar la solución.

Sin embargo, existe una manera más elegante de resolverlo: las válvulas y pipelines que se pueden crear para el File Adapter.

Flujo del File Adapter

El flujo que normalmente sigue el File Adapter para procesar un archivo de entrada, es el siguiente:

File System > (1) > File o FTP Adapter > (2) > Transformación (NXSD) > (3) > Proceso BPEL o Pipeline de OSB o Mediador

Donde:

(1) - El File Adapter lee el archivo o archivos de la ruta indicada

(2) - El contenido del archivo se traslada a un proceso de traducción donde mediante un NXSD transformamos el contenido a XML. El traductor publica el contenido hacia el SCA (tiempo de ejecución).

(3) - Finalmente, el SCA publica el contenido hacia el engine de servicio (BPEL, OSB, Mediator).

Flujo del File Adapter haciendo uso de Pipelines y Válvulas

En el caso de las válvulas y los pipelines, va a existir un paso intermedio, justo entre los pasos (1) y (2), el resto del flujo es el mismo.

De tal suerte que nuestro flujo de procesamiento quedaría como sigue:

File System >  (1) > File o FTP Adapter > (1A) > Pipeline > (1B) > Válvula > (1C) > File o FTP Adapter (2) > Transformación (NXSD) > (3) > Proceso BPEL o Pipeline de OSB o Mediador

Donde:

(1A) - El File Adapter va a trasladar el contenido hacia un Pipeline, que tiene asociadas válvulas de pre-procesamiento.

(1B) - El Pipeline va a ejecutar las válvulas de pre-procesamiento en el orden que nosotros indiquemos.

(1C) - La última válvula que se ejecute, va a devolver el control al Pipeline, y este a su vez va a devolver el contenido del archivo pre-procesado al FTP Adapter. A partir de ahí, el flujo es el mismo.

Implementación de la válvula

Implementar la válvula es relativamente simple. Vamos a necesitar dos proyectos: uno Java y un compuesto.

Proyecto Java

El proyecto Java contendrá básicamente el código fuente para la conversión de XLS a CSV. Para esto usamos, como dije antes, Apache POI.

La clase implementada es la siguiente:

package excelvalves;

import java.io.ByteArrayInputStream;

import java.io.ByteArrayOutputStream;

import java.io.IOException;

import java.io.InputStream;

import java.text.DateFormat;

import java.text.SimpleDateFormat;

import java.util.Date;

import java.util.Iterator;

import oracle.tip.pc.services.pipeline.AbstractValve;

import oracle.tip.pc.services.pipeline.InputStreamContext;

import oracle.tip.pc.services.pipeline.PipelineException;

import org.apache.poi.hssf.usermodel.HSSFWorkbook;

import org.apache.poi.ss.usermodel.Cell;

import org.apache.poi.ss.usermodel.Row;

import org.apache.poi.ss.usermodel.Sheet;

import org.apache.poi.ss.usermodel.Workbook;

public class ExcelToCsv extends AbstractValve {

    public InputStreamContext execute(InputStreamContext inputStreamContext) throws IOException, PipelineException {

        System.out.println("The valve will begin executing the inputstream");

        // Get the input stream that is passed to the Valve

        InputStream originalInputStream = inputStreamContext.getInputStream();

        ByteArrayOutputStream bos = new ByteArrayOutputStream();

        

        // Read workbook into HSSFWorkbook

        Workbook workbook = new HSSFWorkbook(originalInputStream);

        // Read worksheet into HSSFSheet

        Sheet datatypeSheet = workbook.getSheetAt(0);

        // To iterate over the rows

        Iterator<Row> iterator = datatypeSheet.iterator();

        //store the csv string

        StringBuffer data = new StringBuffer();

        

        int i = 0;

        //Loop through rows.

        while (iterator.hasNext()) {

            int j = 0;

            Row currentRow = iterator.next();

            Iterator<Cell> cellIterator = currentRow.iterator();

            while (cellIterator.hasNext()) {

                Cell currentCell = cellIterator.next();

                if (currentCell.toString().length() > 0 && i > 0) {

                    switch (currentCell.getCellType()) {

                    case Cell.CELL_TYPE_BOOLEAN:

                        data.append(currentCell.getBooleanCellValue() + ",");

                        break;

                    case Cell.CELL_TYPE_NUMERIC:

                        DateFormat df = new SimpleDateFormat("yyyyMMdd");

                        Date date = currentCell.getDateCellValue();

                        data.append(df.format(date) + ",");

                        break;

                    case Cell.CELL_TYPE_STRING:

                        data.append(currentCell.getStringCellValue() + ",");

                        break;

                    case Cell.CELL_TYPE_BLANK:

                        data.append("" + ",");

                        break;

                    default:

                        data.append(currentCell + ",");

                    }

                    if (j == 15) {

                        data.append('\n');

                    }

                }

                j++;

            }

            i++;

        }

        System.out.println("snippet from stream: " + data.toString());

        ByteArrayInputStream bin = new ByteArrayInputStream(data.toString().getBytes());

        inputStreamContext.setInputStream(bin);

        System.out.println("done processing the stream in the valve");

        return inputStreamContext;

    }

    @Override

    public void finalize(InputStreamContext inputStreamContext) {

        // TODO Implement this method

    }

    @Override

    public void cleanup() throws PipelineException, IOException {

        // TODO Implement this method

    }

}

Las librerías necesarias para el proyecto son las siguientes:

Lo siguiente es compilar, generar un perfil de despliegue y desplegar el proyecto en un JAR.

Proyecto SOA (compuesto)

Vamos a crear un compuesto con un File Adapter como servicio expuesto. En el asistente de configuración colocar lo siguiente:

Definir la interfaz posteriormente.

Mantener JNDI por default.

Seleccionar operación de lectura (no leer el contenido del archivo).

Leer cualquier archivo (*.*).

Frecuencia de lectura: 10 segundos.

Seleccionar el NXSD con el que convertiremos el CSV a XML.

Finalizar la configuración.

Una vez que tenemos el adaptador listo, vamos a crear el Pipeline. Para esto basta con crear un archivo XML nuevo (ExcelPipeline.xml), debajo de la carpeta SOA:

Este archivo XML va a definir el orden en que se van a ejecutar las válvulas. Aquí lo único que hay que colocar es el nombre de las clases que hemos creado en el proyecto Java (completamente calificadas): en mi caso excelvalves.ExcelToCsv, que fue el nombre que le puse a mi clase donde implementé la válvula. Aquí podemos agregar una o más, dependiendo de nuestras necesidades de implementación.

Finalmente, vamos a agregar en el archivo de configuración del adaptador (JCA), la referencia hacia el Pipeline: <property name="PipelineFile" value="ExcelPipeline.xml"/>

Después de esto, ligamos el adapter a un proceso BPEL. De tal suerte que nuestro compuesto queda de la siguiente forma:

Debajo de la carpeta SCA-INF/lib, debemos colocar el JAR generado de nuestra válvula (el que generamos en el proyecto Java).

Desplegamos el proyecto del compuesto a nuestra infraestructura y lo probamos colocando un archivo de Excel en la ruta que configuramos en nuestro File Adapter.

Deberá iniciarse una instancia y aparecer lo siguiente en nuestros logs:

En Enterprise Manager podremos ver que la instancia se ha ejecutado correctamente:

Los detalles de la traza:

En este caso el BPEL no hace otra cosa sino un assign de la entrada a una variable para posteriormente terminar:

Observamos que los datos provenientes del Excel han sido asignados de manera correcta a la variable:

Comprobamos que todo se haya realizado bien, comparando con los datos de nuestro archivo de Excel:

Resumen

• Las válvulas pueden servir para pre y/o post procesamiento (archivos de entrada y/o de salida).
• Las válvulas serán ejecutadas en el orden que definan dentro del pipeline.
• El pipeline a usar se configura dentro del archivo JCA del adaptador.
• El pipeline se define en un archivo XML.
• Las clases de pre y/o post procesamiento se implementan en Java y reciben como entrada un InputStream.
• Se pueden utilizar frameworks adicionales dentro de las clases Java que implementan la lógica de nuestras válvulas. En mi caso utilicé Apache POI para el procesamiento del archivo Excel (https://poi.apache.org/).
• El JAR que contiene la implementación de las válvulas se debe incluir en el proyecto (compuesto, OSB) que lo utiliza. Para el caso de un compuesto, lo ponemos debajo de SCA-INF/lib.

Integración Continua - Parte 1

Integración Continua

Vamos sin rodeos. Hace un buen rato que no escribía una entrada en el blog. Así que vamos al grano. En la siguiente serie de entradas, me ocuparé de un tema muy interesante (al menos para mi): Integración Continua.

Les parecerá un tópico normal, seguramente en los últimos años/meses han escuchado mucho de esto. Pero, ¿en realidad han tenido alguna relación directa con un algún ambiente de integración continua? Hasta hace algunos meses, yo no. Quizá en alguno que otro experimento, tras bambalinas, pero no de manera directa.

Oracle. "Es el producto que yo manejo", se diría por ahí (1). Así que exploraremos algunos conceptos básicos y una serie de herramientas que podrían ayudar a desplegar un entorno de integración continua, para Oracle Fusion Middleware.

Servicios y Microservicios: SOA

Como ésta entrada no está dedicada a discutir si los microservicios reemplazan a SOA, ni tampoco a determinar si SOA es el padre de los microservicios, vamos a centrarnos en la forma en que se construye (típicamente) una aplicación.

En la mayoría de los proyectos en que hemos participado existen pequeños grupos de personas, que en conjunto hacen un equipo de trabajo completo. Cada uno de esos grupos realiza una tarea definida, trabaja en el ámbito en el que está especializado: administración del proyecto, desarrollo (cualquier tecnología), pruebas, infraestructura, soporte y demás. Así cada equipo colabora con una pequeña parte del proyecto, para al final construir una aplicación integral en la que conviven todas las piezas. ¿Les suena esto en donde cada quien hace un pedazo de todo el trabajo? ¿Servicios? ¿SOA? Acordamos no hablar de eso, sigamos.

Agilidad

Otro concepto que hemos escuchado mucho es el de la agilidad. Aquí es donde comienza a tener importancia la metodología que utilizamos para implementar un proyecto de software. Lo sentimos por aquellos que se identifican con la metodología en cascada, pero desde mi punto de vista eso ya quedó atrás. Muchos años atrás.

Las metodologías ágiles nos ayudan a implementar estrategias iterativas que permiten descubrir errores en etapas más tempranas del proyecto. Por lo tanto, podemos corregirlos de manera anticipada y durante cada iteración, también podemos incluir funcionalidad nueva que haga que el desarrollo sea incremental.

Una parte fundamental de ser ágil es: el negocio cambia constantemente. ¿Qué tan constantemente? Tal vez les suene que a la mitad de los proyectos o, incluso, ya prácticamente cuando se encuentran desplegando sus componentes, al usuario se le ocurre cambiar alguna regla o definición de negocio. O varias.

Entre más pequeñas sean las piezas que construimos y más rápido las pongamos en pruebas, validación y operación, la vida se vuelve mucho más simple. Podemos agregar, modificar o eliminar funcionalidad de acuerdo a las nuevas necesidades. Una vez por año, una vez por mes. Quizá una vez por día. Al usuario eso no le interesa, su interés se centra en qué tan rápido ve funcionando el producto que solicitó.

¿Se imaginan generar un JAR, WAR, EAR, EXE, o cualquier cosa que ustedes generen, una vez al día? ¿Desplegarlo, probarlo, validarlo, monitorearlo y dar soporte a la producción? Ahora imaginen eso, multiplicado por las decenas o cientos de componentes que generaron. Quizá justo en este momento quieran darle una oportunidad al concepto de integración continua.

Concepto

El concepto de libro es el siguiente: la integración continua es una práctica de la ingeniería de software enfocada en mejorar la calidad y reducir el tiempo de entrega de una pieza de software. Esto se logra aplicando pequeños pero frecuentes esfuerzos en el control de la calidad. Uno de los fines de la integración continua es ayudar a las organizaciones a automatizar despliegues y pruebas de los componentes desarrollados.

Prácticas clave

Para lograr establecer un entorno de integración continua, es necesario llevar a cabo una serie de prácticas clave:

1. Un control de versiones que es utilizado para dar seguimiento a los cambios.
2. Los desarrolladores realizan commit hacia el control de versiones todos los días.
3. El producto (build) es realizado después de cada commit.
4. El build debe ser automático.
5. El despliegue debería ser automático hacia los ambientes de desarrollo, pruebas y producción.
6. Las pruebas del producto deberían estar automatizadas.
7. Los resultados del build deben ser públicos, de esta manera cualquier persona podrá enterarse cuando sus cambios son incorrectos e impiden que el build se complete de manera satisfactoria.
8. Los entregables deben estar disponibles para desarrolladores, equipo de pruebas y cualquier otro stakeholder del proyecto.

Soporte de integración continua, Oracle

Como mencionamos en un principio, esta serie de entradas se centrará en tecnología Oracle. ¿Cómo Oracle soporta un entorno de integración continua?

1. Oracle JDeveloper se integra con los sistemas de control de versiones más comunes.
2. Capacidad de realizar el build desde la línea de comandos usando Maven, así el build puede ser automatizado.
3. Capacidad de crear nuevos proyectos usando los arquetipos de Maven.
4. Capacidad de descargar las dependencias de los repositorios de Maven.
5. Capacidad de parametrizar los scripts, así los builds pueden ser desplegados hacia varios entornos (desarrollo, pruebas, producción).
6. Capacidad de incluir pruebas de los proyectos en el ciclo de vida de Maven.
7. Capacidad de poblar el repositorio de Maven con dependencias de Oracle desde un directorio de instalación de productos de Oracle (Oracle Home).
8. Capacidad de gestión de los builds con servidores de integración continua (como Hudson).

Componentes de integración continua

En el mercado hay disponibles un buen número de opciones tecnológicas para la implementación de un entorno de integración continua. Algunos de estos componentes pueden ser de uso gratuito (open source) y algunos otros pueden ser productos comerciales. Para nuestro ejemplo vamos a usar lo siguiente:

1. Apache Subversion como sistema de control de versiones.
2. Apache Maven para creación y automatización de los builds.
3. Apache Archiva como administrador del repositorio de Maven.
4. Apache Hudson como servidor de integración continua.

Apache Subversion

Un control de versiones funciona como repositorio de artefactos de código. A este repositorio tienen acceso los desarrolladores usando un cliente de Subversion. Los equipos de desarrollo pueden copiar artefactos desde y hacia el repositorio. El control de versiones lleva un registro de quién y qué ha cambiado en los artefactos de código (aquel que rompa el build, deberá pagar el desayuno del día siguiente).

• Se integra de manera natural con JDeveloper.
• Soporta distintas opciones de autenticación, incluyendo la autenticación vía un certificado.
• Funciona bien en entornos de red.
• Para proyectos de Oracle SOA Suite, provee de commit atómico, que permite actualizar varios archivos como parte de un mismo commit.

Apache Maven

Maven es un sistema de administración de proyectos y builds. Tiene capacidades de administración de proyectos (no piensen en MS Project, por favor) en términos de:

• Nombrado y versionamiento.
• Dependencias.
• Ubicación del código.
• Ubicación de los builds.
• Plantillas de proyectos.
• Proceso de liberación.

También tiene capacidades de administración de builds en términos de:

• Cómo ejecutar el build.
• Pasos a realizar en cada fase.
• Parametrización del build.
• Extensión del framework.

Una instalación típica de Maven consiste de la instalación de Maven en la máquina de cada desarrollador, un repositorio de Maven compartido al interior de la organización y múltiples repositorios públicos de Maven donde están almacenadas las dependencias. Estos repositorios públicos almacenan librerías que pudieran ser usadas como dependencias en el desarrollo de nuestros proyectos.

Apache Archiva

En ocasiones nos viene a la mente ¿por qué usar un administración de repositorios de Maven? La respuesta a esto es que algunas organizaciones encuentran útil tener un repositorio interno de Maven. Las razones pudieran ser las siguientes:

• Actuar como intermediario o caché de repositorios externos. Así el repositorio central (interno) descargaría las dependencias una única vez y las almacenaría en caché para que los desarrolladores las puedan utilizar.
• Para almacenar los artefactos que se desarrollen al interior de la organización y que estos puedan ser compartidos con otros equipos de desarrollo o proyectos.

Apache Hudson

Hudson es un servidor de integración continua muy utilizado y nos ayudará a automatizar el proceso de creación de builds. Los pasos que se contemplan en la automatización pueden ser los siguientes:

• Iniciar el proceso de build siempre que un desarrollador realice un commit hacia el sistema de control de versiones.
• Descargar el código del sistema de control de versiones.
• Compilar el código.
• Ejecutar pruebas unitarias.
• Empaquetar el código en un archivo con formato de despliegue (JAR, por ejemplo).
• Desplegar el archivo hacia un ambiente de ejecución.
• Ejecutar pruebas de integración.
• Enviar notificaciones ante fallas en el proceso.

Resumen

En la primer entrada de esta serie, hemos explorado algunos conceptos, beneficios y necesidades que se cubren al implementar un entorno de integración continua al interior de una organización.

Se ha dado un breve resumen de lo que cubriremos en las siguientes entradas del blog, para mostrar cómo un entorno de integración continua nos proporciona capacidades de automatización de builds, administración del código, documentación, automatización de pruebas, despliegue hacia distintos entornos (desarrollo, pruebas, producción), entre otras.

Vamos a usar tecnología de Apache para: control de versiones (Subversion), administración de proyectos y builds (Maven), administración de repositorios de Maven (Archiva) y servidor de integración continua (Hudson).

Citas

(1) Gerardo "Ellera" Nieves

Instalación de Oracle Real-Time Integration Business Insight

Introducción

Oracle Real-Time Integration Business Insight está especialmente diseñado para que los usuarios de negocio puedan modelar, recolectar y monitorear métricas del negocio. Insight se integra completamente con Oracle SOA Suite y Oracle Service Bus.

Oracle Real-Time Integration Business Insight permite que el usuario de negocio tenga el control del contenido, tiempo y formato de las métricas que necesita para tomar decisiones de negocio con pleno conocimiento del comportamiento diario. Esto es posible al identificar los puntos clave dentro de sus integraciones de negocio, los responsables del negocio tienen acceso inmediato a datos detallados, en tiempo real, sin costosos compromisos de ingeniería o redespliegues.

Este artículo detalla los pasos de la instalación y configuración del ambiente en un dominio completo de Oracle SOA Suite: SOA + Service Bus + BAM.

Instalación del dominio completo de Oracle SOA Suite

Dado que Oracle Real-Time Business se integra por completo con Oracle SOA Suite y Oracle Service Bus, hemos puesto un dominio completo para aprovechar al máximo sus características.

A continuación, se resumen los pasos de ésta instalación. Cabe mencionar que la versión de la SOA Suite que se utiliza para Insight es la 12.2.1:

• Instalar JDK 1.8
• Instalar Oracle Fusion Middleware Infrastructure
• Instalar Oracle SOA Suite
• Instalar Oracle Service Bus
• Ejecución de RCU
• Creación del dominio (SOA + OSB + BAM)

Para mayor detalle acerca de la instalación de esta versión, consultar la documentación oficial de Oracle:

https://docs.oracle.com/cd/E23104_01/download_readme_1221/download_readme_1221.htm

Una vez que tenemos instalado nuestro dominio de Oracle SOA Suite 12.2.1, se deben seguir los pasos que se describen a continuación para la configuración de Oracle Real-Time Integration Business Insight.

Configuración de Oracle Real-Time Integration Business Insight

Descarga y aplicación de parches

El primer paso, es instalar los parches de Oracle Real-Time Integration Business Insight en el dominio de SOA. Para esto es necesario descargarlos de la siguiente ruta:

http://www.oracle.com/technetwork/middleware/insight/downloads/index.html

Una vez descargados los parches, se colocan debajo del directorio OPatch de nuestro dominio (únicamente los archivos ZIP). La aplicación de los parches es como ya conocemos, ejecutando debajo de la carpeta OPatch del dominio de SOA, el comando:

opatch apply archivo_parche.zip

El orden de instalación de los parches es el siguiente:

1. p22189824
2. p22655174
3. p22659236

Una vez aplicados los parches al dominio, será necesario extenderlo. Como se detalla a continuación.

Configuración del dominio

Para la configuración del dominio, debemos ejecutar el siguiente comando:

Ruta: MW_HOME\oracle_common\common\bin:

Comando: config.sh (para Windows es config.cmd)

Esto abrirá el asistente de configuración de nuestro dominio, únicamente debemos indicar que vamos a extender un dominio existente y seleccionar la ruta del dominio de SOA.

En los siguientes pasos, encontraremos las plantillas que podemos aplicar a nuestro dominio existente. Para poder configurar Insight de manera adecuada, es necesario elegir las siguientes plantillas:

• Insight SOA Agent 12.2.1
• Insight Service Bus Agent 12.2.1
• Insight 12.2.1

Inicio del dominio

Básicamente estamos en la parte final de la configuración de nuestro dominio de Insight. Ahora lo único que debemos hacer es levantar nuestros servidores (administrador y manejados) y tendremos disponible la consola de Oracle Real-Time Integration Business Insight.

Despliegues

Si hicimos bien los pasos anteriores, en la consola de administración de WebLogic, debemos observar los siguientes despliegues:

Podemos observar que la interfaz de usuario se encuentra desplegada dentro de bam_server. En osb_server y soa_server están instalados los agentes (que seleccionamos en la reconfiguración de dominio).

Si expandimos el despliegue de la interfaz de usuario, encontraremos un módulo llamado insight. Al ver los detalles del módulo en la pestaña de pruebas, podemos ver la URL de la consola de Oracle Real-Time Integration Business Insight:

Consola de Oracle Real-Time Integration Business Insight

La consola del producto se verá de la siguiente manera:

Al colocar las credenciales válidas, esto es lo que veremos:

Nuestro producto está correctamente instalado y listo para usarse. En siguientes artículos vamos a crear una demostración real del producto con un caso ficticio para hacer notar sus capacidades y beneficios.

Instalación de un Compact Domain de Oracle SOA Suite 12.2.1

Instalación de Compact Domain de Oracle SOA Suite versión 12.2.1

Ya a finales de noviembre de 2014, nuestro amigo Rolando Carrasco (@borland_c) había creado una entrada en Oracle Radio para separar la configuración de un dominio de JDeveloper, usando la instalación Quick Start de la Oracle SOA Suite. Esto lo hacía en la versión 12.1.3.

El post que menciono, se encuentra aquí:

http://oracleradio.blogspot.mx/2014/11/oracle-soa-suite-12c-standalone.html

Pues en la nueva versión de Oracle SOA Suite (12.2.1), liberada en septiembre pasado en San Francisco durante el Oracle Open World de 2015, también es posible crear un dominio de tipo standalone (separado de JDeveloper). A este tipo de dominio se le conce como compact domain.

Hay una variante en los pasos a seguir para crear este tipo de dominio en la versión 12.2.1, y aquí los documentamos:

El primer paso es establecer una variable de ambiente con el siguiente valor:

CONFIG_JVM_ARGS=-Dcom.oracle.cie.config.showProfile=true

En ésta versión ya no existe el comando qs_config, por lo que es necesario setear la variable de ambiente anterior, para habilitar la opción de crear un dominio compacto en el wizard de configuración del dominio que ya conocemos. Este wizard no se utilizaba para generar un compact domain en la versión 12.1.3.

Posteriormente vamos a la siguiente ruta:

ORACLE_HOME/oracle_common/common/bin

Ahí ejecutamos el siguiente comando:

config.cmd (en Windows) config.sh (en Unix, Linux, etx)

Lo que sigue es elegir el tipo de dominio que vamos a crear, en este caso generaremos un dominio compacto. Elegimos la opción que corresponde. Esta opción no está habilitada normalmente al correr el config.cmd, se habilitó al crear la variable de ambiente que mencionamos al inicio.

Elegimos las plantillas de los productos que deseamos instalar, en este caso SOA y OSB.

Elegimos el directorio donde estarán instaladas las aplicaciones del dominio.

Colocamos el nombre del usuario de administración del dominio.

Definimos el modo de nuestro dominio y la ubicación del JDK (esta versión funciona con JAVA 8, a diferencia de 12.1.3 que funcionaba con JAVA 7).

Al momento de configurar la base de datos, seleccionamos la base de datos embebida (JAVA BD, Derby).

Dejamos las opciones que vienen por default para el almacén de claves.

Seleccionamos el servidor que vamos a crear. En este caso sólo vamos a elegir el servidor de administración. Debemos recordar que en un compact domain toda la infraestructura de SOA se encuentra dentro del servidor de administración, no tenemos servidores manejados.

Configuramos la dirección de recepción y puertos para el servidor de administración.

Finalmente, revisamos la configuración del dominio y procedemos a crearlo.

Iniciamos nuestro servidor como normalmente lo hacemos, con startWeblogic.cmd

Finalmente, una vez que inicia nuestro servidor, tenemos disponible nuestro dominio.

WebLogic Console:

 aba

Enterprise Manager:

Service Bus Console:

Con esto, tenemos un dominio compacto de Oracle SOA Suite en la versión 12.2.1. Este dominio, a diferencia del Integrated Server, está completamente separado de JDeveloper y podemos gestionarlo y usarlo de manera independiente.

Favor de consultar la documentación de oficial de Oracle para detalles adicionales:

https://docs.oracle.com/middleware/1221/core/SOAQS/GUID-79114282-39B6-4EBF-853F-73158636BAA2.htm#SOAQS220