FR
Comment fonctionnent les intégrations de systèmes

AtroCore Integrations synchronise les données entre vos systèmes par configuration, chacune adaptée à vos besoins et au fonctionnement garanti.

Intégrations de systèmes en un coup d'œil

AtroCore Integrations connecte AtroPIM/AtroCore à chaque système qui détient ou nécessite vos données produit, qu'il s'agisse d'un ERP, d'une place de marché ou d'une plateforme e-commerce, d'un système multicanal ou DAM, d'un CMS ou DXP, ou encore d'un PLM ou PDM. Chaque scénario est adapté à votre environnement. Aucune programmation n'est requise, seulement de la configuration. Chaque intégration est mise en œuvre individuellement selon vos exigences spécifiques et validée sur vos propres données avant la mise en production, ce qui nous permet de garantir une solution qui fonctionne dans votre environnement. Voici les points forts de ce que vous obtenez:

Échange orchestré selon votre calendrier

L'échange de données est organisé en Synchronisations qui s'exécutent manuellement, selon une planification basée sur cron jusqu'à des intervalles d'une minute, ou de manière événementielle lorsqu'un enregistrement est créé, mis à jour ou atteint un statut défini. Chaque type de données conserve son propre rythme, de sorte que les données de référence sont transférées la nuit tandis que les prix et les stocks sont actualisés toutes les heures.

Tout système, toute méthode de transport

Les connexions sont établies via des services web REST et SOAP, un accès direct à la base de données ou l'échange de fichiers par SFTP, FTPS, HTTP(S) et partages réseau, en combinant plusieurs méthodes lorsque cela s'avère utile. Les mêmes mécanismes s'appliquent on-premises, dans le cloud et dans des environnements hybrides, AtroCore initiant les connexions sortantes, de sorte qu'aucun port entrant n'a besoin d'être ouvert.

Bidirectionnel et complet en portée

Les données sont récupérées et transmises au sein du même scénario, couvrant chaque entité, attribut et relation du système, y compris vos propres entités et champs personnalisés, les valeurs d'attribut par langue et par canal, les prix, les informations de stock et les ressources numériques avec leurs métadonnées.

Mappage et transformation sans développement

Le mappage au niveau des champs, les paramètres de format pour CSV, Excel, JSON et XML, les filtres, les types d'action, les transformations de valeurs et les scripts optionnels de préparation des données relèvent tous de la configuration plutôt que du code, de sorte que même des structures sources inhabituelles sont prises en charge sans projet de développement sur mesure.

Entièrement transparent pour votre administration

Toutes les configurations sont consultables et modifiables dans l'interface d'administration, de la Synchronisation jusqu'au mappage d'un seul champ. La configuration est stockée sous forme de données plutôt que de code, ce qui la rend compatible avec les mises à niveau et permet à votre administrateur de réagir à une modification de la structure source sans déploiement ni intervention d'un développeur.

Fonctionnement fiable avec journalisation complète

Les chargements delta et la correspondance des enregistrements basée sur des clés rendent les exécutions efficaces et reproductibles, les Sub-Jobs parallèles maintiennent la rapidité pour de gros volumes de données, et les relances automatiques ainsi que les fichiers d'erreurs résolvent la plupart des problèmes sans intervention manuelle. Chaque exécution crée un Job avec journalisation complète, surveillé via des Widgets de Dashboard et des notifications d'échec.

Les synchronisations orchestrent l'échange de données

