Internet de las Cosas, a nivel industrial

En el año 2015, dentro del marco del evento Sinergias, tuvimos la oportunidad de platicar de qué era y qué tecnologías conforman la Tercera Plataforma. ¿Lo recuerdan? Estas son:

• Cómputo en La Nube
• Big Data y Analíticos
• Mobilidad
• Social Business

Posteriormente en el año 2016 en el marco del mismo evento anual, avanzábamos lo que en aquel entonces era la "novedad" y ahora es el cimiento y la piedra angular de lo que estamos viviendo: La Cuarta Revolución Industrial.

2017 nos recibió con esa hija que tuvieron la Tercera Plataforma y la Cuarta Revolución Industrial. Digna sobrina de la Convergencia Informática y hoy por hoy lo que está marcando la pauta de todo lo que respecta a las Tecnologías de la Información. La Transformación Digital.

La mejor manera de entender la Transformación Digital y sus inmensos alcances, es entender y poner foco en tecnologías y desarrollos relacionados que son las que la pueden hacer realidad.

Existen pues ya identificadas diez y seis tecnologías que apuntalan la Transformación Digital. Doce de ellas ya están impactando nuestras vidas desde hace no mas de un año ni menos de seis meses, mientras que las restantes doce lo harán en un mediano plazo no mayor a ocho años.

Las primeras doce tecnologías con impacto a corto plazo son:

• Cómputo en La Nube (de la Tercera Plataforma)
• Big Data (de la Tercera Plataforma)
• Blockchain (de la Cuarta Revolución Industrial)
• Realidad Virtual (de la Cuarta Revolución Industrial)
• Realidad Aumentada (de la Cuarta Revolución Industrial)
• Internet de las Cosas (de la Cuarta Revolución Industrial)
• Inteligencia Artificial (de la Cuarta Revolución Industrial)
• Vehículos Autónomos (de la Cuarta Revolución Industrial)
• Robots (desde la Tercera Revolución Industrial)
• Fábricas Oscuras  (de la Cuarta Revolución Industrial)
• Impresión 3D (de la Cuarta Revolución Industrial)
• Biología Sintética (de la Cuarta Revolución Industrial)

Las otras cuatro tecnologías con impacto a largo plazo son:

• Auto Ensamble Molecular 
• Cómputo Cuántico
• Cómputo Orgánico
• Interfaces Cibernéticas

En esta entrada, deseamos platicar con un poco de más profundidad acerca de la Internet de las Cosas. ¿Están preparados?

En no pocas entradas anteriores en este Blog Tecnológico, hemos platicado que Internet de las Cosas se define (estricta y teóricamente) como:

-"...un concepto que se refiere a la interconexión digital de objetos cotidianos con internet."- Wikipedia

¿Para qué conectar estos objetos cotidianos utilizando la red de redes? Para que éstos (los objetos) se conviertan es sensores, actuadores y en esos chivatos, chismosos, cotillones que nos pueden hacer la vida más fácil, así como proporcionar valiosísimos datos a las empresas que fabrican electrodomésticos, vehículos, equipos de cómputo, teléfonos inteligentes, etc.

Mas sin embargo Internet de las Cosas no es solamente conectarlo todo y a todos a la Internet, como en una masiva tertulia en la que todos hablamos contra todos, sin llegar a un claro y concreto objetivo.

¿Cómo hacer entonces para de manera ordenada, útil, rentable y trascendente podamos aprovechar a nuestros artilugios cotidianos (y no tanto) conectados a la Web?

Estándares y protocolos para Internet de las Cosas

Comencemos pues con una visión general de los protocolos involucrados en dispositivos y aplicaciones de Internet de las Cosas.

Internet de las Cosas abarca una amplia gama de industrias y se presentan casos que varían desde un solo dispositivo restringido, hasta despliegues masivos multi-plataforma de tecnologías integradas y sistemas en la nube que se conectan en tiempo real.

Interconectar todo esto requiere numerosos protocolos de comunicación ya existentes y emergentes, que permiten que los dispositivos y servidores se comuniquen entre sí de formas nuevas y más interconectadas.

