Quand on cherche à connecter Business Central et Magento, les options ne manquent pas : Logic Apps, Power Automate, middleware ESB, connecteurs AppSource, ou code maison. Sur la dizaine d’intégrations que nous avons livrées ces deux dernières années, Azure Functions est devenu notre choix par défaut pour les volumes PME (jusqu’à ~5'000 commandes / mois). Voici pourquoi, et comment nous structurons le code.

Pourquoi Azure Functions plutôt qu’autre chose

Versus Logic Apps

Logic Apps est séduisant côté drag-and-drop : un connecteur Magento, un connecteur BC, des cartes de transformation visuelles. En pratique :

• Le connecteur Magento officiel ne couvre pas tous les flux dont on a besoin (stocks multi-sources, attributs personnalisés, configurable products) — on retombe vite sur des appels HTTP custom.
• La debuggabilité est faible : un workflow qui échoue produit une trace JSON difficile à lire en astreinte un dimanche soir.
• Le coût explose avec le volume : facturé à l’action, on dépasse rapidement le coût d’un App Service Plan dédié.

Logic Apps reste pertinent pour un POC ou un client qui veut maintenir les flux lui-même, sans développeur. Pour une PME en production sérieuse, nous préférons coder.

Versus Power Automate

Même logique que Logic Apps, en plus restreint côté gouvernance et versioning. À éviter pour des flux critiques.

Versus un middleware ESB (BizTalk, MuleSoft)

Sur-dimensionné pour une PME romande typique. Coût de licence, courbe d’apprentissage, et personne dans l’équipe interne ne saura reprendre la main. À garder pour les groupes multi-sites avec une vraie équipe intégration.

Versus du code C# / Node hébergé sur un VPS

C’est ce que la plupart des intégrateurs font encore. Ça marche, mais vous payez un serveur 24/7 pour traiter des évènements qui arrivent par salves. Et vous gérez vous-même le scaling, les retries, la supervision.

Azure Functions = vous codez le métier, Microsoft gère le reste.

L’architecture qu’on déploie

Magento ──webhook──▶ HTTP Function ──▶ Service Bus ──▶ Queue Function ──▶ Business Central
                                                                              │
Business Central ──webhook──▶ HTTP Function ──▶ Service Bus ──▶ Queue Function ──▶ Magento

Trois principes :

1. Découpler la réception et le traitement via Azure Service Bus. Le webhook répond en < 100 ms, le traitement métier prend son temps.
2. Une queue par direction × par domaine : mag-to-bc-orders, mag-to-bc-customers, bc-to-mag-stocks, bc-to-mag-prices. Ça permet de paralléliser et d’isoler les pannes.
3. Idempotence : chaque message porte un identifiant métier (n° de commande Magento, n° de produit BC). Le handler vérifie d’abord si l’objet existe déjà côté cible.

Quelques détails techniques

Authentification Business Central

Depuis BC SaaS, l’authentification se fait via Microsoft Entra ID (ex-Azure AD) avec le flow Client Credentials :

var token = await _confidentialClientApp
    .AcquireTokenForClient(new[] { "https://api.businesscentral.dynamics.com/.default" })
    .ExecuteAsync();

Côté BC, créer une Entra Application dans la page Microsoft Entra Applications, lui assigner le permission set D365 EXTENSION MGT (ou plus restreint selon vos APIs custom), et stocker le client_id / tenant_id / client_secret dans Azure Key Vault — jamais dans local.settings.json.

Authentification Magento

Magento 2 propose deux mécanismes :

• Token d’intégration : simple, créé manuellement dans le back-office, valide jusqu’à révocation. Adapté aux Functions.
• OAuth 1.0a : plus orthodoxe mais lourd. À réserver aux intégrations distribuées à plusieurs partenaires.

Pour un usage Function ↔ Magento dédié, le token d’intégration suffit. Stocké dans Key Vault, accédé via Managed Identity.

Gestion des erreurs

Le pattern qui sauve nos astreintes :

[Function("HandleMagentoOrder")]
public async Task Run(
    [ServiceBusTrigger("mag-to-bc-orders", Connection = "ServiceBus")]
    ServiceBusReceivedMessage message,
    ServiceBusMessageActions actions)
{
    try {
        var order = JsonSerializer.Deserialize<MagentoOrder>(message.Body);
        await _bcClient.UpsertSalesOrder(order);
        await actions.CompleteMessageAsync(message);
    }
    catch (BusinessCentralValidationException ex) {
        // erreur métier (ex: client introuvable) → dead-letter explicite
        await actions.DeadLetterMessageAsync(message,
            propertiesToModify: null,
            deadLetterReason: "BC_VALIDATION",
            deadLetterErrorDescription: ex.Message);
    }
    catch (Exception ex) {
        // erreur transitoire → retry automatique du Service Bus
        _logger.LogError(ex, "Failed to process order {OrderId}", message.MessageId);
        throw;
    }
}

Trois catégories d’erreurs, trois traitements :

• Erreur transitoire (réseau, timeout, 503) → on throw et on laisse le Service Bus retry (jusqu’à 10 fois par défaut, exponentiel).
• Erreur métier (donnée invalide, référence manquante) → dead-letter immédiat avec la raison. Une autre Function lit la dead-letter queue et notifie l’équipe via Teams ou email.
• Erreur de notre code (bug) → dead-letter, alerte Application Insights, à corriger.

Idempotence côté Business Central

Pour ne pas créer deux fois la même Sales Order, on stocke le magento_order_id dans un champ custom de la table BC (table extension) et on fait un upsert :

procedure UpsertFromMagento(MagentoOrderId: Text): Code[20]
var
    SalesHeader: Record "Sales Header";
begin
    SalesHeader.SetRange("Magento Order Id", MagentoOrderId);
    if SalesHeader.FindFirst() then
        exit(SalesHeader."No.");
    // sinon, création
    SalesHeader.Init();
    SalesHeader."Magento Order Id" := MagentoOrderId;
    // ...
    SalesHeader.Insert(true);
    exit(SalesHeader."No.");
end;

Combien ça coûte

Pour une PME qui fait passer 3'000 commandes / mois et synchronise les stocks toutes les 5 minutes :

• Functions (plan Consumption) : ~ CHF 5 / mois.
• Service Bus (Standard) : CHF 10 / mois.
• Application Insights : CHF 5 / mois (logs raisonnables).
• Key Vault : < CHF 1 / mois.

Total : moins de CHF 25 / mois pour l’infrastructure d’intégration. Comparez à un VPS dédié + le temps de maintenance.

Quand Azure Functions n’est PAS la bonne réponse

• Volumétrie > 50'000 commandes / jour : passez à Functions sur App Service Plan dédié (cold-start gênant en Consumption), ou à un middleware avec batch processing.
• Transformations très complexes entre formats (EDI, multi-pays) : un vrai outil d’intégration (Logic Apps, BizTalk, MuleSoft) sera plus productif.
• Équipe interne sans aucun développeur .NET : Functions deviendra difficile à reprendre. Préférez Logic Apps ou un connecteur AppSource packagé.

Pour aller plus loin

Vous voulez voir une de nos intégrations en démo, ou parler de votre propre projet Magento ↔ Business Central ? Écrivez-nous.

Et si vous démarrez sur Business Central, jetez d’abord un œil à notre page démonstration Business Central — un essai gratuit Microsoft, complété par une démo personnalisée si vous voulez voir le produit avec vos propres données.