Une Synchronisation est l'unité d'orchestration de plus haut niveau. Elle définit quels systèmes sont connectés, dans quelle direction les données circulent et quand chaque transfert est exécuté. Chaque Synchronisation regroupe les paramètres de connexion, la méthode de transport et la logique d'exécution d'un scénario d'intégration. Rien n'est codé en dur et aucun produit middleware distinct n'est requis.
  • Configurée par notre équipe : pendant le projet de mise en œuvre, nous analysons les interfaces de vos systèmes, documentons les endpoints, tables et formats d'export disponibles, et convenons avec vous quel système constitue la source de référence pour chaque entité et chaque champ avant la création du premier Feed.
  • Tout est consultable et modifiable dans l'administration : toutes les configurations, de la Synchronisation et de sa planification jusqu'au mappage d'un champ individuel, sont stockées sous forme de données et gérées dans l'interface d'administration, où un administrateur disposant des autorisations correspondantes peut les consulter, les ajuster et les étendre à tout moment.
  • Aucun middleware supplémentaire : la couche d'intégration fait partie de la plateforme AtroCore et s'exécute sur le même serveur d'applications, de sorte qu'il n'y a aucun produit ETL ou iPaaS distinct à licencier, héberger et surveiller, ni de second emplacement où les identifiants et les mappages doivent être gérés.
  • Exécution manuelle, planifiée ou événementielle : une Synchronisation est démarrée manuellement depuis l'interface utilisateur, exécutée selon une planification basée sur cron jusqu'à des intervalles d'une minute, ou déclenchée automatiquement lorsqu'un enregistrement est créé, mis à jour ou atteint un statut défini (les déclencheurs événementiels nécessitent le module Workflows).
  • Cadence indépendante par type de données : chaque Synchronisation possède sa propre planification, de sorte que les données de référence produit sont transférées la nuit tandis que les prix et les niveaux de stock sont mis à jour toutes les heures, et que les nouvelles ressources sont récupérées dès leur arrivée.
  • Bidirectionnelle par conception : les données sont récupérées depuis le système connecté et transmises à celui-ci au sein du même scénario d'intégration, y compris les entités personnalisées, les champs personnalisés et les relations spécifiques à votre activité.
  • Exécution basée sur une file d'attente : chaque exécution est envoyée à la file d'attente des tâches et traitée par des workers en arrière-plan, de sorte que les transferts ne bloquent jamais les sessions utilisateur interactives ; plusieurs Synchronisations s'exécutent simultanément, et le débit est mis à l'échelle en ajoutant des workers et des ressources CPU plutôt qu'en repensant l'interface.

Connectivité, authentification et topologie réseau

La couche de transport est configurée par connexion et s'adapte à ce que le système à l'autre bout propose réellement, qu'il s'agisse d'un service web moderne, d'une base de données ou d'un dépôt de fichiers nocturne. Les paramètres de connexion, les endpoints et les paramètres de transport font partie de la configuration dans l'interface d'administration, de sorte que votre équipe sait toujours quel système est contacté, comment et avec quels identifiants.
  • Plusieurs méthodes de transport : services web REST et SOAP, accès direct à la base de données (généralement via des vues en lecture seule ou un schéma de staging dédié) et échange de fichiers par SFTP, FTPS, HTTP(S) ou un partage réseau monté. Les méthodes sont combinées au sein d'une même Synchronisation lorsque c'est l'option la plus fiable.
  • Authentification et gestion des identifiants : les mécanismes d'authentification courants des systèmes métier sont pris en charge, notamment la clé API, HTTP Basic et l'accès basé sur des tokens, avec le renouvellement automatique des tokens arrivant à expiration. Les identifiants appartiennent à la connexion et non au Feed individuel, de sorte qu'un secret ayant fait l'objet d'une rotation est modifié à un seul et unique endroit.
  • Topologie compatible avec les pare-feu : AtroCore initie normalement la connexion en sortie, ce qui signifie qu'aucun port entrant n'a besoin d'être ouvert dans votre réseau. Lorsque le système externe doit initier la connexion, notre API REST est utilisée, sécurisée par un utilisateur API dédié, des restrictions ACL et, en option, une liste d'adresses IP autorisées, un VPN ou un peering de réseau privé.
  • On-premises, cloud ou hybride : les mêmes mécanismes s'appliquent, qu'AtroCore s'exécute dans votre propre centre de données, dans notre hébergement ou dans un environnement hybride avec des services cloud d'un côté et un ERP on-premises de l'autre.
  • Résiliente face aux limites du système distant : la pagination et le traitement des réponses renvoyées sont configurés par interface, avec les délais d'expiration et les relances automatiques, de sorte que les limites de débit de l'API, les fenêtres de traitement par lots et les brèves interruptions de l'autre côté sont gérées sans intervention manuelle.
  • Contrôle d'accès et contexte d'exécution : l'exécution et la configuration sont régies par le système de rôles et d'autorisations, de sorte que les opérateurs démarrent un Job tandis que seuls les administrateurs désignés modifient les mappages, les filtres ou les identifiants. Chaque Feed est exécuté soit au nom du système, soit au nom de l'utilisateur qui le démarre, ce qui détermine les autorisations appliquées pendant le traitement.
  • Validée avant la mise en production : les Synchronisations sont construites et testées sur une instance de staging avec des extraits réels de vos données, puis transférées en production avec les paramètres de connexion échangés, de sorte que la première exécution productive n'est pas la première exécution.

Les synchronisations se composent de Feeds d'import et d'export