Al mismo tiempo, se están formando docenas de alianzas y coaliciones con la esperanza de unificar el panorama IoT fracturado y orgánico.

A continuación veremos:

• Una lista general de protocolos y estándares populares que ayudan a impulsar dispositivos, aplicaciones y aplicaciones de IoT
• Profundizaremos en capas específicas o protocolos específicos de la industria
• Haremos una lista de las comparaciones cara a cara de los protocolos populares

Protocolos

En lugar de intentar ajustar todos los protocolos IoT sobre los modelos de arquitectura existentes como el modelo OSI, hemos desglosado los protocolos en las siguientes capas para proporcionar un cierto nivel de organización:

• Infraestructura (por ejemplo, 6LowPAN, IPv4/IPv6, RPL)
• Identificación (ej .: EPC, uCode, IPv6, URI)
• Comunicaciones/Transporte (por ejemplo: Wifi, Bluetooth, LPWAN)
• Descubrimiento (por ejemplo: Physical Web, mDNS, DNS-SD)
• Protocolos de datos (por ejemplo: MQTT, CoAP, AMQP, Websocket, Node)
• Administración de dispositivos (por ejemplo: TR-069, OMA-DM)
• Semántica (ej .: JSON-LD, "Web Thing Model")
• Frameworks multicapa (ej: Alljoyn, IoTivity, Weave, Homekit)
• Seguridad (hogar conectado, industria, etc.)

Infraestructura

IPv6: "IPv6, es un protocolo de capa de Internet (evolución de IPv4) para interconexión de conmutación de paquetes, que proporciona transmisión de datagramas de extremo a extremo a través de múltiples redes IP.

6LoWPAN: Acrónimo de "IPv6 Sobre Redes Inalámbricas de Área Personal de Baja Potencia. Es una capa de adaptación para IPv6 sobre enlaces IEEE802.15.4. Este protocolo opera solo en el rango de frecuencias de 2,4 GHz con una tasa de transferencia de 250 kbps.

UDP (User Datagram Protocol - Protocolo de Datagramas de Usuario): Protocolo simple de capa de transporte OSI, para aplicaciones de red cliente/servidor basadas en Protocolo de Internet (IP). UDP es la principal alternativa a TCP y uno de los protocolos de red más antiguos en existencia, introducido en 1980. UDP a menudo se utiliza en aplicaciones especialmente optimizadas para el rendimiento en tiempo real.

QUIC (Quick UDP Internet Connections - Conexiones Rápidas a Internet vía UDP): Admite un conjunto de conexiones multiplexadas entre dos puntos finales a través del Protocolo de Datagramas de Usuario (UDP). diseñado para proporcionar protección de seguridad equivalente a Transport Layer Security (TLS)/Secure Socket Layer (SSL), junto con una latencia reducida de conexión, transporte y estimación de ancho de banda en cada dirección para evitar congestión.

Aeron: UDP confiable y eficiente en modalidad de difusión única, multidifusión UDP y transporte de mensajes Inter-Process Communication (IPC).

uIP: Pila (stack) de código abierto del protocolo TCP/IP, que se puede usar con pequeños microcontroladores de 8 y 16 bits. Originalmente fue desarrollado por Adam Dunkels del grupo "Networked Embedded Systems" en el Instituto Sueco de Ciencias de la Computación, con licencia Berkeley Software Distribution (BSD) y desarrollado por un amplio grupo de desarrolladores.

DTLS (Datagram Transport Layer): Proporciona privacidad de comunicaciones para protocolos de datagramas. El protocolo permite que las aplicaciones cliente/servidor se comuniquen de manera tal, que evite las escuchas, la manipulación o la falsificación de mensajes. El protocolo DTLS se basa en El protocolo Transport Layer Security (TLS) y proporciona garantías de seguridad equivalentes.

