L'application que l'entreprise a développée en interne offre déjà une porte d'entrée, et ce qui manque entre elle et Shopware, c'est un accord sur les opérations qui importent plutôt que sur tout nouveau développement.
Tous les systèmes d'une entreprise ne proviennent pas d'un fournisseur. Il existe forcément une application développée en interne, car aucune solution du marché ne répondait parfaitement à ses besoins. Son interface est fonctionnelle, car son concepteur a fait preuve de bon sens. Cependant, elle ne dispose pas de connexion à la boutique en ligne, et l'on suppose généralement que combler cette lacune implique de trouver un développeur. L'intégration de Shopware à l'API REST relève de la configuration et non du projet ; ainsi, l'application développée en interne devient accessible à tous.

L'application développée ici permet d'échanger des commandes et des stocks avec Shopware, ce qui évite d'être coupé de tout ce que l'entreprise achète par la suite, car elle est sur mesure.
La mise en relation des deux est un exercice de configuration plutôt qu'une tâche à planifier en fonction de tout le reste des activités de la seule personne qui connaît cette application.
Une commande, un contrôle des stocks et une mise à jour du statut sont configurés séparément ; modifier l'un d'eux ultérieurement ne signifie donc pas rouvrir un accord qui les couvre tous les trois à la fois.
La manière dont la boutique en ligne et l'application communiquent entre elles est consignée par écrit à un endroit où l'équipe actuelle peut la consulter, plutôt que de rester dans la mémoire de celui qui a initialement créé le système.
Lorsqu'une commande est passée dans Shopware, Alumio la met en forme conformément aux attentes de l'application et l'y envoie, de sorte que le système mis en place par l'entreprise pour gérer son activité reçoive les commandes web de la même manière que toutes les autres données.
Lorsque l'application a quelque chose à dire concernant une commande, l'information parvient au client Shopware au lieu de rester interne à un système que seules trois personnes peuvent ouvrir, ce qui explique généralement pourquoi personne ne pouvait répondre à la question auparavant.
Lorsque la personne qui assure la maintenance de l'application modifie l'une de ses fonctionnalités, seule cette partie du système est ajustée ; une amélioration interne ne devient donc pas la raison pour laquelle la boutique en ligne a cessé de fonctionner un mardi.
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.
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.
La plupart des entreprises qui ont mis en place un système en ont construit deux, le second étant généralement plus ancien et moins bien documenté que le premier. Une fois le modèle établi, le second système coûte bien moins cher que le premier, car la réflexion sur les opérations essentielles a déjà été menée. Alumio centralise ces connexions, les intégrant à celle-ci, plutôt que de les laisser reposer sur des arrangements privés.
Oui, chaque opération est configurée séparément et s'exécute selon son propre calendrier. Les commandes peuvent devoir être traitées instantanément, tandis que les stocks ne nécessitent qu'un contrôle horaire. Considérer ces deux aspects comme un seul et même système peut transformer une petite modification en un changement majeur. Le terme utilisé est celui défini par l'application ; il convient donc de le vérifier en premier lieu.
Non, et c'est là le point crucial, car l'alternative serait de demander au concepteur de l'étendre. Or, son temps est une ressource précieuse. La correspondance entre les données envoyées par Shopware et celles attendues par l'application relève de la configuration, et le transformateur de code prend le relais lorsque la configuration ne peut plus s'exprimer.
L'application publie les opérations qu'elle prend en charge, et cette liste constitue la réponse. Il s'agit d'un dialogue avec la personne qui la maintient, plutôt que d'un obstacle technique, et la procédure est généralement courte, car le développeur sait précisément ce qu'elle accepte. Une fois cette liste établie, le reste consiste à configurer l'application, et la configuration n'est plus uniquement liée à la mémoire d'une seule personne quant à sa conception.
Ce qui reste caché, c'est un appel qui a abouti sans que rien ne change, car rien ne semble anormal et la commande n'apparaît tout simplement jamais là où on l'attend. Alumio enregistre l'appel et la réponse reçue, permettant ainsi de visualiser une acceptation silencieuse. Chaque échange est surveillé en direct et consigné avec son contenu ; en cas de refus, une alerte est émise avec le motif ; des nouvelles tentatives sont effectuées si la configuration le permet, et rien n'est perdu discrètement.
É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.