Les Feeds d'import/export sont les blocs exécutables d'une Synchronisation. Chaque Feed définit une direction, un périmètre de données et un format, et sa configuration complète reste consultable et modifiable dans l'administration. Une Synchronisation regroupe autant de Feeds que le scénario l'exige, chacun avec une configuration individuelle et une position définie dans l'ordre d'exécution. C'est là que devient visible la part de l'intégration que votre propre équipe contrôle.
  • Un Feed par périmètre de données et par direction : une même Synchronisation peut contenir un Feed d'import pour les classifications provenant de SAP Business One, un deuxième pour les données de référence produit, et un Feed d'export qui publie du contenu produit enrichi vers Microsoft Dynamics ou votre boutique en ligne.
  • Configuration individuelle par Feed : la source et la cible, la définition de l'endpoint ou du fichier, le mappage, les filtres, le type d'action, la validation et la gestion des erreurs sont définis par Feed, de sorte qu'une modification apportée à un Feed laisse tous les autres intacts et peut être testée de manière isolée.
  • Ordre d'exécution déterministe : l'ordre de tri au sein de la Synchronisation résout les dépendances de manière fiable, par exemple importer les classifications et les attributs avant les valeurs d'attribut correspondantes, ou créer les produits avant que leurs relations et affectations de ressources ne soient écrites.
  • Adaptateurs avec modèles de configuration : pour les cibles d'intégration récurrentes, nous fournissons des Adaptateurs qui encapsulent les définitions d'endpoint, les structures de données et la logique de traitement du système externe, ajoutent des types de feed dédiés et livrent des modèles préconfigurés pour les paramètres de connexion et de mappage, ce qui raccourcit la configuration et supprime toute une catégorie d'erreurs manuelles.
  • Réutilisable et duplicable : un Feed existant est dupliqué et adapté plutôt que reconstruit, ce qui maintient la cohérence entre des scénarios comparables tels que plusieurs canaux de vente, sites ou filiales par pays.
  • La configuration, c'est de la donnée, pas du code : l'ensemble du paramétrage est stocké dans la base de données et géré via l'interface d'administration. Il n'y a aucune interface compilée ni aucun core modifié, de sorte que les mises à niveau de version laissent votre intégration intacte, et lorsqu'un système connecté acquiert un nouveau champ, votre administrateur l'ajoute au mappage sans déploiement et sans intervention d'un développeur.
  • Open source : à la fin du projet, la configuration est remise avec les mappages et les planifications. Le code source de la plateforme est ouvert, de sorte que votre équipe peut auditer exactement ce qu'il advient de vos données au lieu de faire confiance à une boîte noire.

Toute structure de données, y compris vos propres extensions

Les Feeds ne se limitent pas à un ensemble prédéfini de champs. Chaque entité, attribut et relation du système peut faire partie d'un transfert, y compris tout ce que vous avez ajouté vous-même. Le périmètre de données de chaque Feed est défini dans l'interface d'administration et ajusté dès que votre modèle de données ou un système connecté évolue.
  • Couverture complète des entités : les Feeds ciblent n'importe quelle entité du système, standard ou personnalisée, y compris les produits, catégories, classifications, attributs, fournisseurs et toute entité supplémentaire que votre scénario requiert.
  • Valeurs spécifiques par langue et par canal : les valeurs d'attribut sont transférées par langue et par canal, de sorte qu'un catalogue multilingue et un contenu spécifique à chaque canal sont gérés dans le même Feed au lieu de nécessiter une interface distincte par marché.
  • Relations, prix et informations de stock : les relations de toute cardinalité, les données de prix et de stock ainsi que les affectations de catégorie ou de classification sont transférées avec les données de référence auxquelles elles appartiennent.
  • Transfert de ressources et de binaires : les images, documents et autres fichiers sont importés par URL ou depuis un chemin du système de fichiers, les métadonnées, les types de ressources et les affectations de produits étant traités au cours de la même exécution.
  • Champs personnalisés sans développement : les entités et les champs que vous ajoutez vous-même dans le panneau d'administration sont immédiatement disponibles comme sources et cibles de mappage dans chaque Feed, de sorte qu'étendre le modèle de données ne signifie pas réécrire l'interface.
  • Mappage des données au niveau des champs : les règles de mappage sont définies séparément pour chaque champ d'entité et chaque attribut, y compris la colonne source ou le chemin d'API, le champ cible, les valeurs par défaut, les indicateurs d'obligation et le comportement pour les valeurs vides.
  • Le mappage définit la portée d'une écriture : seuls les champs contenus dans le mappage sont écrits, de sorte que les champs gérés dans un autre système ou enrichis manuellement dans AtroCore ne sont ni écrasés ni vidés par un import qui n'a pas vocation à les gérer.

