Différents états des tâches d'intégration

Une tâche est générée chaque fois que des données transitent par Alumio, et elle permet de suivre les données à chaque étape du processus d'intégration. Il fournit des informations sur l'état de l'intégration, qu'elle soit réussie, en cours, en file d'attente, si elle a été ignorée ou si elle a rencontré des erreurs. Ainsi, outre la mesure de l'échange de données au sein d'Alumio, les tâches constituent également la base des intégrations de surveillance et de dépannage.

C'est pourquoi l'une des premières choses que le tableau de bord Alumio vous montre est l'état en temps réel de vos tâches d'intégration. En plus de vous montrer le nombre total de tâches que vous avez générées, le moniteur de tâches du tableau de bord Alumio donne un aperçu clair des différentes étapes du cycle de vie d'une tâche dans Alumio. Il décompose le trajet des données d'une application à l'autre comme suit :

• Nouvelle tâche : Lorsque les données sont importées pour la première fois depuis une source dans le cadre d'un itinéraire, elles sont reconnues comme une nouvelle tâche.
• Tâche de traitement : Une fois qu'Alumio commence à envoyer ces données à une application cible, la tâche passe au stade du traitement.
• Tâche terminée : Si la tâche est terminée avec succès, elle est marquée comme terminée.
• Tâche échouée : Si une erreur survient lors de l'échange de données, la tâche est étiquetée comme ayant échoué.
• Tâche ignorée : Dans des scénarios tels que les tests ou lorsque certaines données doivent être filtrées, les tâches peuvent être délibérément ignorées manuellement ou de manière automatisée.

Explorons brièvement en quoi chacun de ces statuts de tâche est essentiel pour permettre à l'iPaaS d'Alumio de rationaliser et de surveiller l'ensemble du processus d'intégration à chaque étape.

Nouvelle tâche :

Pour intégrer des données entre des applications, vous devez d'abord collecter des données à partir d'une application source (système A), puis envoyer ces données à une application cible (système B). Une nouvelle tâche est générée lorsqu'Alumio importe avec succès des données depuis le système A, via une configuration entrante, au sein d'un itinéraire.

Lors de la configuration de cette configuration entrante, Alumio vous permet de définir exactement quelles données récupérer et à quelle fréquence les récupérer. Devez-vous extraire toutes les données disponibles ou uniquement des parties spécifiques d'une entité de données ? (par exemple, les commandes provenant d'une région spécifique)? Le format de données doit-il être converti (par exemple, de XML à JSON)? À quelle fréquence les données doivent-elles être importées : chaque minute, chaque heure, chaque jour ou chaque semaine ? Alumio fournit des transformateurs pour modifier et structurer les données entrantes et un planificateur pour déterminer quand et à quelle fréquence les données doivent être récupérées. Cela vous permet d'être très précis quant au type de données que vous souhaitez envoyer à l'application cible.

Par exemple, lors de l'intégration d'un système ERP à la fois à une plateforme de commerce électronique et à un système PIM, Alumio extrait les données des produits et crée une nouvelle tâche, en les mettant en file d'attente pour traitement. À ce stade, vous pouvez filtrer des enregistrements spécifiques (par exemple, uniquement les produits mis à jour), normaliser les formats (par exemple, convertir des devises) et enrichir les données (par exemple, ajouter des attributs manquants). Cela vous permet de collecter et de structurer les données au sein d'Alumio avant de décider comment les transformer pour différentes destinations. Vous pouvez mapper les catégories de produits différemment pour le système PIM tout en ajustant les formats de prix pour la plateforme de commerce électronique, le tout à partir de la même nouvelle tâche.

Remarque : Si aucune configuration entrante n'est configurée dans un itinéraire (actif), aucune nouvelle tâche ne sera crééed.

Tâches de traitement :

Lorsque vous créez une configuration sortante et que vous exécutez la route dans Alumio pour envoyer les données que vous avez extraites d'une source (système A) à une application cible (système B), une nouvelle tâche se transforme en tâche de traitement.

Comme indiqué précédemment, c'est la raison pour laquelle Alumio n'envoie pas (exporte) immédiatement les données qu'il extrait (importe) via une configuration entrante et ne les met pas en file d'attente en tant que nouvelle tâche. Ainsi, vous pouvez choisir où et comment vous souhaitez envoyer ces données en créant une configuration sortante. Devez-vous filtrer, modifier ou mapper le format des données que vous avez importées pour qu'elles correspondent à l'application cible ? Ou souhaitez-vous envoyer les données par lots toutes les minutes, toutes les heures, toutes les semaines, etc. ? Alumio vous permet de décider de la manière dont vous souhaitez transformer et planifier les données que vous avez extraites du système A avant de les envoyer au système B.

