Présentation de l'Alumio Route Builder
Connectez, orchestrez et gouvernez vos intégrations depuis une interface visuelle
Les commandes et les clients de Shopware arrivent dans PostgreSQL sous la forme définie par un utilisateur, de sorte que les données qui y arrivent sont conçues pour la tâche pour laquelle ce magasin a été créé.
Une base de données est neutre vis-à-vis de votre activité. Elle accepte les données qui lui sont fournies, dans le format défini par un utilisateur, et elle acceptera aussi bien une commande mal structurée qu'une commande bien structurée. La première question à se poser est donc : à quoi sert réellement cette structure ? En effet, les rapports et l'alimentation d'une autre application nécessitent des informations différentes issues d'une même commande Shopware. Faute de réponse, toutes les données sont consignées dans une structure unique et incohérente. La connexion entre Shopware et PostgreSQL commence par la définition de ce format, qui constitue le seul contrat existant entre les deux.
DES DONNÉES QUI CIRCULENT ENTRE EUX
Commandes
Lignes de commande
Clients
Produits
Chargement des références
Chargement des horodatages
PostgreSQL est mentionné dans la liste des bases de données prises en charge par Alumio ; les données Shopware sont donc écrites directement dans la structure que vous avez définie, plutôt que par l’intermédiaire d’un chargeur géré par un tiers.
Chaque commande est associée à son identifiant, de sorte qu'un deuxième chargement met à jour les données existantes plutôt que d'ajouter un doublon quasi-identique que personne ne remarque jusqu'à ce qu'un comptage semble erroné.
Les horodatages de chargement sont associés aux données, ce qui permet à toute personne les consultant de savoir à quel point une donnée est à jour au lieu de supposer qu'elle a dû être écrite ce matin.
Comme Shopware est lu selon un calendrier et mis en place, la boutique n'est pas interrogée à nouveau par chaque processus qui souhaite les mêmes commandes, ce qui allège la charge de reporting de la boutique en ligne.
Alumio inscrit les commandes Shopware et leurs lignes dans PostgresQL selon le format que vous définissez et en fonction de l'identifiant que vous utilisez, afin que le magasin reçoive ce pour quoi il a été conçu plutôt que ce qu'il a renvoyé par hasard.
Un chargement répété correspond à ce qui existe déjà au lieu d'insérer à nouveau des données, de sorte qu'un entrepôt utilisé pour les rapports n'accumule pas lentement des commandes en double qui gonfleraient discrètement tous les chiffres extraits ultérieurement.
Lorsque le magasin alimente une autre application plutôt qu'un rapport, seules les données nécessaires à cette application y sont inscrites, ce qui permet au développeur de s'appuyer dessus plutôt que d'obtenir une copie de tout ce que Shopware contient.
Alumio se place entre vos canaux de vente et vos systèmes de traitement des commandes en tant qu'épine dorsale d'intégration gouvernée. Les commandes sont acheminées, transformées et validées, tandis que les mises à jour de statut sont renvoyées vers chaque canal.
Authentifiez vos systèmes à l'aide des connecteurs pré-construits d'Alumio. Faites votre choix parmi plus de 200 packs de connecteurs sur la marketplace, en plus d'intégrations personnalisées illimitées.
Définissez la correspondance des champs de données entre vos systèmes via une interface visuelle. Ajustez les formats, enrichissez les enregistrements et appliquez vos règles métier, sans aucun code personnalisé.
Configurez vos flux pour qu'ils s'exécutent en temps réel selon des événements, selon un calendrier, ou les deux. Réduisez la saisie manuelle des données et laissez Alumio gérer les transferts et les transformations entre vos systèmes.
.svg){kind=icon}
Une fois votre première intégration en ligne, l'ajout de votre ERP, PIM, WMS ou CRM se connecte au même hub. Les flux existants continuent de fonctionner. Pas besoin de tout reconstruire.
Il est important de définir la finalité du stockage avant toute autre connexion, car cela influencera la réponse. Lorsque PostgreSQL sert d'archive plutôt que de flux de données, il est généralement nécessaire d'ajouter un service de conservation et d'archivage, car la conservation permanente de chaque commande Shopware représente un coût et une contrainte plutôt qu'un atout. Alumio gère les deux types de connexions ; ainsi, la décision concernant les données conservées et celles transférées ne fait qu'un.
L'emplacement et l'identification des données sont primordiaux ; le reste n'est que détail. Alumio lit les commandes Shopware et les clients que vous avez sélectionnés selon la fréquence définie et les enregistre dans PostgreSQL au format que vous avez défini. La correspondance se fait sur les éléments d'identification, ce qui permet de mettre à jour les données lors d'un chargement ultérieur plutôt que d'y insérer des données. Seules les modifications pertinentes sont traitées, évitant ainsi à la boutique et au magasin de traiter les données deux fois.
Non, et la forme correspond au contrat plutôt qu'au code. La manière dont chaque détail Shopware est intégré à PostgreSQL, et ce qui l'identifie une fois intégré, est définie dans l'interface d'Alumio, qui est également documentée de par son existence même. Puisqu'une conception interne reflète les conventions choisies par son auteur, le transformateur de code reste disponible pour tout élément qui ne peut pas être interprété tel quel.
Les deux, généralement, et les considérer comme une seule entité est une erreur. Une base de données PostgreSQL recevant des données Shopware est à la fois une destination pour l'écriture et une source pour la lecture ultérieure. Sa structure dépend donc entièrement de la seconde partie, et il est impossible de définir correctement la première sans la connaître. Déterminer ce qui lira ces données, avant de décider de ce qui y sera écrit, permet d'éviter une structure trop vaste et peu fiable.
Une écriture réussie au mauvais endroit est une erreur dont une base de données ne se plaindra jamais, car elle n'a aucune raison de le faire. Alumio détecte les écritures refusées dès qu'elles se produisent et enregistre l'emplacement de chaque chargement Shopware dans PostgreSQL ainsi que son contenu. En cas de refus d'écriture, une alerte est immédiatement émise, le motif est indiqué, des tentatives de réexécution sont effectuées si la configuration le permet, et le chargement reste affiché jusqu'à sa validation. Ainsi, aucune donnée n'est insérée deux fois et aucune donnée n'est perdue entre les deux.
Échangez avec un spécialiste de l'intégration Alumio. Nous concevrons l'architecture adaptée à vos systèmes et à votre échelle, pour garantir la fiabilité de vos opérations à chaque étape de votre évolution.
.svg)
