Patterns d'intégration Salesforce et SAP pour les industriels

Réponse courte : presque toutes les intégrations Salesforce et SAP dans l'industrie se ramènent à quatre patterns : synchronisation par lots, appel synchrone, virtualisation des données et diffusion d'événements. Choisissez-en un par objet de données, et tranchez sur deux questions seulement : quel système est propriétaire de l'enregistrement, et quel niveau d'obsolescence est acceptable. Le middleware découle de ces réponses, pas l'inverse.

Nous avons tranché cette question sur les données de commande, de produit et de service chez des industriels riches en actifs. Les projets qui échouent n'échouent presque jamais à cause du mauvais iPaaS. Ils échouent parce que personne n'a écrit qui est propriétaire de l'enregistrement.

Qu'est-ce qu'un pattern d'intégration Salesforce et SAP ?

Un pattern d'intégration est la forme d'un flux de données, indépendamment de l'outil qui le porte. Les recommandations d'architecture de Salesforce en nomment un petit nombre : batch data synchronization, remote process invocation (request and reply, ou fire and forget), remote call-in, UI update based on data changes et data virtualization. Chaque connecteur, adaptateur et iPaaS du marché est l'un de ces patterns avec un logo dessus. Choisir le pattern relève de l'architecture. Choisir le produit relève des achats.

Quelles données SAP doivent réellement circuler chez un industriel ?

Trois familles couvrent l'essentiel, et elles n'appellent pas le même traitement.

• Les données de commande. Les devis et opportunités naissent dans Salesforce, mais SAP devient propriétaire de la commande dès sa confirmation. Les commerciaux ont besoin de la quantité confirmée, de la date promise et du statut en retour.
• Les données produit, prix et stock. SAP détient les données de base article, les conditions et le stock. Salesforce est consommateur ici, jamais auteur.
• Les données de service et d'actifs. La propriété se partage vraiment. SAP détient les numéros de série, les nomenclatures et les conditions de garantie ; Salesforce détient la requête, le contrat de service et l'intervention terrain.

Écrivez le propriétaire à côté de chaque objet avant d'évaluer le moindre outil. Si deux systèmes peuvent écrire le même champ, vous n'avez pas conçu une intégration. Vous avez conçu un conflit avec un planning.

Quels sont les quatre patterns à considérer ?

Synchronisation par lots

Un transfert de masse planifié, en général la nuit. Adapté aux données de base article, aux coûts et aux réalisés historiques. Peu coûteux, compréhensible, facile à rejouer après un incident. Le prix : une fraîcheur mesurée en heures, et une fenêtre nocturne qui se resserre quand le volume grandit.

Appel synchrone

Salesforce appelle SAP et attend la réponse : vérification de disponibilité, contrôle de crédit, simulation de prix, soumission de commande. Adapté quand l'utilisateur a besoin de la vérité à la seconde près et qu'une copie serait pire qu'une courte attente. Le prix : la disponibilité de SAP devient celle du CRM.

Virtualisation des données

Salesforce Connect expose les données SAP en external objects via OData 2.0 ou 4.0, généralement au travers d'une passerelle SAP, de sorte que les enregistrements sont lus en direct et jamais stockés dans Salesforce. Adapté aux données de référence de longue traîne que l'on consulte mais sur lesquelles personne ne fait de reporting : anciennes factures, bons de livraison, ordres de service clos. Le prix : reporting faible, automatisation faible, rien hors ligne.

Diffusion d'événements

SAP publie un changement et Salesforce réagit : livraison confirmée, lot libéré, expédition bloquée, actif mis en service. Adapté aux changements d'état où les minutes comptent et où le volume interdit le polling. Le prix : vous prenez en charge l'ordonnancement, les reprises et les doublons.

Comment choisir ? La propriété des données et la latence, pas la marque du middleware