Comme dans notre exemple précédent, la planification de l'envoi des données que vous avez extraites du système ERP vers la plateforme de commerce électronique crée une tâche de traitement. Une tâche de traitement entre dans la file d'attente d'Alumio et se prépare à envoyer les données au moment prévu.
‍

Remarque : Alumio permet également aux utilisateurs de sélectionner l'option « Traitement en temps réel » lors de la création d'un itinéraire, dans le cas où des données critiques doivent être intégrées immédiatement. Dans ce cas, au moment où l'itinéraire est exécuté, une tâche de traitement est directement créée au lieu d'une nouvelle tâche, et elle cherche immédiatement à devenir une tâche terminée.
‍

Tâches terminées :

Une tâche de traitement devient une tâche terminée lorsque l'échange de données entre l'application source et l'application cible est terminé avec succès. Cela signifie qu'Alumio a envoyé avec succès les données importées au système cible et que les règles de transformation ou de planification que vous avez configurées ont été appliquées sans problème.

Par exemple, si le système ERP envoie avec succès les mises à jour des produits à la plateforme de commerce électronique et que toutes les données ont été reçues, traitées et stockées correctement, la tâche passe de l'état En cours à l'état Terminé.

Tâches ayant échoué :

Une tâche de traitement devient une tâche ayant échoué si quelque chose empêche le bon traitement de l'échange de données. Cela peut être dû à toute une série de problèmes, tels que :

• L'application cible (système B) est temporairement indisponible.
• Le format de données ne correspond pas à la structure attendue dans le système récepteur.
• Erreurs d'authentification ou d'autorisation empêchant l'échange de données.

Lorsqu'une tâche échoue, Alumio fournit des journaux d'erreurs et des options de dépannage pour vous aider à identifier et à résoudre rapidement le problème. Vous pouvez réessayer la tâche une fois le problème résolu, en vous assurant qu'aucune donnée n'est perdue.

Par exemple, si un ERP essaie d'envoyer des mises à jour de produits à un système de commerce électronique, mais que le champ SKU est manquant ou mal formaté, la tâche échouera et les détails de l'erreur seront enregistrés pour révision. Vous pouvez ensuite consulter les journaux pour identifier et résoudre rapidement l'erreur, puis recommencer la tâche.
‍

Tâches ignorées :

Il existe également une « Tâches ignorées » dans l'iPaaS Alumio qui compte les tâches qui, pour diverses raisons telles que des tests ou des règles de filtrage prédéfinies, sont intentionnellement contournées. Une tâche est classée comme « ignorée » lorsqu'Alumio détecte que les données en cours de traitement n'ont pas besoin d'être envoyées au système cible. Cela se produit lorsque :

• Les données existent déjà dans le système cible et n'ont pas changé.
• La logique d'intégration comporte des conditions qui déterminent si les données doivent être traitées (par exemple, envoyer uniquement de nouvelles commandes mais ignorer les commandes déjà traitées).
• Les règles de transformation filtrent les données spécifiques avant qu'elles n'atteignent la configuration sortante.

Alumio vous permet d'ignorer manuellement des données spécifiques ou d'appliquer des règles pour ignorer automatiquement des données spécifiques en bloc. Par exemple, supposons qu'un ERP soit configuré pour envoyer des mises à jour de produits à une plateforme de commerce électronique toutes les 10 minutes, mais qu'aucune modification n'a été apportée aux données du produit depuis la dernière mise à jour. Alumio peut le reconnaître et marquer la tâche comme ignorée. Cela permettra d'éviter tout traitement inutile. Cela permet d'optimiser les performances et d'éviter les appels d'API redondants.

Étant donné que les données ignorées restent stockées dans Alumio, cela permet également à l'iPaaS Alumio de faire office de système de mise en cache. Cela signifie que si des données précédemment ignorées deviennent pertinentes ultérieurement, par exemple si une commande passe de « En attente » à « Payée », vous pouvez facilement la retraiter sans avoir à les extraire à nouveau de l'application source. Cela améliore l'efficacité et réduit la charge sur les systèmes connectés.

‍

Comment utiliser Alumio comme système de mise en cache

Alumio peut également être utilisé comme système de mise en cache, dans lequel seules les versions delta des données, ou uniquement les versions mises à jour ou nouvelles des données, seront envoyées d'une application à l'autre.

