Archive

Posts Tagged ‘Integración’

Crónica PaaS Partner Community Forum (Split, 27-31 marzo 2017)

Del 27 al 31 de marzo se celebró en Split (Croacia) el PaaS Partner Community Forum XXIV. Es el encuentro anual de la Comunidad de Partners de Fusion Middleware de Oracle de EMEA. En esta edición, más de 200 personas de 40 países diferentes, asistieron durante las jornadas generales del congreso organizado por Jürgen Kress, Oracle FMW Partner adoption. avanttic, representada por 3 personas, contribuyó de forma destacada al éxito del encuentro, como veremos a continuación.

El enfoque central del Forum de este año fue la Plataforma como Servicio (PaaS), cambiando incluso el nombre del acontecimiento y su hastag por #PaaSForum. Este año cabe destacar la participación de avanttic en diferentes iniciativas promovidas por la organización del congreso:

  • La primera jornada del congreso consistió en una serie de presentaciones de speakers de la comunidad, ACE y Product Managers. En esta ocasión, Rubén Rodríguez, Cloud Solution Specialist en avanttic, presentó una ponencia sobre los beneficios de Mobile Cloud Service en las soluciones de movilidad desarrolladas por avanttic.
  • Durante la segunda jornada, en la introducción Jürgen Kress habló de los retos conseguidos por algunos partners y mencionó a avanttic por ser el primer partner a nivel mundial en haber conseguido la especialización en Oracle Mobile Cloud Service.

 

  • Él mismo presentó delante de la audiencia la aplicación Try&Win, construida por avanttic con tecnología Oracle (Oracle MCS & Oracle JET) y retó a los asistentes a descargarla y participar en la consecución de los retos propuestos (relacionados con IoT y redes sociales), con el objetivo de participar en un sorteo digital que se realizaría al finalizar el evento. Try&Win permitió disfrutar a los asistentes de una experiencia SMACT (Social, Mobile, Analytics, Cloud, IoT) mediante una aplicación móvil (iOS y Android) desde la que los participantes tuvieron que interaccionar con twitter y localizar y “capturar” beacons que se encontraban ubicados en el hotel y un restaurante, y el resto estaban repartidos entre personas de Oracle y de avanttic.

Ver vídeo experiencia TryAndWinApp

Leer más…

Oracle Forms 12c – Integración con Oracle BI Publisher

Una de las nuevas funcionalidades de Oracle Forms 12c es la integración nativa con Oracle BI Publisher.

biPublisher

Antes de la versión 12c, solamente se podía utilizar Oracle Forms con BI Publisher de estas 4 formas:

  • Llamando a la aplicación BI Publisher via URL
  • Integrando las clases de BI Publisher dentro de Forms y usando las funciones de la API
  • Programando un servlet y usando las funciones de la API
  • Llamando a sus Web Services desde Forms

Gracias a esta nueva funcionalidad podemos combinar en nuestra aplicación el uso de Oracle Reports y de Oracle BI Publisher.

Esta integración se ha diseñado para que sea muy parecida a la que nos ofrece Oracle Reports con RUN_REPORT_OBJECT. Por tanto, para poder diferenciar entre que tipo de informe vamos a ejecutar, Oracle ha creado la nueva propiedad REPORT_OBJECT_TYPE, que podemos encontrar en las propiedades del objeto “Informe en el navegador de objetos de Oracle Forms. Esta propiedad puede tener uno de los siguientes valores:

  • OraReports:  Oracle Reports
  • OraBIP: Oracle BI Publisher

Debemos tener en cuenta que la llamada a BI Publisher, a través de la integración nativa con Forms, siempre es asíncrona.

Leer más…

Prueba real de integración de GoldenGate y Data Guard

En este post aportamos un ejemplo de integración de GoldenGate y Oracle Data Guard, aprovechando de cada uno sus mejores funcionalidades.

En primer lugar comentar que en ocasiones existen dudas sobre los usos “objetivo” de GoldenGate y Data Guard, en la siguiente gráfica podemos ver una descripción genérica de sus posibilidades.

gg_vs_sb

A grandes trazos, Data Guard nos aporta un entorno de recuperación ante desastres sólido y de alto rendimiento ideal para BBDD productivas críticas y con posibilidades de ser usado simultáneamente como entorno de bakup, reporting y pruebas.

GoldenGate por su parte es una herramienta de réplica heterogénea en tiempo real, de una enorme flexibilidad. Nos permite seleccionar de manera precisa los datos a replicar, enviar a cada destino solo los datos necesarios e incluso aplicar transformaciones en estos datos replicados. Todo ello sin ser intrusivo en las BBDD origen  y permitiendo replicas entre BBDD de diferentes tipos y fabricantes.