ROLL/RPL: Enrutamiento IPv6 para Redes de Baja Potencia y/o Baja Pérdida. Las edes de bajo consumo y bajas pérdidas (LLN por sus siglas en inglés) son una clase de red en la que tanto los enrutadores como su interconexión están restringidos. Los enrutadores LLN generalmente funcionan con restricciones en la potencia de procesamiento, memoria y energía (energía de la batería). Sus interconexiones se caracterizan por altas tasas de pérdida, baja velocidad de datos e inestabilidad.

NanoIP: Nano Internet Protocol, es un concepto que se creó para llevar servicios de red similares a Internet a dispositivos integrados y sensores, sin la sobrecarga de TCP/IP. NanoIP se diseñó para condiciones con gastos generales mínimos, redes inalámbricas y el direccionamiento local.

Red centrada en contenido (CCN): Arquitectura de red de próxima generación, pensada para resolver los desafíos en la escalabilidad, movilidad y seguridad para la distribución de contenido.

CCN enruta directamente y entrega piezas de contenido con nombre en el nivel de paquete de la red, lo que permite el almacenamiento en caché automático y neutral de la aplicación en cualquier lugar de la red. ¿El resultado? Entrega eficiente y efectiva de contenido donde sea y cuando sea necesario. Dado que la arquitectura permite estos efectos de almacenamiento en caché como un efecto secundario automático de la entrega de paquetes, la memoria se puede utilizar sin costosos servicios de caché a nivel de aplicación.

Time Synchronized Mesh Protocol (TSMP): Protocolo de comunicaciones para redes auto-organizadas de dispositivos inalámbricos llamados "motes". Los dispositivos TSMP se mantienen sincronizados entre sí y se comunican en intervalos de tiempo, de forma similar a otros sistemas de Multiplexación por División de Tiempo (TDM por sus siglas en inglés).

Descubrimiento

mDNS (sistema de multidifusión de nombres de domini): Resuelve los nombres de host a direcciones IP dentro de redes pequeñas que no incluyen un servidor de nombres local.

Web Física: la Web física le permite ver una lista de las Universal Resource Locators (URLs) que emiten los objetos en el entorno que lo rodea, con una baliza Bluetooth de Baja Energía (BLE).

HyperCat: un formato de catálogo hipermedia abierto y ligero basado en Java Script Open Notation (JSON) para exponer colecciones de Universal Resource Locators (URIs).

UPnP (Plug and Play universal): Ahora administrado por Open Connectivity Foundation, es un conjunto de protocolos de red que permite a los dispositivos conectados, descubrir la presencia de los demás nodos en la red, estableciendo servicios de red funcionales para compartir datos, comunicaciones y entretenimiento.

Protocolos de datos

MQTT (Message Queue Server Telemetry Transport): Habilita un modelo de mensajería de publicación/suscripción de una manera extremadamente ligera. Es útil para las conexiones con ubicaciones remotas donde se requiere una pequeña huella de código y/o ancho de banda de la red.

MQTT-SN (MQTT para redes de sensores): un protocolo de publicación/suscripción abierto y ligero, diseñado específicamente para aplicaciones Máquina-a-Máquina y móviles:

• Mosquitto: Un Broker v3.1 Open Source MQTT
• IBM MessageSight

CoAP (Protocolo de aplicación restringido): Es un protocolo de capa de aplicación, diseñado para dispositivos de Internet con recursos limitados como los nodos WSN. CoAP está diseñado para traducirse fácilmente a HTTP para una integración simplificada con la web, al mismo tiempo que cumple con los requisitos especializados como el soporte de multidifusión, gastos generales muy bajos y simplicidad.

El Grupo de Entornos RESTful Restringidos (CoRE por sus siglas en inglés) ha propuesto las siguientes características para CoAP:

• Diseño de protocolo RESTful que minimiza la complejidad del mapeo con HTTP.
• Sobrecarga de encabezado baja y la complejidad de análisis.
• URI y soporte de tipo de contenido.
• Soporte para el descubrimiento de recursos proporcionados por Servicios de CoAP. 
• Suscripción simple para un recurso, y notificaciones push resultantes.
• Almacenamiento en caché simple basado en max-age.

SMCP: Una pila de CoAP basada en C, que es adecuada para entornos integrados. Las características incluyen: Soporte draft-ietf-core-coap-13, Entrada/Salida totalmente asíncronas y soporta sockets BSD y UIP.

