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

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

Concevoir des intégrations

Voici un flux d'intégration entrant de base qui reçoit les demandes d'une application en amont au moyen d'une API REST, les analyse, les valide et les envoie à l'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 acceptées par l'aval. Il y aura de nombreux défis de traitement tels que le traitement par lots, la corrélation/flux 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 un point d'extrémité REST d'intégration. Vous devriez être en mesure de limiter dynamiquement les demandes ayant une incidence sur Financials Cloud, de suivre le statut des demandes et de resoumettre les demandes en échec. 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 se faire à 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 simplifier.

Description de l'illustration oic_extended_parkinglot_eh.png

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

Une intégration orchestrée du répartiteur de calendriers est déclenchée par une programmation. Vous pouvez programmer cette exécution d'intégration pour copier des 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 en compte la création comme exemple, mais en réalité, il peut s'agir de tout objet d'affaires exposé par une API REST Oracle SaaS.

Publier les demandes

L'intégration Request Persister expose un point d'extrémité de déclenchement REST, qui peut être appelé par une application amont (client) pour POST les demandes de création de compte.

Cette intégration persistante charge les demandes de création de compte dans la base de données Autonomous Transaction Processing immédiatement à la réception des applications client et accuse réception avec HTTP 202/Accepté. Le code de compte et l'ensemble des données utiles sont conservés dans la table des lots de stationnement aux fins de traitement ultérieur.

Charger les demandes dans la table de stationnement

La base de données Autonomous Transaction Processing contient ici la table des parkings où toutes les demandes reçues sont stationnées avant le traitement. Pour simplifier, un tableau simple permet de conserver les données utiles et de suivre l'état de la demande, ainsi que toute information d'erreur.

Les données utiles de la demande JSON de création de compte sont entièrement stockées dans la table de stationnement sous forme de chaîne. Il peut y avoir des cas d'utilisation à stocker en tant qu'objet CLOB ou chaîne encodée où il n'est pas souhaitable d'avoir des données utiles visibles dans la table. Toutefois, le stockage des données utiles en tant que json permet de modifier les données utiles lors des resoumissions d'erreur.

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

• Étape Write à l'aide de l'exemple JSON des données utiles de la demande pour créer un fichier de schéma.
• Une opération Read Entire File intermédiaire utilisant un schéma opaque.

  Fournit la valeur encodée base64 de la chaîne de données utiles JSON. Ensuite, la fonction intégrée decodebase64(opaqueElement) peut être utilisée dans le programme de mappage (ou affecter) pour obtenir la valeur de chaîne JSON. Le fichier xsd de schéma opaque utilisé lors de la lecture de l'étape est disponible dans GitHub, qui sera traité plus loin dans cette solution.

Demandes de répartition selon le calendrier

L'intégration programmée est programmée pour s'exécuter à la fréquence requise. À chaque exécution, il extrait un nombre configuré de demandes et de boucles à travers elles en transmettant 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 programmé pour ajuster 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 provenant de la table de stationnement 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 programmé effectue ensuite une boucle sur le nombre de demandes extraites et transmet chaque demande au processeur asynchrone pour la création de compte. Assurez-vous que le flux du planificateur (parent) appelle un flux d'intégration asynchrone (enfant) unidirectionnel. Le processeur asynchrone ne retourne aucune réponse, de sorte que le thread du planificateur est libéré pour revenir en arrière et parcourir le reste des demandes et les envoyer. Cela permet de s'assurer que les threads du programmateur qui sont destinés au cas d'utilisation spéciale de la planification ne sont pas bloqués dans le traitement à long terme. La logique métier du traitement des demandes lui-même est gérée par des ressources de traitement asynchrones disponibles dans Oracle Integrations.

Voici quelques meilleures pratiques pour l'orchestration programmée : Dissociez toujours la logique de programmation à la logique métier à l'aide d'un transfert asynchrone de l'intégration programmée. Cela garantit que les unités d'exécution du programmateur ne sont pas utilisées pour la création de compte.

• Les orchestrations programmées sont conçues pour répondre aux exigences particulières des flux de programmation, 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 programmées ne doivent pas être utilisées pour remplacer les orchestrations basées sur une application.

Vous pouvez ajouter des actions à l'intégration orchestrée. Si vous utilisez for-each action, 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 est basé sur un élément répétitif 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 l'option Traiter les articles en parallèle peut être sélectionnée 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 ignore le parallélisme. Dans de tels cas, le degré de parallélisme sera réglé à 1 pour éviter les problèmes de concurrence.

Créer un compte

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

Le processeur asynchrone présente une interface REST. Il est important que cette intégration soit modélisée comme un flux asynchrone unidirectionnel pour libérer l'intégration du programmateur. 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 retourne pas de réponse au client.

1. Vous pouvez configurer ces deux éléments dans l'Assistant Configurer un point d'extrémité pour le repos.
   1. Dans votre canevas d'intégration, dans le volet 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 sous START sur le canevas. L'assistant de configuration Configurer un point d'extrémité REST s'affiche.
2. Dans la page Informations de base de l'assistant, sélectionnez POST dans la liste déroulante pour Quelle action voulez-vous effectuer sur le point d'extrémité?
3. Sélectionnez Configurer des données utiles de demande pour ce point d'extrémité.

Étant donné que le flux asynchrone effectue la création réelle du compte, il sera responsable de mettre à jour le statut de la demande dans la table des parkings. Après la création du compte, la colonne STATUS dans la table des lots de stationnement est mise à jour à PROCESSED.

Traiter les demandes en échec

La resoumission des demandes en échec peut être contrôlée à partir de la table des parkings. Un programme de traitement des erreurs de niveau portée traite toutes les erreurs lors de la création du compte et met à jour le statut à ERREUR pour les erreurs éventuelles. Les détails sur le motif et l'erreur sont également mis à jour dans la table des parkings. Ceci est utile pour déterminer si la demande peut être resoumise ultérieurement. Vous pouvez également envoyer des courriels d'avis d'erreur aux administrateurs d'intégration.

Les programmes de traitement des erreurs ont réglé les demandes qui ont échoué au statut ERREUR dans la table des parcs de stationnement. Ces demandes peuvent être mises à jour dans la table avec le statut ERROR_RETRY et elles seront prélevées dans le prochain programme de 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 ERREURES vers ERROR_RETRY peut être effectuée par un administrateur de la base de données.
• Vous pouvez même ajouter un flux d'intégration de resoumission qui s'exécute quotidiennement ou selon la fréquence souhaitée, et mettre à jour tous les enregistrements ERREUR à ERROR_RETRY.
• Le programme de traitement des erreurs de l'intégration de processeur asynchrone peut régler le statut à ERROR_RETRY directement, de sorte que chaque défaillance soit resoumise automatiquement dans la programmation suivante.

Correction des données utiles

Le stockage des données utiles de création de compte dans la table de stationnement nous a permis de corriger les données utiles des erreurs de données avant la resoumission. Mettez à jour les données utiles et réglez la colonne de statut à ERROR_RETRY pour resoumettre une demande avec les données utiles corrigées.