El cliente al que se le planteó esta arquitectura disponía en origen de un RAC productivo de 2 nodos y requería:

  1. Una solución de “Disaster Recovery” para su BBDD principal dentro del plan de “Bussines Continuity”. Este entorno de DR debería consistir en una réplica total de la BBDD en una ubicación remota, asegurando una pérdida de datos “cero” en caso de problemas.
  2. Descargar de su entorno principal ciertas selects realizadas por parte de sus clientes/proveedores. Un destino objetivo para estas selects eran BBDD en el “cloud”, por aportar flexibilidad y posibilidad de crecimiento bajo demanda.

La arquitectura planteada consistió en una BBDD Standby en un datacenter remoto replicada mediante Data Guard, así como la réplica de los datos necesarios para las selects mediante GoldenGate en BBDD remotas en el cloud. El siguiente esquema muestra la solución planteada:

solucion_planteada

Solución técnica:

  • La configuración de recuperación ante desastres con Data Guard consiste de un RAC de dos nodos en el CPD origen y una BBDD standby monoinstancia en el datacenter remoto.  La configuración mediante DataGuard permite conmutar el rol de las BBDD en unos pocos minutos, un alto rendimiento en la replica de la información y una perdida de datos “cero” en caso de problemas.
  • La BBDD que actúe como principal, independientemente de la que sea, está configurada para enviar la información de “redo” que genera además de a la correspondiente standby a una tercera BBDD que llamaremos “Downstream Database“.
  • En esta “Downstream Database” se ha configurado GoldenGate integrado con LogMiner para capturar los cambios de la BBDD productiva extrayendo estos del la información de “redo” recibida, la captura de datos por tanto no es un proceso intrusivo (no interfiere la BBDD principal para realizar la captura). Para optimizar más incluso el rendimiento se plantea configurar GoldenGate para capturar solo los datos del subconjunto de tablas implicado en las selects a externalizar (ignorando los cambios del resto de tablas).
  • Es el mismo GoldenGate quien, una vez capturados los cambios, los envía a las máquinas remotas y los aplica en sus respectivas BBDD. Las máquinas remotas sólo reciben el subconjunto de datos necesario para cada una de ellas, no todos los datos capturados. Las BBDD remotas pueden ser de fabricante, versión, arquitectura y dimensionamiento totalmente diferente a las originales, permitiendo ajustar su coste de mantenimiento al mínimo necesario para que realicen su cometido.
  • El cambio de roles de las BBDD principal/standby (sea mediante switchover o failover) no afecta el envío de los datos de redo a la BBDD de Downstream ni, por tanto, a la captura y aplicación de los cambios en las BBDD remotas. En caso de switchover/failover la réplica continua de manera trasparente sin necesidad de actuación por parte de los administradores.

Con esta configuración obtenemos todas las ventajas de Recuperación ante Desastres que nos aporta Data Guard así como una réplica trasparente, automática y no intrusiva de un subconjunto de datos a BBDD remotas de tipo “comodity” mediante GoldenGate.

Cómo integrar fácilmente BI Publisher con nuestras aplicaciones

BI PublisherHace ya tiempo que Oracle eligió a BI Publisher (BIP) como motor de reporting de la compañía y lo ha ido integrando en sus aplicaciones y/o sustituyendo a otras aplicaciones de reporting (EBS, OBI EE, JDE, …). En ocasiones con integraciones más elaboradas y ad-hoc como en el caso de OBIEE (bidireccional: podemos publicar informes BIP en cuadros de mando de OBI y también podemos utilizar OBI como orígen de datos para BIP) o de manera más “embedded”, como con algunas aplicaciones estándard (la aplicación invoca a BIP, que ejectura el informe y genera un fichero de salida -PDF u otro, según convenga- para su posterior reprocesado/presentación por parte de la aplicación).

Hoy vamos a ver cómo podemos integrar fácilmente informes BIP con nuestras aplicaciones y/o desarrollos a medida, incluso también, por qué no, con aplicaciones estándard que permitan invocar una URL externa. En primer lugar vamos a clarificar el concepto “fácil”. Uno de los factores críticos la hora de integrar herramientas es la seguridad: ¿cómo hacer para que una vez autenticado en la aplicación A, el usuario tenga los mismos privilegios en la aplicación B, o que no tenga que volverse a autenticar al navegar entra A y B?

En realidad sería más apropiado hablar de integración “simplificada”, puesto que explicaremos cómo invocar un informe BIP vía URL sin que éste solicite autenticación, obviando  problemáticas importantes, como que sea necesario aplicar restricciones sobre los datos accedidos en función del usuario, o más aún, que cualquiera que haya obtenido la URL de un informe pueda ejecutarlo. Ahora bien, si necesitamos una solución fácil para publicar informes operativos, sin valor estratégico ni confidenciales, dentro de un entorno LAN que ofrezca una mínima seguridad, esta es una manera válida.

