Archivo

Posts Tagged ‘JSON’

Analizar, Aconsejar, Automatizar… las nuevas funciones del DBA

Los pasados 21 y 27 de junio, en Barcelona y Madrid respectivamente, celebramos los últimos meetups de los grupos Oracle Database meetups para DBAs y Arquitectos  de ambas ciudades antes de las vacaciones. En nuestro primer encuentro, realizado el pasado mes de febrero, nos habíamos centrado en conocer la última tecnología en Servicios en la nube de Oracle Database/Autonomous Database. En el segundo, celebrado en abril, nuestra atención se dirigió al análisis, almacenamiento y acceso a datos, ya estén almacenados en una base de datos SQL o no-SQL o en Big Data.

Esta vez la temática fue algo distinta: quisimos valorar cómo está cambiando el día a día de los profesionales que conforman nuestros grupos, los DBAs, y cuáles son los nuevos roles que estos deben asumir. Para ello contamos con dos especialistas de bases de datos de Oracle y con un desarollador de Fusion Middleware de avanttic.

Un DBA lleva a cabo todas las actividades relacionadas con el mantenimiento de un entorno de base de datos: diseño, implementación, mantenimiento del sistema, establecimiento de políticas y procedimientos relativos a la gestión, la seguridad… en resumen: un DBA es un Administrador.

Partiendo de esa “A”, la de Administrar, quisimos jugar a descubrir cuáles son las nuevas funciones, todas escritas con “A”, que estos profesionales deben asumir hoy en día. Guillermo Best, Cloud Platform Presales Manager de Oracle, empezó los meetups dejando un claro mensaje a los asistentes: “En un mundo tan interconectado, desarrollar aplicaciones de calidad requiere que alguien se tome tiempo para pensar. Se manejan grandes cantidades de datos, e históricamente han sido los DBAs los que han estado más cerca de los datos. Por ese motivo, son ellos los más capacitados para decidir qué aporta valor, ofreciendo sus recomendaciones a los desarrolladores”. Esa fue la primera de las “A” del Meetup: Aconsejar.

Leer más…

Invocar Servicios REST, tipo POST, con JSON en BPEL 12c

El adaptador REST es una importante característica en la versión 12c de Oracle Middleware. Nos permite la exposición e invocación de servicios REST de una forma sencilla, disponiendo también de integración con objetos JSON. En este post vamos a ver cómo podemos consumir un servicio REST de tipo POST que requiera de un objeto JSON como entrada al mismo, y cómo trabajar con dicho objeto desde un proceso BPEL. Empezaremos generando un nuevo proceso BPEL, sobre nuestro proyecto SOA (ya generado). En nuestro caso va a ser un proyecto síncrono.

Leer más…

Categorías:Tech - Integration Etiquetas: , , ,

Uso de servicios REST y ficheros complejos con ODI 12c (II)

odirwsEn la primera parte de este post vimos como realizar una petición vía REST Webservice a la API de Geocoding de google con ODI 12c, a partir de una dirección almacenada en una tabla en nuestra BD Oracle.

En esta segunda parte veremos como acceder al fichero de respuesta obtenido en la primera parte y actualizar la tabla original con las coordenadas UTM contenidas en el fichero JSON, para lo que deberemos:

  • Crear un fichero XSD que defina la estructura del fichero JSON
  • Configurar la topología física para el acceso al fichero JSON
  • Desarrollar un mapping que lea el fichero JSON y actualice la tabla, y un package que coordine la ejecución

Para comprender mejor los pasos que vamos a seguir en el package, sería interesante primero dar un vistazo rápido al capítulo de la descripción general del funcionamiento del procesamiento de ficheros complejos, en la documentación oficial de ODI 12c. Dicho documento queda resumido en el siguiente esquema, y descibre como el fichero complejo (JSON en nuestro caso) es traducido y cargado al vuelo por el driver en un esquema de BD, que será con el que trabajaremos en realidad (aunque de manera transparente).

ODI_JSON_CFD_Process

A nivel de topología necesitamos definir dentro la tecnología “Complex File” un DataServer (al que llamamos Coordenates) y un modelo físico (al que también llamamos Coordenates) como se aprecia en la siguiente captura:

ODI_JSON_TOPOLOGIA

Utilizaremos el botón “Edit nXSD” para invocar un asistente que nos ayudará con la creación del fichero nXSD que define la estructura del fichero JSON a procesar.