STOMP: El Protocolo de Mensajería Orientada a Texto Simple, anteriormente conocido como TTMP, es un protocolo  basado en texto diseñado para trabajar con Middleware Orientado a Mensajería (MOM por sus siglas in inglés). Proporciona un formato interoperable que permite a los clientes STOMP hablar con cualquier agente de mensajes que admita el protocolo.

XMPP (Extensible Messaging and Presence Protocol): una tecnología abierta para la comunicación en tiempo real, que impulsa una amplia gama de aplicaciones que incluyen mensajería instantánea, presencia, chat multipartita, llamadas de voz y video, colaboración, middleware ligero, sindicación de contenido y enrutamiento generalizado de datos basados en eXtensible Markup Language o XML.

XMPP-IoT: De la misma manera que XMPP, silenciosamente ha creado una comunicación interoperable de persona a persona. Su objetivo es hacer que las máquinas de comunicación Persona a Persona y Máquina a Máquina sean interoperables.

Mihini/M3DA: El agente de Mihini es un componente de software que actúa como mediador entre un servidor de Máquina a Máquina y las aplicaciones que se ejecutan en una puerta de enlace incrustada. M3DA es un protocolo optimizado para el transporte de datos binarios de máquina a máquina.

Está disponible en el proyecto Mihini tanto para la gestión de dispositivos, facilitando la manipulación y sincronización del modelo de datos de un dispositivo, como para la gestión de activos, permitiendo a las aplicaciones de usuario intercambiar datos / comandos escritos de un lado a otro, con una máquina. Al servidor de la máquina de una manera que optimice el uso del ancho de banda.

AMQP (Protocolo Avanzado de Colas de Mensajería): Protocolo de capa de aplicación estándar, abierto, para middleware orientado a mensajería de datos. Las características definitorias de AMQP son la orientación de los mensajes, la puesta en cola, el enrutamiento (incluyendo punto a punto y publicación y suscripción), así como confiabilidad y seguridad."

DDS (Servicio de Distribución de Datos para Sistemas en Tiempo Real): El primer estándar internacional abierto de middleware, que aborda directamente las comunicaciones bajo el esquema publicación/suscripción para sistemas en tiempo real e integrados".

JMS (Java Message Service): API de Middleware Orientado a Mensajería (MOM) basado en Java,  para enviar mensajes entre dos o más clientes.

LLAP (Protocolo Ligero para Automatización Local): Protocolo que utiliza mensajes corto y simples, que se envía entre objetos inteligentes usando texto normal. No es como TCP/IP, Bluetooth, Zigbee, 6lowpan, WiFi, etc. que alcanza un bajo nivel de "cómo" para mover los datos. Esto significa que LLAP puede correr sobre cualquier medio de comunicación. Las tres fortalezas de LLAP son:

• Se ejecuta en cualquier "cosa" actualmente, 
• Se ejecutará en cualquier "cosa"cualquier cosa en el futuro
• Es fácilmente comprensible para los humanos

LWM2M (Lightweight M2M): Sistema estándar en la Open Mobile Alliance. Incluye DTLS, CoAP, Block, Observe, SenML y Resource Directory, integrándolos en una interfaz de dispositivo-servidor junto con una estructura orientada a Objetos.

SSI (Interfaz de Sensor Simple): Protocolo de comunicaciones simple diseñado para la transferencia de datos entre computadoras o terminales de usuario y sensores inteligentes.

Flujos Reactivos: Estándar para el procesamiento de flujos asíncronos con contrapresión, sin bloqueo en la Máquina Virtual Java (JVM).

Object Name Service (ONS): Mecanismo que aprovecha el Sistema de Nombres de Dominio (DNS) para descubrir información sobre un producto y servicios, basándose en el Código de Producto Electrónico (EPC). Es un componente de la red EPCglobal.

REpresentational State Transfer (REST): Arquitectura que define un conjunto de restricciones que se utilizarán para crear servicios web. Los servicios web que se ajustan a REST, o los servicios web RESTful, proporcionan interoperabilidad entre los sistemas informáticos en Internet.

