Conception pour la résilience à l'aide d'Oracle Integration

Utilisez ces bonnes pratiques lors de la conception de vos intégrations résilientes.

Intégrations de conception

Voici un flux d'intégration entrante de base qui reçoit des demandes d'une application en amont via une API REST, les analyse, les valide et les envoie à une application en aval.

Il peut y avoir un cas où l'application en aval ne répond plus lorsque l'application en amont envoie des demandes. Ces demandes ne seront pas reconnues par l'aval. Il existe de nombreux défis de traitement tels que les lots, les flux/corrélations de messages complexes et la limitation.

Prenons un exemple de création d'entités sur Oracle Financials Cloud à l'aide des API REST. Les demandes doivent être reçues par une adresse REST d'intégration. Vous devez pouvoir limiter dynamiquement les demandes renvoyées par Financials Cloud, suivre leur statut et soumettre à nouveau les demandes ayant échoué. Pour cette solution, trois intégrations et une base de données Autonomous Transaction Processing sont affichées. La mise en œuvre du parking peut être effectuée à l'aide de diverses technologies de stockage telles que la base de données ou Coherence. Cependant, nous utilisons une table de base de données Autonomous Transaction Processing pour plus de simplicité.

Description de l'image oic_extended_parkinglot_eh.png

Dans l'image présentée, lorsque l'application en amont envoie une demande, l'intégration Request Persister l'envoie à la base de données et accuse réception de l'application en amont. Dans la base de données, le modèle de parking stocke les métadonnées de demande et les informations de statut et traite la demande d'entrée en fonction de l'ordre dans lequel elles entrent. Chaque message est mis en attente dans le stockage pendant x minutes (temps de stationnement), de sorte que le flux d'intégration a une chance de réduire le nombre de messages traités simultanément.

Une intégration de répartiteur de planification orchestrée est déclenchée par une planification. Vous pouvez planifier cette exécution d'intégration pour copier les demandes de la base de données à la date et à l'heure de votre choix. Vous pouvez également définir la fréquence de l'intégration. Ces demandes sont transmises à l'intégration du processeur asynchrone. L'intégration asynchrone du processeur traitera les demandes entrantes et les enverra à l'application en aval.

Composants de conception

La conception de haut niveau comprend trois intégrations et une base de données. Nous prenons la création comme exemple, mais en réalité, il peut s'agir de n'importe quel objet fonctionnel exposé par n'importe quelle API REST Oracle SaaS.

Demandes POST

L'intégration Request Persister expose une adresse de déclencheur REST, qui peut être appelée par une application (client) en amont pour envoyer les demandes de création de compte par POST.

Cette intégration persistante charge les demandes de création de compte dans la base de données Autonomous Transaction Processing immédiatement après réception des applications client et accuse réception avec HTTP 202/Accepted. L'ID de compte et la charge utile entière sont conservés dans la table des parkings pour traitement ultérieur.

Charger les demandes dans la table des parkings

La base de données Autonomous Transaction Processing contient la table des parkings dans laquelle toutes les demandes reçues sont mises en attente avant le traitement. Pour plus de simplicité, une table simple est affichée pour conserver la charge utile et suivre le statut de la demande et toutes les informations d'erreur.

La charge utile de demande JSON de création de compte est entièrement stockée dans la table de parking sous forme de chaîne. Dans certains cas d'emploi, il peut s'agir d'un objet CLOB ou d'une chaîne encodée où il n'est pas souhaitable d'avoir une charge utile visible dans la table. Toutefois, le stockage de la charge utile en tant que json permet de modifier la charge utile lors des resoumissions d'erreur.

Si vous le souhaitez, vous pouvez stocker l'intégralité de la demande JSON dans la table. Vous pouvez le faire en deux étapes :

• Phase Write utilisant l'exemple JSON de la charge utile de demande pour la création du fichier de schéma.
• Opération d'étape Read Entire File utilisant un schéma opaque.

  Fournit la valeur codée base64 de la chaîne de charge utile JSON. Ensuite, la fonction intégrée decodebase64(opaqueElement) peut être utilisée dans mapper(ou affecter) pour obtenir la valeur de chaîne JSON. Le fichier de schéma opaque xsd utilisé lors de la lecture de la phase est disponible dans GitHub, qui est décrit plus loin dans cette solution.

Demandes d'expédition selon la planification

L'exécution de l'intégration programmée est planifiée à la fréquence requise. Dans chaque exécution, il extrait un nombre configuré de demandes et de boucles via lesquelles il envoie chaque demande à une intégration de processeur asynchrone pour traitement.

Vous pouvez configurer l'extraction d'un certain nombre de demandes en tant que paramètre planifié pour ralentir ou accélérer le traitement des demandes, ainsi que pour modifier dynamiquement la valeur. Par exemple, vous pouvez configurer une table de manière à ce que les demandes de la table de parking soient extraites en fonction du statut des demandes. Vous pouvez extraire les demandes de statut NEW et ERROR_RETRY et les transmettre pour traitement.