Formats, logique de transfert et transformation des données

Les interfaces réelles livrent rarement les données dans la structure attendue par le système cible. La configuration d'un Feed comble cet écart sans projet de développement sur mesure. Les paramètres de format, le mode de transfert, les filtres et les transformations sont configurés par Feed et restent entièrement modifiables dans l'interface d'administration.
  • Transferts complets et delta : les chargements complets sont utilisés pour la migration initiale et les petits jeux de données de référence, les chargements delta pour l'exploitation quotidienne, en s'appuyant sur les horodatages de modification, les indicateurs de changement ou la file d'attente d'export du système source, ce qui maintient le volume transféré proportionnel aux changements réels.
  • Correspondance déterministe des enregistrements : les enregistrements sont identifiés par une clé métier stable telle que le SKU, le numéro d'article ERP ou un ID externe persisté sur l'enregistrement cible, de sorte que les exécutions répétées mettent à jour les données existantes au lieu de créer des doublons, et qu'un transfert interrompu est simplement relancé.
  • Configuration spécifique au format : pour CSV et Excel, cela couvre le délimiteur, le caractère d'encadrement, l'encodage des caractères, la ligne d'en-tête, la feuille de calcul, les séparateurs décimal et de milliers, les formats de date et d'heure ainsi que le délimiteur pour les champs à valeurs multiples. Pour JSON et XML, ce sont les chemins de nœuds pertinents qui sont configurés à la place.
  • Conversion tenant compte du type : les valeurs entrantes sont converties dans le type de données cible, ce qui couvre les unités de mesure, les devises, les notations booléennes, les énumérations mises en correspondance avec des options d'attribut, ainsi que les formats de nombre et de date propres à la locale.
  • Types d'action flexibles : insérer de nouveaux enregistrements, mettre à jour les enregistrements existants, insérer et mettre à jour en une seule passe, supprimer des enregistrements, ou toute combinaison de ces actions, définie par Feed.
  • Filtres avancés : le jeu de données transféré est restreint par des valeurs de champ, par exemple exporter uniquement les produits au statut validé, uniquement les articles affectés à un Marketing Channel spécifique, ou uniquement les enregistrements modifiés depuis l'exécution précédente.
  • Transformations : les transformations s'exécutent avant l'import ou l'export des données et couvrent les tables de correspondance de valeurs, comme un code couleur ERP traduit en une option d'attribut, la conversion d'unités et de devises, les opérations sur les chaînes de caractères ainsi que la concaténation ou la séparation de champs.

Traitement, gestion des erreurs et journalisation complète

Chaque exécution d'un Feed crée un Job qui documente ce qui a été transféré, ce qui a été ignoré et ce qui a échoué, jusqu'au niveau de l'enregistrement et du champ individuel. C'est la partie avec laquelle votre équipe travaille au quotidien, et elle répond à la question de savoir ce qui s'est passé pendant l'exécution de la nuit précédente sans avoir à deviner.
  • Scripts pour la préparation et le traitement des données : lorsque la configuration standard ne suffit pas, des scripts sont rattachés à un Feed d'import ou d'export afin de préparer ou de traiter les données avant leur import ou leur export, ce qui maintient la logique propre à chaque cas au sein de la configuration du Feed au lieu de la disperser entre les systèmes connectés.
  • Validation avant l'écriture des données : les champs obligatoires, les types de données, les options autorisées et l'intégrité référentielle sont vérifiés pendant le traitement, de sorte qu'un enregistrement non valide est rejeté avec un message lisible au lieu de dégrader silencieusement la qualité de vos données.
  • Sub-Jobs parallèles : les charges utiles volumineuses sont automatiquement découpées en Sub-Jobs traités en parallèle par les workers de la file d'attente, ce qui maintient des temps d'exécution prévisibles pour des jeux de données tels que des enregistrements produit comportant un grand nombre de valeurs d'attribut.
  • Traitement des erreurs optimisé : les défaillances transitoires telles que les délais d'expiration réseau ou les verrous d'enregistrement font l'objet de relances automatiques, un enregistrement en erreur est isolé au lieu d'interrompre toute l'exécution, et un fichier d'erreurs contenant uniquement les lignes rejetées ainsi que leurs messages peut être exporté, corrigé et réimporté. Des relances manuelles sont disponibles pour les Jobs principaux et pour les Sub-Jobs individuels.
  • Journalisation complète : chaque Job enregistre l'heure de début et de fin, la durée, l'utilisateur ou le déclencheur qui l'a initié, le nombre d'enregistrements créés, mis à jour, supprimés, ignorés et en échec, ainsi que des entrées par enregistrement avec la charge utile source et le message résultant.
  • Surveillance et notification via le Dashboard : les Widgets du Dashboard affichent d'un coup d'œil le statut et l'historique des Jobs récents, et les échecs sont signalés par notification in-app ou par e-mail, de sorte qu'une exécution défaillante est repérée le jour même où elle survient plutôt qu'à la prochaine revue des données.
  • Housekeeping et rétention : les Jobs, les entrées de journal et les fichiers transférés sont soumis à une rétention configurable, ce qui maintient la base de données compacte et répond aux exigences de protection des données lorsque les données transférées contiennent des informations personnelles.