Par exemple, supposons que nous extrayons régulièrement un millier de dossiers, ce qui représente des milliers de produits, d'une application à l'autre. Il est productif d'envoyer des données uniquement pour les produits dont le prix, le stock, l'inventaire, etc. ont été mis à jour à l'autre application, ou des données pour des produits entièrement nouveaux et qui n'ont pas encore été enregistrés dans l'autre application.

Avec cette approche, vous pouvez planifier une mise à jour toutes les minutes, en n'envoyant qu'une poignée de tâches, par exemple trois, cinq ou, aux heures de pointe, peut-être vingt nouvelles mises à jour de produits. C'est beaucoup plus efficace que d'essayer d'envoyer les mille enregistrements chaque minute. En vérifiant régulièrement la présence de nouvelles données et en n'envoyant que ces données, nous évitons de perdre du temps et des ressources dans le traitement de tâches redondantes. Si vous avez besoin de voir les données filtrées, vous pouvez consulter les journaux qu'Alumio aide à maintenir pour chaque action et intégration.
‍

Autres statuts de tâches essentiels dans Alumio

Au-delà des statuts des tâches principales affichés sur le tableau de bord, Alumio gère également des statuts de tâches supplémentaires qui jouent un rôle crucial pour garantir un traitement fluide des données. Ces statuts sont « Réessayer », « Rejeté » et « En attente », ce qui permet d'automatiser la gestion des erreurs, de renforcer la validation des données et de fournir un contrôle manuel sur des tâches spécifiques en cas de besoin.
‍

Réessayer les tâches :

Il est possible que vous deviez retraiter une tâche pour exporter à nouveau les données vers le système cible. Cela peut être dû au fait que la tâche a échoué précédemment en raison d'un problème de configuration qui a été résolu depuis, ou simplement parce que toutes les entités doivent être retraitées, même si elles étaient déjà marquées comme Terminées.

Lorsque l'option « Activer la nouvelle tentative des tâches ayant échoué » est activée dans un itinéraire, Alumio tente automatiquement de retraiter les tâches ayant échoué. Cela signifie qu'Alumio tentera automatiquement de retraiter la tâche jusqu'à ce qu'elle réussisse ou atteigne la limite de nouvelles tentatives configurée. Cette fonctionnalité permet de résoudre des problèmes temporaires, tels que de brèves pannes du système ou des interruptions du réseau, sans nécessiter d'intervention manuelle. Si une tâche continue d'échouer après avoir épuisé le maximum de tentatives, elle sera marquée comme ayant échoué et les détails de l'erreur seront enregistrés à des fins de résolution des problèmes.

Réessayer les tâches manuellement définira le statut des tâches sur Nouveau encore une fois, l'itinéraire le traitera vers le système sortant lors de la prochaine exécution. Sur la page de présentation des tâches, vous pouvez filtrer et choisir de réessayer plusieurs tâches à la fois. Vous pouvez également choisir de sélectionner une seule tâche et de la réessayer. De cette façon, vous ne pouvez réessayer qu'une tâche dont le statut est Terminé, Échec ou Ignorée.
‍

Tâches rejetées :

Une tâche est classée comme rejetée lorsqu'elle ne répond pas à des contraintes système ou à des règles de validation spécifiques. Par exemple, si une limite de 1 000 octets est définie pour les données d'entité et qu'une tâche dépasse ce seuil, elle sera rejetée au lieu d'être traitée. De même, les tâches dont les données d'entité ne sont pas valides peuvent être automatiquement rejetées pour empêcher les erreurs de se propager au cours de l'intégration. La raison du rejet est enregistrée dans les journaux d'importation sur la page des détails de la tâche, ce qui permet aux utilisateurs de vérifier et de résoudre le problème avant de soumettre à nouveau les données.

‍

Tâches en attente :

Dans certains cas, les utilisateurs peuvent configurer un itinéraire de telle sorte qu'au lieu d'être automatiquement marquée comme terminée ou comme ayant échoué après le traitement, une tâche passe au statut « En attente ». Cela donne aux utilisateurs la possibilité de revoir manuellement la tâche et de déterminer son résultat en fonction des informations disponibles dans les journaux. Si une tâche est en statut « En attente », les utilisateurs peuvent décider si elle doit être marquée comme terminée ou comme ayant échoué en utilisant le menu « Actions ». Des actions groupées peuvent également être appliquées pour mettre à jour plusieurs tâches en attente à la fois. Ce statut est particulièrement utile dans les cas où une validation manuelle est requise avant de finaliser le processus d'intégration.

Maintenant que nous avons compris les différents types de tâches dans Alumio, explorons tous les détails qu'une tâche contient pour comprendre comment elle permet en outre de suivre, de gérer et de rationaliser l'intégration à chaque étape du processus.
‍