Leer más…

Servicios REST: Uso de parámetros en URI y payload

Muchas veces, al diseñar o usar servicios REST externos, nos encontramos con que, a parte de los parámetros del payload, requieren de parámetros en la URI, como el caso común de versionado de los servicios. Un ejemplo de ello sería el siguiente servicio: http://localhost:7001/empleados/{version}/actualizacion/ donde, a parte de los datos del empleado a actualizar, necesitamos informar de la versión del servicio REST.

La versión 12c del Bus de Oracle nos permite configurar estos servicios destinados a mapear uno de los parámetros de entrada del servicio como parámetro de la cabecera. Con ello ya podremos invocar al servicio correspondiente con el payload adecuado, y el objeto json para la actualización de los datos del empleado no tiene por qué contener el valor de la versión del compuesto.

A lo largo del siguiente ejemplo, iremos descubriendo como mapear estos parámetros y configurar el servicio de forma dinámica.

El primer paso sería la generación de un nuevo proyecto.

Seleccionamos Service Bus Project:

Le pondremos como nombre ServicioRestEjemplo y pulsaremos en Finalizar.

Una vez generado el proyecto, configuraremos el servicio REST al que invocar. Para ello, desde el composite, con botón derecho en External Services generamos un binding REST.

Leer más…

Categorías:Tech - Integration Etiquetas: , ,

Uso de servicios REST y ficheros complejos con ODI 12c (I)

odirwsHace unos días me encontré frente a una tabla de direcciones con coordenadas UTMS en la que faltaban las coordenadas de diez registros de entre más de tres mil. Iniciar el proceso para que los usuarios afectados actualizasen los datos de los registros de su responsabilidad llevaría inevitablemente cierto tiempo hasta su resolución, así que decidí echar mano de Google.
Rápidamente identifiqué la API necesaria (Geocoding) y elegí el formato  para la respuesta. Verifiqué el funcionamiento con una invocación manual, exploré el fichero .json de respuesta (> 6Kb) y hallé los 50 bytes con los datos que buscaba. Los comprobé con la función inversa, introduciendo las coordenadas obtenidas en Google Maps, que me ubicó en la dirección original. Veamos un ejemplo:

https://maps.googleapis.com/maps/api/geocode/json?address=Aragó+180,+Barcelona&key=************************

Tras esta verificación pensé: ya sólo me faltan nueve. Así que siendo pragmático, hice unos cuantos cut&paste y completé en unos minutos las coordenadas de los diez registros. Pero me quedé con una inquietud: ¿qué habría ocurrido si en lugar de sólo diez hubieran habido más de tres mil registros sin coordenadas?
La respuesta fue clara: automatizarlo con ODI. Y así fue como se originó la decisión de escribir este post, ilustrando la solución a dos necesidades bastante cotidianas:

  • Utilizar un servicio REST para obtener datos de la web
  • Procesar un fichero JSON

Tanto el orden de las necesidades como “el sentido” del flujo de datos pueden variar, así como su relación con alguna de las tablas en BD (que en nuestro caso, será una tabla con direcciones), no obstante espero que el ejemplo sea suficientemente ilustrativo.
Una segunda motivación para este post es la “actualización de conocimientos”. Estas dos tareas ya eran posibles con ODI 11g, pero veremos que ODI 12c simplifica su ejecución y a la vez nos ayuda a conservar los desarrollos más ordenados.

Utilizar un servicio REST para obtener datos externos

La llamada es sencilla, la API sólo requiere dos parámetros:

  • la dirección buscada (formateando adecuadamente los espacios, numeración y comas)
  • la clave de desarrollador para poder utilizar la API (que es constante)

Quizá lo más complicado sea parsear la respuesta, pues hay cierta redundancia de datos, y utilizar el formato XML en lugar de JSON tampoco variaría mucho. Así pues, iremos por partes: primero obtendremos los datos de la respuesta del servicio y después procesaremos la respuesta (fichero .json).
Para configurar el servicio, lo primero que necesitamos crear es un “Data Server” al que llamaremos “GoogleGeocod”, que apuntará a la URL del endpoint del servicio REST: https://maps.googleapis.com.
Acto seguido, crearemos un esquema físico bajo el nuevo servicio:

ps_geocode

Leer más…