BIP tiene una característica llamada “Acceso para invitados” (Guest Access) que permite ejecutar informes a usuarios no autenticados.

Para poder utilizarla, TODOS los elementos que participan en los informes a publicar, deben estar bajo una misma carpeta del catálogo de BIP, que a su vez, estará bajo las carpetas compartidas del catálogo, que será la que haremos accesible a los invitados (si el desarrollo ya existe, será necesario reasignar el data source tras mover/copiar los informes).

Una vez preparados los informes seguiremos los siguientes pasos:

  1.  Configurar el “Guest Access” desde la página de administración de BIP:

    Admin > Security Center > Security Configuration

    BIP Security Options
    Activaremos el flag “Allow” y seleccionaremos la carpeta del catálogo donde hemos ubicado los informes a publicar.
    Navegaremos a la página de administración de orígenes de datos de BIP.

  2. Administration > Data Sources >  JDBC Connections

    Editaremos cada uno de los datasources que participen en los informes a publicar, y en el apartado de seguridad, activaremos el checkbox “Allow Guest Access”

    BIP Datasource Security Options

  3. Obtendremos la URL de cada uno de los informes a publicar.

    La manera más rápida de obtenerlo es ejecutar el informe y desplegar las opciones a la derecha, donde encontraremos “Compartir Enlace Informe”

    Opciones de enlaces del informe

  4. Reiniciamos BIP

  5. Según cada caso particular, añadiremos la URL previamente obtenida al menú de la aplicación con la que vamos a integrar BIP. En este punto, es interesante tener en cuenta todos los parámetros de invocación que ofrece BIP y que nos permitirán personalizar su comportamiento al ejecutar el informe, en especial, en lo referente al modo de visualización (mostrar los parámetros, la cabecera de BIP, URL, parámetros que puedan haber sido seleccionados en la aplicación con la que se integra …) para construir la URL definitiva.

¡Esperamos que os sea útil!

Oracle Mobile Suite = Mobile + OSB + App. Adapters

Conjunt

El auge de las aplicaciones de movilidad ha llevado a buscar la mejor arquitectura y tecnología para facilitar y acelerar los desarrollos de este tipo de aplicaciones. La facilidad de consumir servicios web (SOAP o REST), desde dispositivos móviles, ha sido clave para establecer este mecanismo para la integración con los sistemas de BackEnd.

Si los servicios se publican en un Enterprise Service Bus, tendremos una arquitectura del estilo:

Arquitectura Oracle Mobile Suite

Arquitectura Oracle Mobile Suite

Dada esta situación, Oracle acaba de poner a la venta Oracle Mobile Suite. Esta suite se compone de los productos Mobile Development Framework, Enterprise Service Bus y Applications Adapters. La justificación para la creación de esta Suite está basada en la experiencia adquirida con los clientes que ya han implantado aplicaciones de movilidad, junto con la arquitectura, siempre recomendada por Oracle, de posicionar el Bus entre los dispositivos móviles y los sistemas de BackEnd.

Componentes de Oracle Mobile Suite

Componentes de Oracle Mobile Suite

Si unimos todas las piezas tenemos una solución completa de movilidad con un acceso fácil, rápido y seguro a la información de los sistemas de BackEnd de las compañías, desde los dispositivos móviles a través de Enterprise Service Bus con los Adaptadores.

Aquellas compañías que estén pensando incorporar aplicaciones de movilidad, tienen en esta Suite todo lo necesario para un desarrollo altamente productivo y desde el minuto cero. Por un lado, con Mobile Development Framework se pueden desarrollar aplicaciones de movilidad cross-device, que permitirán implementar y mantener una sola aplicación y desplegarla en distintos dispositivos (IOS, Android). Y por otro lado, además se beneficiarán de todas las ventajas de integración que aporta Enterprise Service Bus con Applications Adapters, no sólo con dispositivos móviles si no con múltiples aplicaciones heterogéneas.

Para más información:  http://www.oracle.com/us/technologies/mobile/oracle-mobile-suite-ds-2085011.pdf

ADF tips: Integrando Web Services y Business Componets

noviembre 6, 2012 Deja un comentario

A veces nos encontramos con la necesidad de mostrar en la misma fila de una tabla campos procedentes de diferentes fuentes de datos (‘data sources’).  Puede darse el caso,  por ejemplo,  de que necesitemos cruzar mediante una operación ‘JOIN’ dos tablas que se encuentran en distintas Bases de Datos. También es posible que algunos atributos se encuentren en la B.D.  y el resto deban obtenerse mediante un Web Service. Este post  muestra los pasos a seguir para implementar una solución para este segundo escenario.