HTTP/2: El Protocolo de Transferencia de Hipertexto, versión 2, es un protocolo de red utilizado por la World Wide Web que llega con el objetivo de actualizar el protocolo HTTP/1.1, con el que es compatible. HTTP 2.0 no modifica la semántica de aplicación de Http, permitiendo un uso más eficiente de los recursos de red y una menor percepción de la latencia al introducir la compresión del campo del encabezado, permitiendo múltiples intercambios simultáneos en la misma conexión.

SOAP (Protocolo Simple de Acceso a Objetos): Protocolo estándar que define cómo dos objetos en diferentes procesos, pueden comunicarse por medio de intercambio de datos usando XML. Está actualmente bajo el auspicio de la W3C y es uno de los protocolos más utilizados en los servicios Web.

Websocket: Especificación WebSocket desarrollada como parte de la iniciativa HTML5, introduciendo la interfaz JavaScript de WebSocket, que define una conexión de socket único dúplex completo a través de la cual se pueden enviar mensajes entre el cliente y el servidor. Simplifica gran parte de la complejidad en torno a la comunicación web bidireccional y la gestión de la conexión.

En posteriores entregas, hablaremos más acerca de todos los estándares actuales relativos a la Capa de Transporte, Comunicación, Semántica, Frameworks multi capa, Seguridad y estándares específicos.

Por el momento sólo podemos decir que, más allá de pensar que Internet de las Cosas es algo que llegó de manera súbita, improvisada o para intentar cubrir una necesidad general o específica simple, es toda una Tecnología que ya cuenta con todo lo necesario para ser implementada de manera seria, cabal, completa, segura y escalable.

¿Ya tiene Usted pensada su estrategia e Internet de las Cosas?

Plataforma de Integración de Datos en La Nube para aplicaciones SaaS

Hoy todos y cada uno que ya contamos al menos con un dispositivo inteligente, generamos enormes cantidades de datos en aplicaciones Software como un Servicio (SaaS por sus siglas en inglés) que son fundamentales para las decisiones comerciales, como reducir el gasto en compras o maximizar la utilización de la fuerza de trabajo.

Con la mayoría de los clientes que usan múltiples aplicaciones SaaS, muchas de estas decisiones se toman en motores analíticos fuera de la solución SaaS, o necesitan datos externos para ser llevados a SaaS para tomar decisiones dentro de ellos. En esta entrada examinaremos las necesidades comunes de movimiento y replicación de datos en el ecosistema SaaS, y cómo la Plataforma de Integración de Datos (DIPC por sus siglas en inglés) de Oracle permite el acceso a datos de SaaS y ayuda con la toma de decisiones.

Desafíos de integración de datos para SaaS

A medida que las aplicaciones se trasladaron de las instalaciones a SaaS, a la vez que proporcionaron una serie de beneficios, se modificó una serie de supuestos y arquitecturas preexistentes. Examinemos aquí algunos cambios en el panorama empresarial, que de ningún modo son exhaustivos.

En primer lugar, las aplicaciones locales proporcionan en la mayoría de los casos acceso a aplicaciones a nivel de base de datos, generalmente de solo lectura. Esto no ha cambiado con casi todos los proveedor de SaaS que proporcionan acceso a la base de datos. Los clientes ahora trabajan con REpresentational State Transfer (REST) APIs (o versiones anteriores de Simple Object Access Protocol APIs) para extraer y cargar datos masivos. Si bien las Application Programming Interfaces (APIs) tienen muchas ventajas, incluida la eliminación de la dependencia en el esquema de la aplicación, no concuerdan con las consultas Structured Query Language (SQL) y tienen limitaciones de aceleración de datos preestablecidas definidas por el proveedor de la solución SaaS.