Veuillez nous contacter

human test

FAQ

Comment mettez-vous en œuvre une intégration ?

Nous commençons par analyser les interfaces des systèmes concernés et par documenter quels endpoints, tables ou formats d'export sont réellement disponibles, puis nous convenons avec vous quel système constitue la source de référence pour chaque entité et chaque champ. Sur cette base, nous configurons une ou plusieurs Synchronisations avec leurs Feeds d'import/export, définissons l'ordre d'exécution, les règles de mappage, les filtres et la planification, et validons le tout sur une instance de staging avec des extraits réels de vos données avant leur passage en production.

Quelles données peuvent être synchronisées ?

Toutes les données que les systèmes concernés peuvent fournir. Cela couvre les données de référence produit avec des valeurs d'attribut par langue et par canal, les catégories et classifications, les prix et niveaux de stock, les ressources numériques avec leurs métadonnées, les fournisseurs, clients et commandes, ainsi que chaque entité et chaque champ personnalisés que vous avez ajoutés vous-même. Les champs que vous créez dans le panneau d'administration sont immédiatement disponibles comme sources et cibles de mappage, de sorte qu'étendre votre modèle de données ne signifie pas reconstruire l'interface.

Comment les données sont-elles synchronisées ?

Via des requêtes aux API REST, SOAP et GraphQL, des requêtes directes en base de données (généralement sur des vues en lecture seule ou un schéma de staging dédié), ou l'échange de fichiers par SFTP, FTPS, HTTP(S) et partages réseau montés. La méthode la plus adaptée est sélectionnée individuellement pour chaque cas, et plusieurs méthodes sont combinées au sein d'un même scénario lorsque c'est l'option la plus fiable pour les systèmes à l'autre bout.

La synchronisation se fait-elle en temps réel ?

Elle peut se faire en quasi temps réel. Chaque Synchronisation s'exécute manuellement, selon une planification basée sur cron jusqu'à des intervalles d'une minute, ou de manière événementielle lorsqu'un enregistrement est créé, mis à jour ou atteint un statut défini, les déclencheurs événementiels nécessitant le module Workflows. La plupart des projets combinent les modes, par exemple un export événementiel des produits validés vers la boutique plus une exécution de réconciliation nocturne.

Ai-je besoin d'un middleware supplémentaire pour cela ?

Non. La couche d'intégration fait partie de la plateforme AtroCore et s'exécute sur le même serveur d'applications, de sorte qu'il n'y a aucun produit ETL ou iPaaS distinct à licencier, héberger et surveiller, ni de second emplacement où les identifiants et les règles de mappage doivent être gérés.

Puis-je modifier les configurations ultérieurement ?

Oui. Toutes les configurations sont consultables et modifiables dans l'interface d'administration, de la Synchronisation et de sa planification jusqu'au mappage d'un champ individuel, et aucune programmation n'est requise. Comme la configuration est stockée sous forme de données plutôt que dans du code, votre administrateur l'adapte lorsqu'un système connecté ajoute une colonne ou modifie un format, sans déploiement et sans intervention d'un développeur.

L'auto-intégration est-elle une option ?

Techniquement oui, car rien n'est caché et la plateforme est open source, mais cela requiert une solide connaissance des interfaces des deux côtés et de la configuration des feeds elle-même. Nous recommandons de nous laisser construire et documenter le scénario initial et de le remettre à votre équipe, qui le maintient et l'étend ensuite de manière autonome. C'est ainsi que travaille la plupart de nos clients ; par exemple, nous connectons l'ERP, et ils ajoutent eux-mêmes d'autres feeds pour leur boutique et leurs marketplaces.

