Archivo

Posts Tagged ‘REST’

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: , , ,

Revista Oracleando nº 9 (SPOUG, febrero 2018)

febrero 9, 2018 Deja un comentario

Se ha publicado el número 9 de la Revista Oracleando, editada por SPOUG – Spain Oracle Users Group, en esta ocasión dedicada, especialmente, a casos de usuario destacados durante el 2017. El lanzamiento de este último número ha aparecido en el marco del evento nacional más relevante del sector TI, Oracle Digital Day.

avanttic (socio institucional de SPOUG) ha colaborado en este número con publicidad sobre el nuevo site de servicios paquetizados de Oracle Cloud, centrado en acelerar el viaje de nuestros clientes hacia la nube.

Aparece nuestro caso de éxito con Industrial Farmacéutica Cantabria (IFC), que gracias a Oracle Mobile Cloud Service ha conseguido que sus comerciales sean más eficientes mediante la integración automática con su CRM.

Además hemos publicado un artículo titulado Construye tu arquitectura móvil en Oracle Cloud, en el que Rubén Rodríguez (Cloud Solution Specialist de avanttic) aborda la movilidad como punto clave en la era digital y como ventaja competitiva frente a los nuevos desafíos. En este artículo, Rubén, explora las diferentes opciones disponibles para construir e integrar una arquitectura móvil dentro del Cloud de Oracle; así como las diferentes opciones para desarrollar aplicaciones móviles con garantía para llevar a cabo la transformación digital de las organizaciones.

Si desea la edición impresa puede recogerla en nuestras oficinas o asistiendo a alguno de nuestros eventos.

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…

Oracle Integration Cloud Service – Parte 2

marzo 21, 2017 1 comentario

orquestacion_ejemplo

En el anterior post, Oracle Integration Cloud Service – Parte 1, hicimos una introducción al producto y comentamos el modelo de adquisición. En éste veremos un ejemplo orquestando una integración entre servicios de Yahoo y Twitter.

Ejemplo de integración ICS

Crearemos un servicio REST que twiteará el clima actual de nuestra ubicación al asignarle los parámetro de ciudad y país. La cuenta Twitter debe existir y será configurada previamente. Para obtener los datos del clima actual se consultará el servicio Yahoo Weather.

Nuestro servicio será REST y funcionará con una llamada http GET y parámetros “ciudad” “pais”, de la forma:

https://<host ics>:<port>/integrations/tweetweather/<ciudad>/<pais>

El código fuente del proyecto es importable a ICS si utilizamos el empaquetado fichero “iar”, disponible en GitHub.

Al terminar la orquestación tendríamos que ver en el diseñador ICS la imagen que mostramos a continuación:

uno

Ahora, describiremos paso a paso cómo conseguirlo: Leer más…

Categorías:Tech - Integration Etiquetas: , ,

Publicar y securizar ADF Business Components como servicios REST

En ADF 12.2.1, que fue liberado justo antes de Oracle Open World 2015, se introdujeron muchas nuevas funcionalidades y mejoras, y una de ellas es la de exponer los ADF Business Componentes (ADF BC) como servicios REST.

La primera cosa que debemos hacer es configurar la Release Version de REST. Esto se puede hacer en el fichero adf-config.xml

1

En versiones anteriores podíamos exponer los ADF BC como servicios SOAP (desde la pestaña Web Services en el Application Module) y en esta última versión también podemos elegir REST.

2

Podemos elegir las instancias de las vistas que deseemos y asignarles un Resource Name.

3

Automáticamente se creará un fichero XML donde podremos seleccionar los atributos que queramos exponer, así como si también deseamos exponer métodos personalizados que hayamos creado en la clase de implementación de la vista.

Leer más…