Ce répartiteur planifié effectue ensuite une boucle sur le nombre de demandes extraites et transfère chaque demande au processeur asynchrone pour la création de compte. Assurez-vous que le flux (parent) du planificateur appelle un flux asynchrone (enfant) unidirectionnel. Le processeur asynchrone ne renvoie aucune réponse, de sorte que le thread du planificateur est libéré pour revenir en arrière et faire une boucle dans le reste des demandes et les envoyer. Cela garantit que les threads de planificateur destinés au cas d'utilisation spécial de la planification ne sont pas bloqués dans le traitement à long terme. La logique métier du traitement des demandes elle-même est gérée par les ressources de traitement asynchrone disponibles dans les intégrations Oracle.

Voici quelques bonnes pratiques pour l'orchestration programmée : découplez toujours la logique de planification avec la logique métier à l'aide d'un transfert asynchrone de l'intégration programmée. Cela garantit que les threads du planificateur ne sont pas utilisés pour la création de compte.

• Les orchestrations planifiées sont conçues pour répondre à des exigences particulières de planification des flux, et leur libération à l'aide du transfert asynchrone rend la solution évolutive et performante lors du traitement d'un grand nombre de demandes.
• Les orchestrations planifiées ne doivent pas être utilisées comme substitut aux orchestrations basées sur une application.

Vous pouvez ajouter des actions à l'intégration orchestrée. Si vous utilisez une action for-each, vous pouvez effectuer une boucle sur un élément répétitif et exécuter une ou plusieurs actions dans la portée de l'action for-each. Le nombre d'itérations de boucle repose sur un élément extensible sélectionné par l'utilisateur. Par exemple, vous pouvez avoir une intégration dans laquelle vous avez téléchargé un certain nombre de fichiers et souhaitez effectuer une boucle sur la sortie des fichiers. L'action for-each vous permet d'effectuer cette tâche. Notez que Traiter les éléments en parallèle peut être sélectionné pour certaines boucles for-each. Cela garantit que les activités de la boucle for-each sont regroupées par intégration et exécutées en parallèle. Il existe certaines conditions dans lesquelles l'intégration ignorera le parallélisme. Dans ce cas, le degré de parallélisme sera défini sur 1 pour éviter les problèmes de simultanéité.

Créer un compte

L'intégration asynchrone du processeur traitera les demandes entrantes du répartiteur planifié et les enverra à l'application en aval.

Le processeur asynchrone affiche une interface REST. Il est important que cette intégration soit modélisée en tant que flux asynchrone unidirectionnel pour libérer l'intégration du planificateur. Lorsque vous configurez l'intégration asynchrone d'une manière, assurez-vous que le déclencheur REST expose une méthode POST et que le flux REST ne renvoie pas de réponse au client.

1. Vous pouvez configurer ces deux éléments dans l'assistant Configurer l'adresse Rest.
   1. Sur le canevas d'intégration, dans le panneau Déclencheurs, cliquez sur REST si les adaptateurs REST ne sont pas déjà répertoriés.
   2. Faites glisser votre connexion d'intégration vers l'icône plus en dessous de START sur le canevas. L'assistant de configuration Configurer l'adresse REST apparaît.
2. Sur la page Informations de base de l'assistant, sélectionnez POST dans la liste déroulante pour Quelle action voulez-vous effectuer sur l'adresse ?
3. Sélectionnez l'adresse Configurer la charge utile de demande pour l'adresse.

Comme le flux asynchrone effectue la création réelle du compte, il sera chargé de mettre à jour le statut de la demande dans la table des parkings. Une fois le compte créé, la colonne STATUS de la table des parkings est mise à jour sur PROCESSED.

Gérer les demandes en échec

La resoumission des demandes ayant échoué peut être contrôlée à partir de la table des parkings. Un gestionnaire d'erreurs au niveau de la portée gère toutes les erreurs lors de la création du compte et met à jour le statut sur ERRORED pour toutes les erreurs. Les détails de la raison et de l'erreur sont également mis à jour dans la table des parkings. Cela est utile pour déterminer si la demande peut être soumise à nouveau ultérieurement. Vous pouvez également envoyer des courriels de notification d'erreur aux administrateurs de l'intégration.

Les gestionnaires d'erreurs définissent les demandes en échec sur le statut ERRORED dans la table des parkings. Ces demandes peuvent être mises à jour dans la table avec le statut ERROR_RETRY et seront sélectionnées dans la programmation suivante pour retraitement en raison des critères de sélection de l'appel de base de données Autonomous Transaction Processing du répartiteur programmé.

Il existe différentes options pour déclencher de telles resoumissions :

• La mise à jour des demandes ERRORED vers ERROR_RETRY peut être effectuée par un administrateur sur la base de données.
• Vous pouvez même ajouter un flux d'intégration de resoumission qui s'exécute quotidiennement ou à toute fréquence souhaitée, et mettre à jour tous les enregistrements ERRORED sur ERROR_RETRY.
• Le gestionnaire d'erreurs de l'intégration du processeur asynchrone peut définir l'état sur ERROR_RETRY directement, de sorte que chaque échec soit automatiquement resoumis dans la programmation suivante.

Correction de charge utile

Le stockage de la charge utile de création de compte dans la table des parkings nous a permis de corriger la charge utile des erreurs de données avant la resoumission. Mettez à jour la charge utile et définissez la colonne de statut sur ERROR_RETRY pour soumettre à nouveau une demande avec la charge utile corrigée.