En segundo lugar, la mayoría de los clientes tienen múltiples aplicaciones SaaS, lo que hace imperativo fusionar datos de diferentes soluciones para cualquier análisis significativo; Ventas con producto, leads con contactos; Pedidos con inventario y la lista continúa. Si bien cada una de las aplicaciones de SaaS proporciona alguna capacidad analítica, la mayoría de los clientes preferiría las mejores herramientas modernas y arquitecturas abiertas para sus datos para el procesamiento analítico. Esto podría ser desde las bases de datos relacionales tradicionales con Business Intelligence hasta los modernos Data Lakes con motores Spark.

En tercer lugar, la mayoría de los clientes empresariales tiene una aplicación o una plataforma analítica que entrega informes "in situ", lo que requiere el movimiento de datos entre la nube y las instalaciones; es decir, una implementación de nube híbrida.

En cuarto lugar, las fuentes de datos semiestructuradas y no estructuradas, se utilizan cada vez más en la toma de decisiones. Correos electrónicos, entradas de Twitter, publicaciones de Facebook e Instagram, archivos de registro y datos de dispositivos proporcionan un contexto para los datos transaccionales en los sistemas relacionales.

Finalmente, las líneas de tiempo para la toma de decisiones se reducen con la necesidad de un análisis de datos en tiempo real, la mayoría de las veces. Si bien la mayoría de las aplicaciones SaaS brindan arquitecturas por lotes y REST API, tienen dificultades para proporcionar una capacidad de transmisión robusta para el análisis en tiempo real. Los clientes necesitan aplicaciones SaaS para ser parte de las arquitecturas de estilo Kappa y Lambda.

Echemos un vistazo a cómo Oracle Data Integration Platform Cloud aborda estos problemas.

Mitigación de los desafíos de integración de datos de SaaS con DIPC

Data Integration Platform Cloud (DIPC) es una plataforma basada en La Nube para la transformación, integración, replicación y administración de los datos. DIPC proporciona integración de datos en tiempo real y por lotes entre entornos en la nube dentro de las instalaciones, reuniendo los mejores productos de integración de datos Oracle GoldenGate, Oracle Data Integrator y Oracle Enterprise Data Quality dentro de una única plataforma en La Nube. Puede encontrar más información sobre DIPC haciendo "click" aquí.

Para las aplicaciones Oracle Fusion, como ERP Cloud, HCM Cloud y Sales Cloud, DIPC admite varios métodos de carga y extracción con conectores listos para usar. Estos incluyen BI Publisher, BI Cloud Connector y otras interfaces estándar SOAP/REST.

La elección de la interfaz depende del caso de uso específico. Por ejemplo, para extraer grandes conjuntos de datos para un área temática determinada (por ejemplo, Finanzas-> Cuentas), BI Cloud Connector (BICC) es ideal con su configuración de extracción incremental en Oracle Fusion. BICC proporciona acceso a datos de Fusion Cloud a través de Objetos de Vista Pública (PVO por sus siglas en inglés).

Estas PVO se agregan en áreas temáticas (Finanzas, HCM, CRM, etc.) y BICC se puede configurar para extraer de forma manual o mediante programación, extractos completos o incrementales. DIPC se integra con BI Cloud Connector para iniciar un extracto, descargar los archivos de datos PVO en fragmentos, descomprimirlos y desencriptarlos, extraer datos de formatos Archivos Separados por Comas (CSV por sus siglas en inglés), leer formatos de metadatos de archivos Meta Data Comma Separated Values (MDCSV) y finalmente cargarlos en cualquier destino, como Database Cloud Service o Servicio de nube de almacenamiento de datos autónomo. Para conjuntos de datos más pequeños, DIPC puede llamar a reportes existentes de BI o personalizados, cargando datos a cualquier objetivo.

Para otras aplicaciones SaaS, DIPC tiene controladores para Salesforce, Oracle Service Cloud, Oracle Sales Cloud y Oracle Marketing Cloud. Estos controladores proporcionan una interfaz Java Database Connector (JDBC) para la manipulación de datos, mientras se accede a aplicaciones SaaS a través de REST/SOAP API. Además, otras aplicaciones de SaaS que proporcionan controladores de estilo JDBC, como NetSuite, pueden convertirse en fuente y destino para el procesamiento apegado a Extract-Load-Transform (ELT) en DIPC. DIPC tiene soporte genérico REST y SOAP que permite el acceso a cualquier REST API de SaaS. Aquí puede encontrar una lista de fuentes y objetivos admitidos por DIPC.

