Diseño para la resiliencia mediante Oracle Integration

Utilice estas mejores prácticas a la hora de diseñar integraciones resilientes.

Integraciones de diseño

Este es un flujo de integración de entrada básico que recibe solicitudes de una aplicación ascendente a través de una API de REST, analiza, valida y envía a la aplicación descendente.

Puede haber un caso en el que la aplicación descendente no responda cuando la aplicación ascendente envíe solicitudes. Estas solicitudes no serán reconocidas por la dirección descendente. Habrá muchos desafíos de procesamiento como lotes, correlaciones/flujos de mensajes complejos y limitación.

Veamos un ejemplo de creación de entidades en la nube de Oracle Financials mediante las API de REST. Las solicitudes las debe recibir un punto final de REST de integración. Debería poder limitar dinámicamente las solicitudes que llegan a Financials Cloud, realizar un seguimiento del estado de las solicitudes y volver a enviar las solicitudes con fallos. Para esta solución, se muestran tres integraciones y una base de datos de Autonomous Transaction Processing. La implantación del aparcamiento se puede realizar utilizando diversas tecnologías de almacenamiento como la base de datos o Coherence. Sin embargo, estamos utilizando una tabla de base de datos de Autonomous Transaction Processing para que sea más sencilla.

Descripción de la ilustración oic_extended_parkinglot_eh.png

En la imagen mostrada, cuando la aplicación ascendente envía la solicitud, la integración de Persister de solicitud la envía a la base de datos y confirma la aplicación ascendente. En la base de datos, el patrón de estacionamiento almacena metadatos de solicitud e información de estado y procesará la solicitud de entrada en función del orden en que entren. Cada mensaje está detenido en el almacenamiento durante x minutos (tiempo de detención), por lo que el flujo de integración tiene la oportunidad de limitar el número de mensajes procesados simultáneamente.

Una integración de Schedule Dispatcher orquestada se dispara mediante un programa. Puede programar esta ejecución de integración para copiar solicitudes de la base de datos en la fecha y hora que desee. También puede definir la frecuencia de la integración. Estas solicitudes se entregan a la integración de procesadores asíncronos. La integración asíncrona del procesador procesará las solicitudes entrantes y las enviará a la aplicación descendente.

Componentes de diseño

El diseño de alto nivel tiene tres integraciones y una base de datos. Tomamos como ejemplo la creación, pero en realidad podrían tratarse de cualquier objeto de negocio expuesto por cualquier API de REST de Oracle SaaS.

Solicitudes posteriores

La integración de Persister de solicitudes expone un punto final de disparador REST, al que puede llamar una aplicación (cliente) ascendente para POST las solicitudes de creación de cuentas.

Esta integración de persistencia carga las solicitudes de creación de cuentas en la base de datos de Autonomous Transaction Processing inmediatamente después de la recepción de las aplicaciones cliente y acusa recibo con HTTP 202/Accepted. El ID de cuenta y toda la carga útil se mantienen en la tabla de estacionamiento para su procesamiento posterior.

Cargar solicitudes en tabla de estacionamiento

La base de datos de Autonomous Transaction Processing contiene aquí la tabla de estacionamiento en la que todas las solicitudes recibidas están detenidas antes del procesamiento. Por simplicidad, se muestra una tabla simple para mantener la carga útil y realizar un seguimiento del estado de la solicitud y de cualquier información de error.

La carga útil de solicitud JSON de creación de cuenta se almacena por completo en la tabla de estacionamiento como una cadena. Puede haber casos de uso para almacenar como CLOB o una cadena codificada donde no es deseable tener una carga útil visible en la tabla. Sin embargo, el almacenamiento de la carga útil como json ofrece la oportunidad de cambiarla durante las reenvíos de errores.

Si lo desea, puede almacenar toda la solicitud de JSON en la tabla. Puede hacerlo en dos etapas:

• Etapa Write que utiliza el ejemplo de JSON de la carga útil de solicitud para crear el archivo de esquema.
• Operación de etapa Read Entire File que utiliza un esquema opaco.

  Proporciona el valor codificado base64 de la cadena de carga útil JSON. A continuación, se puede utilizar la función incorporada decodebase64(opaqueElement) en el asignador (o la asignación) para obtener el valor de cadena JSON. El archivo xsd de esquema opaco que se utiliza durante la lectura de etapa está disponible en GitHub, que se trata más adelante en esta solución.

Solicitudes de despacho según programa

La integración programada está programada para ejecutarse con la frecuencia necesaria. En cada ejecución recupera un número configurado de solicitudes y bucles a través de ellos despachando cada solicitud a una integración del procesador asíncrono para su procesamiento.

Puede configurar la recuperación de una serie de solicitudes como parámetro programado para limitar o acelerar el procesamiento de solicitudes, así como para cambiar el valor de forma dinámica. Por ejemplo, puede configurar una tabla de forma que las solicitudes de la tabla de estacionamiento se recuperen en función del estado de las solicitudes. Puede recuperar las solicitudes de estado NEW y ERROR_RETRY y transferirlas para su procesamiento.