Une mise à jour d'AtroCore/AtroPIM va-t-elle casser mon intégration ?

Non. Vos Synchronisations, feeds et règles de mappage résident dans la base de données, et aucun core modifié n'est impliqué, de sorte que les mises à jour de version laissent la configuration d'intégration intacte.

Cela fonctionne-t-il aussi si mon ERP est on-premises et qu'AtroCore est hébergé ?

Oui. Les mêmes mécanismes s'appliquent on-premises, dans notre hébergement et dans les environnements hybrides. Quel côté initie la connexion et quelle méthode de transport est utilisée sont des décisions de configuration que nous prenons conjointement avec votre équipe informatique pendant le projet.

Comment sont gérés les identifiants et l'accès réseau ?

Les identifiants appartiennent à la connexion et non à un Feed individuel, de sorte qu'un secret ayant fait l'objet d'une rotation est modifié à un seul et unique endroit, et les tokens arrivant à expiration sont renouvelés automatiquement. AtroCore initie normalement les connexions en sortie, ce qui signifie qu'aucun port entrant n'a besoin d'être ouvert dans votre réseau. Lorsque le système distant doit initier la connexion, l'accès passe par notre API REST, restreinte par un utilisateur API dédié, des règles ACL et, en option, une liste d'adresses IP autorisées ou un VPN. Les droits de configuration et d'exécution sont séparés par rôle, et chaque Feed s'exécute soit au nom du système, soit au nom de l'utilisateur qui le démarre.

Quel volume de données peut être transféré, et combien de temps dure une exécution ?

Les exécutions sont traitées par des workers en arrière-plan dans la file d'attente des tâches plutôt que dans une session utilisateur, et les charges utiles volumineuses sont automatiquement découpées en Sub-Jobs traités en parallèle, ce qui maintient des temps d'exécution prévisibles pour les catalogues comportant un grand nombre de valeurs d'attribut. Le débit évolue avec le nombre de workers et les ressources CPU disponibles. Les transferts delta basés sur les horodatages de modification ou les indicateurs de changement maintiennent le volume quotidien proportionnel aux changements réels plutôt qu'à la taille de votre catalogue.

Que se passe-t-il si une exécution échoue ou si l'autre système est indisponible ?

Les problèmes transitoires tels que les délais d'expiration réseau ou les verrous d'enregistrement font l'objet de relances automatiques, et un enregistrement en erreur est isolé au lieu d'interrompre toute l'exécution. Les lignes rejetées sont exportées sous forme de fichier d'erreurs avec leurs messages, corrigées et réimportées, et tant les Jobs principaux que les Sub-Jobs individuels peuvent être relancés manuellement. Comme les enregistrements sont mis en correspondance au moyen d'une clé métier stable telle que le SKU ou un numéro d'article ERP, relancer une exécution met à jour les données existantes au lieu de créer des doublons.

Un import peut-il écraser des données que nous gérons manuellement ?

Seuls les champs contenus dans le mappage sont écrits, de sorte que les valeurs gérées dans un autre système ou enrichies manuellement dans AtroCore ne sont ni écrasées ni vidées par un import qui n'a pas vocation à les gérer. Pendant le projet, nous définissons par entité et par champ quel système est la source de référence, ce qui empêche deux systèmes de se disputer la même valeur.

Est-ce que j'obtiens des journaux ?

Oui. Chaque exécution d'un Feed crée un Job qui enregistre l'heure de début et de fin, la durée, l'utilisateur ou le déclencheur qui l'a initié, ainsi que le nombre d'enregistrements créés, mis à jour, supprimés, ignorés et en échec, jusqu'au niveau des entrées par enregistrement avec la charge utile source et le message résultant. Les Widgets du Dashboard affichent d'un coup d'œil le statut et l'historique des Jobs récents, et les échecs sont signalés par notification in-app ou par e-mail.

Comment sont gérées les données personnelles dans les fichiers transférés et les journaux ?

Les Jobs, les entrées de journal et les fichiers transférés sont soumis à une rétention configurable, de sorte que les données contenant des informations personnelles ne sont pas conservées plus longtemps que nécessaire pour l'analyse des erreurs et le retraitement. Associé à l'accès basé sur les rôles aux Jobs et aux configurations, cela répond aux obligations de documentation et de suppression qui vous incombent au titre du RGPD.

Avez-vous des questions ou
souhaitez-vous bénéficier d'une consultation gratuite ?

Contactez nous