DIPC simplifica las tareas de integración de datos utilizando las Tareas Elevadas, y los usuarios pueden esperar más asistentes y "recetas" para la carga de datos comunes de SaaS y extraer tareas en el futuro.

El Catálogo DIPC está lleno de metadatos y datos de muestra recopilados de aplicaciones SaaS. En el Catálogo DIPC, los usuarios pueden crear Conexiones a aplicaciones SaaS, para luego iniciarse un proceso de recolección completándose el Catálogo con las Entidades de Datos SaaS.

A partir de este Catálogo, los usuarios podrán crear Tareas con Entidades de Datos como Orígenes y Destinos, conectando en conjunto un flujo de datos de canalización que incluya UNIONES, FILTROS y acciones de transformación estándar.

También se pueden construir tareas elevadas para alimentar los datos de SaaS a Data Lake o Data Warehouse, como Oracle Autonomous Data Warehouse Cloud (ADWCS). Además, hay un integrador de datos de Oracle completo integrado en el interior para los clientes de Oracle Data Integrator (ODI) existentes para construir escenarios de Extracción, Carga y Transformación para la integración de datos de SaaS.

Los clientes también pueden llevar sus escenarios de ODI existentes a DIPC utilizando ODITask. ODITask es un escenario de ODI exportado de ODI e importado a DIPC para su ejecución. ODITask se puede conectar a fuentes y destinos de SaaS.

La figura anterior muestra el catálogo DIPC poblado con objetos ERP Cloud View.

La figura anterior muestra los detalles del objeto de vista de orden de trabajo en el catálogo DIPC.

Para las arquitecturas de nube híbrida, DIPC proporciona un agente remoto que incluye conectores a una gran cantidad de orígenes y destinos. Los clientes que desean mover/replicar datos de fuentes locales, pueden implementar el agente y enviar datos a DIPC en la nube para su posterior procesamiento, o viceversa, para transferir datos a las aplicaciones locales. El agente remoto también se puede implementar en una nube que no sea de Oracle para la integración con las bases de datos que se ejecutan en nubes de terceros.

Para los casos de uso en tiempo real en aplicaciones SaaS, DIPC incluye Oracle Golden Gate, el estándar de oro en la replicación de datos. Cuando sea posible, las aplicaciones SaaS pueden implementar Golden Gate para transmitir datos a bases de datos externas, Data Lakes y Kafka Clusters.

Golden Gate puede implementarse para leer directamente de la instancia de base de datos de SaaS en producción, para extraer los archivos de registro para rehacer de la base de datos, o puede ejecutarse en una copia de respaldo de la base de datos SaaS y usar el mecanismo de transmisión de registro "redo" en cascada. Este mecanismo conduce a una latencia mínima y ofrece la captura de datos modificados de tablas de transacciones SaaS específicas, a una base de datos externa o depósito de datos que proporciona datos de transacciones en tiempo real para decisiones comerciales.

Al utilizar estas funciones integrales en DIPC, vemos cómo los clientes sincronizan lotes de fin de día/fin de mes de la información de la cuenta de Salesforce en E-Business Suite. Los clientes de Fusion Applications pueden extraer de múltiples áreas temáticas de Oracle Transactional Business Intelligence (OTBI) y fusionar/combinar objetos de Ventas, Finanzas y Servicio para crear datamarts personalizados. Para el segmento de venta al menudeo o Retail, Oracle tiene clientes que usan la captura de datos modificados de Golden Gate para sincronizar los datos de la tienda con las aplicaciones Retail SaaS que residen en el corporativo, en tiempo real.

En resumen, DIPC proporciona un conjunto completo de características para que los clientes de SaaS integren datos en Almacenes de Datos, Data Lakes, bases de datos y con otras aplicaciones SaaS en tiempo real y por lotes. Puede obtener más información sobre DIPC haciendo "click" aquí.