A continuación, este distribuidor programado realiza un bucle en el número de solicitudes recuperadas y transfiere cada solicitud al procesador asíncrono para la creación de cuentas. Asegúrese de que el flujo del programador (principal) llama a un flujo de integración asíncrona (secundario) unidireccional. El procesador asíncrono no devuelve ninguna respuesta, por lo que el thread del programador se libera para volver atrás y realizar un bucle en el resto de las solicitudes y enviarlas. Esto garantiza que los threads del programador destinados al caso de uso especial de programación no se mantengan en el procesamiento a largo plazo. La lógica de negocio del procesamiento de solicitudes en sí misma la manejan los recursos de procesamiento asíncronos disponibles en Oracle Integrations.

Estas son algunas de las mejores prácticas para la orquestación programada: desacople siempre la lógica de programación con la lógica de negocio mediante una transferencia asíncrona de la integración programada. Esto garantizará que los threads del programador no se utilicen para la creación de cuentas.

• Las orquestaciones programadas están diseñadas para satisfacer requisitos particulares de los flujos de programación, y liberarlos mediante el cambio asíncrono hace que la solución sea escalable y eficaz al procesar un gran número de solicitudes.
• Las orquestaciones programadas no deben utilizarse como sustituto de las orquestaciones basadas en aplicaciones.

Puede agregar acciones a la integración orquestada. Si utiliza for-each acción, puede realizar un bucle en un elemento repetitivo y ejecutar una o más acciones dentro del ámbito de la acción for-each. El número de iteraciones de bucle se basa en un elemento de repetición seleccionado por el usuario. Por ejemplo, puede tener una integración en la que haya descargado varios archivos y desee realizar un bucle en la salida de los archivos. La acción for-each le permite realizar esta tarea. Tenga en cuenta que Elementos de Proceso en Paralelo se puede seleccionar para algunos de los bucles for-each. Esto garantizará que las actividades del bucle for-each se agrupen por lotes mediante integración y se ejecuten en paralelo. Hay ciertas condiciones en las que la integración ignorará el paralelismo. En tales casos, el grado de paralelismo se establecerá en 1 para evitar problemas de simultaneidad.

Crear cuenta

La integración asíncrona del procesador procesará las solicitudes entrantes del distribuidor programado y las enviará a la aplicación descendente.

El procesador asíncrono expone una interfaz REST. Es importante que esta integración se modele como un flujo asíncrono unidireccional para liberar la integración del programador. Al configurar la integración asíncrona de una forma, asegúrese de que el disparador REST exponga un método POST y que el flujo REST no devuelva una respuesta al cliente.

1. Puede configurar estos dos en el asistente Configurar punto final de descanso.
   1. En el lienzo de integración, en el panel Disparadores, haga clic en REST si los adaptadores REST aún no se muestran.
   2. Arrastre la conexión de integración al icono más debajo de Iniciar en el lienzo. Se muestra el asistente de configuración Configurar punto final de REST.
2. En la página Información básica del asistente, seleccione POST en la lista desplegable para ¿Qué acción desea realizar en el punto final?
3. Seleccione Configurar una carga útil de solicitud para este punto final.

Dado que el flujo asíncrono crea la cuenta real, será responsable de actualizar el estado de la solicitud en la tabla de estacionamiento. Después de crear correctamente la cuenta, la columna STATUS de la tabla de estacionamiento se actualiza a PROCESSED (Procesado).

Manejar solicitudes fallidas

La reenvío de solicitudes fallidas se puede controlar desde la tabla de estacionamiento. Un manejador de errores de nivel de ámbito maneja los fallos durante la creación de la cuenta y actualiza el estado a ERRORED para detectar errores. Los detalles de motivo y error también se actualizan en la tabla de estacionamiento. Esto resulta útil para determinar si la solicitud se puede volver a enviar más adelante. También puede enviar correos electrónicos de notificación de error a los administradores de integración.

Los manejadores de fallos configuran las solicitudes con el estado ERRORED (ERRORADO) en la tabla de estacionamiento. Estas solicitudes se pueden actualizar en la tabla al estado ERROR_RETRY y se seleccionarán en el siguiente programa para volver a procesarlas debido a los criterios de selección de la llamada a la base de datos de Autonomous Transaction Processing del distribuidor programado.

Existen varias opciones para disparar dichas reenvíos:

• La actualización de solicitudes ERRORED a ERROR_RETRY puede ser realizada por un administrador en la base de datos.
• Incluso puede agregar un flujo de integración de reenvío que se ejecute diariamente o con cualquier frecuencia deseada, y actualizar todos los registros ERRORED a ERROR_RETRY.
• El manejador de fallos de la integración del procesador asíncrono puede establecer el estado en ERROR_RETRY directamente, por lo que cada fallo se vuelve a enviar automáticamente en el siguiente programa.

Corrección de carga útil

El almacenamiento de la carga útil de creación de cuentas en la tabla de estacionamiento nos ha dado una forma de corregir la carga útil de los errores de datos antes del reenvío. Actualice la carga útil y defina la columna de estado en ERROR_RETRY para volver a enviar una solicitud con carga útil corregida.