1. Nommez le propriétaire par objet. Un seul auteur, tous les autres lisent. Écrivez-le dans le document de conception, pas dans la tête de quelqu'un.
2. Fixez un budget de latence en langage clair. "Un commercial ne doit jamais promettre une date que l'usine ne peut pas tenir" est un budget. "Temps réel" n'est pas un budget, c'est un souhait.
3. Comptez le volume honnêtement. Les pics, pas les moyennes. Un pattern événementiel confortable à mille messages par jour se comporte autrement à un million par semaine.
4. Définissez le comportement en cas de panne avant le scénario nominal. Que voit un commercial quand SAP est indisponible pendant la clôture trimestrielle ? Le silence est la pire réponse possible.

Passez ces quatre étapes et le pattern se choisit souvent tout seul. La plupart des industriels finissent en hybride : lots pour les données de base, événements pour le statut de commande et de livraison, appel synchrone pour les deux ou trois contrôles qui doivent être vivants, virtualisation pour l'archive que personne ne veut copier.

Où les industriels se trompent-ils ?

• Tout synchroniser. Chaque champ copie est un champ à réconcilier pour toujours. Copiez ce qu'un processus Salesforce utilise réellement.
• Pas de correspondance d'identifiants stable. Rapprocher sur le nom du client ou le libellé article marche en démo et échoue en production. Portez la clé SAP comme external ID.
• Une création de commande non idempotente. Une reprise qui crée une seconde commande dans SAP est le bug le plus coûteux de cette catégorie. Chaque écriture a besoin d'une clé de corrélation.
• Aucun job de réconciliation. La dérive n'est pas une éventualité, c'est une certitude. Quelque chose doit compter les deux côtés et publier l'écart.
• Acheter le middleware d'abord. L'outil dicte alors l'architecture, et celle-ci hérite de ce que cet outil sait faire.

La marque du middleware compte-t-elle malgré tout ?

Oui, en second. Salesforce propose des intégrations MuleSoft Direct pour Manufacturing Cloud qui synchronisent les données client, produit et commande avec SAP. Data 360 propose un connecteur SAP HANA dont l'ingestion par lots est généralement disponible tandis que la fédération zéro copy reste en bêta, ce qu'il vaut mieux savoir avant de bâtir une couche analytique autour. SAP Integration Suite, Boomi et le développement d'API restent valides. Chacun est un pattern sous forme packagée. Choisissez d'abord le pattern, puis le produit qui l'implémente avec le moins de code à maintenir.

Le gain est opérationnel, pas cosmétique. Sur un programme d'actifs connectés pour ASSA ABLOY, nous sommes passés de 3 000 à 350 requêtes par semaine, une réduction de 93% sur 11 000 appareils et jusqu'à 2,5 millions d'événements par semaine, sans ajouter de personnel support. C'était possible parce que le volume d'événements était routé par pattern plutôt que poussé dans une synchronisation générique. Tekunda intègre Salesforce avec plus de 70 systèmes d'entreprise, SAP compris, en tant que SI, ISV et PDO Salesforce certifié.

FAQ

Salesforce ou SAP doit-il être propriétaire de la commande de vente ?

SAP, à partir de la confirmation. Salesforce doit posséder le devis et l'opportunité puis relire le statut de la commande, afin qu'il existe un seul endroit où vit une commande confirmée.

Le temps réel est-il toujours préférable ?

Non. Le temps réel augmente le coût, le couplage et la surface de panne. Réservez-le aux cas où une valeur obsolète provoquerait un engagement erroné envers un client, et utilisez le lot partout ailleurs.

Faut-il MuleSoft pour intégrer Salesforce et SAP ?

Non. MuleSoft convient bien aux programmes API-led avec de nombreux consommateurs, mais les mêmes patterns fonctionnent sur SAP Integration Suite, d'autres iPaaS ou du développement d'API direct.

Combien de temps prend une intégration Salesforce et SAP ?

Cela dépend bien plus du nombre d'objets synchronisés que de l'outillage. Deux ou trois objets bien attribués peuvent partir en production en quelques semaines ; un modèle de propriété non tranché peut bloquer un projet un an.