Vamos a describir de forma concisa el problema:

  1. Disponemos de una tabla en la B.D. donde se registran a modo de log todas las conexiones a nuestro sistema. Se guardan dos atributos, la fecha de conexión y la dirección IP de la máquina que se conectó.
  2. Tenemos que diseñar una pantalla que presente de forma tabular el log de conexiones con las siguientes columnas: fecha, IP y una tercera columna con el nombre del país al que pertenece la dirección IP.

Los dos primeros campos, los tenemos, pero la información correspondiente al tercero, ¿de dónde la obtenemos?  Muy sencillo: existen varios  Servicios Web  que nos proporcionan este dato,  uno de los más conocidos es GeoIP.  Trabajar con él será fácil: nosotros le damos una dirección IP  y el WS nos responde con el nombre del país.

¿Y cómo pegamos lo uno con lo otro, y en que lugar? El punto de encuentro está claro: en la capa del modelo, exactamente en el mismo ViewObject donde se realiza la consulta sobre la tabla de Log; añadimos un nuevo atributo llamado Country  y guardamos los cambios. Una vez hecho esto, editamos la clase que implementa el registro del ViewObject y sobrescribimos  el método getCountry() para que se comunique con el  Web Service, consiga el país y lo devuelva. No lo hará directamente, usaremos un JavaBean para ocultar y envolver las llamadas al servicio.

Hay que hacer notar, que estamos planteando un caso muy sencillo,  basta con utilizar un ViewObject de sólo lectura y no basado en entidad. Si los campos de la B.D. tuvieran que ser modificables, entonces diseñaríamos una vista basada en entidad y todo lo dicho para la columna externa (Country)  seguiría siendo válido. Otro caso de uso un poco mas complicado contemplaría la posibilidad de trabajar con WS que proporcionan operaciones  CRUD (create, read, update, delete). Entonces crearíamos entidades basadas en Web Services (y tendríamos que trabajar a nivel de entidad ocultando el origen de datos a los ViewObjects), pero eso lo dejamos para un futuro post.

Pongámonos manos a la obra:

1. Creamos un proyecto nuevo en nuestra aplicación y a partir del WSDL del servicio construimos un proxyService (de tipo JAX-WS,  con el ‘endpoint‘ de la versión 1.2)

Creación de un Web Service Proxy2. Creamos un JavaBean, para envolver la llamada al servicio. A partir de este Bean tendremos la posibilidad de crear un DataControl que nos permita trabajar de forma declarativa con los datos las estructuras del WS.  El método getGeoIP() se encarga de hacer la llamada a la operación del WS que nos interesa.

3. Diseñamos el  ViewObject  (LogView1) a partir de la tabla Log y le añadimos un atributo nuevo, Country.

4. Sobrescribimos  el método getCountry() en la implementación del registro de LogView1, para que obtenga a través d nuestro JavaBean el país correspondiente a la dirección IP.

5. Diseñamos la página con  la tabla de log, arrastrando y soltando el DataControl correspondiente a la vista LogView1 sobre la página, ejecutamos y vemos el resultado final.

Presentación homogénea de columnas que provienen de diferentes fuentes de datos

De esta forma en cinco sencillos pasos hemos conseguido resolver el problema. Seguramente no es muy eficiente llamar al servicio para cada fila, para mejorar esta situación usaremos nuestro JavaBean. Teniendo en cuenta que este tipo de servicios web ofrece operaciones que permiten pasar como parámetro listas de elementos en vez de elementos individuales y de igual manera devuelven listas de resultados, podremos invocar la operación del WS  una vez y mantener en un HashMap la lista de paises, evitando así una invocación  por cada registro.

Volver a sincronizar esquemas o tablas en Oracle GoldenGate

En ocasiones en nuestras instalaciones de GoldenGate nos podemos encontrar con esquemas o tablas que quedan fuera de sincronía con el resto. Esto puede ser a causa de problemas que nos obligan a “saltar” ciertas transacciones o incluso a eliminar esquemas de la configuración de réplica para que ésta pueda continuar.

En esta entrada explicaremos como recuperar estos usuarios o tablas que han dejado de estar sincronizados sin tener que cargar nuevamente todos los esquemas o tablas de la réplica.

Usaremos dos sistemas, el primero disponible en todas las versiones de GoldenGate y tipos de BBDD y el segundo específico para GoldenGate 11.1.1 o superior y BBDD Oracle.

En ambos casos partiremos de un proceso EXTRACT que captura los datos en una BBDD origen y otro proceso REPLICAT que los entrega en una BBDD Destino.

Leer más…

Categorías:GoldenGate Etiquetas: , ,