Patterns d'integration Salesforce et SAP pour les industriels

Reponse courte : presque toutes les integrations Salesforce et SAP dans l'industrie se ramenent a quatre patterns : synchronisation par lots, appel synchrone, virtualisation des donnees et diffusion d'evenements. Choisissez-en un par objet de donnees, et tranchez sur deux questions seulement : quel systeme est proprietaire de l'enregistrement, et quel niveau d'obsolescence est acceptable. Le middleware decoule de ces reponses, pas l'inverse.

Nous avons tranche cette question sur les donnees de commande, de produit et de service chez des industriels riches en actifs. Les projets qui echouent n'echouent presque jamais a cause du mauvais iPaaS. Ils echouent parce que personne n'a ecrit qui est proprietaire de l'enregistrement.

Qu'est-ce qu'un pattern d'integration Salesforce et SAP ?

Un pattern d'integration est la forme d'un flux de donnees, independamment 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 marche est l'un de ces patterns avec un logo dessus. Choisir le pattern releve de l'architecture. Choisir le produit releve des achats.

Quelles donnees SAP doivent reellement circuler chez un industriel ?

Trois familles couvrent l'essentiel, et elles n'appellent pas le meme traitement.

Les donnees de commande. Les devis et opportunites naissent dans Salesforce, mais SAP devient proprietaire de la commande des sa confirmation. Les commerciaux ont besoin de la quantite confirmee, de la date promise et du statut en retour.
Les donnees produit, prix et stock. SAP detient les donnees de base article, les conditions et le stock. Salesforce est consommateur ici, jamais auteur.
Les donnees de service et d'actifs. La propriete se partage vraiment. SAP detient les numeros de serie, les nomenclatures et les conditions de garantie ; Salesforce detient la requete, le contrat de service et l'intervention terrain.

Ecrivez le proprietaire a cote de chaque objet avant d'evaluer le moindre outil. Si deux systemes peuvent ecrire le meme champ, vous n'avez pas concu une integration. Vous avez concu un conflit avec un planning.

Quels sont les quatre patterns a considerer ?

Synchronisation par lots

Un transfert de masse planifie, en general la nuit. Adapte aux donnees de base article, aux couts et aux realises historiques. Peu couteux, comprehensible, facile a rejouer apres un incident. Le prix : une fraicheur mesuree en heures, et une fenetre nocturne qui se resserre quand le volume grandit.

Appel synchrone

Salesforce appelle SAP et attend la reponse : verification de disponibilite, controle de credit, simulation de prix, soumission de commande. Adapte quand l'utilisateur a besoin de la verite a la seconde pres et qu'une copie serait pire qu'une courte attente. Le prix : la disponibilite de SAP devient celle du CRM.

Virtualisation des donnees

Salesforce Connect expose les donnees SAP en external objects via OData 2.0 ou 4.0, generalement au travers d'une passerelle SAP, de sorte que les enregistrements sont lus en direct et jamais stockes dans Salesforce. Adapte aux donnees de reference de longue traine 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'evenements

SAP publie un changement et Salesforce reagit : livraison confirmee, lot libere, expedition bloquee, actif mis en service. Adapte aux changements d'etat ou les minutes comptent et ou le volume interdit le polling. Le prix : vous prenez en charge l'ordonnancement, les reprises et les doublons.

Comment choisir ? La propriete des donnees et la latence, pas la marque du middleware

Nommez le proprietaire par objet. Un seul auteur, tous les autres lisent. Ecrivez-le dans le document de conception, pas dans la tete de quelqu'un.
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 reel" n'est pas un budget, c'est un souhait.
Comptez le volume honnetement. Les pics, pas les moyennes. Un pattern evenementiel confortable a mille messages par jour se comporte autrement a un million par semaine.
Definissez le comportement en cas de panne avant le scenario nominal. Que voit un commercial quand SAP est indisponible pendant la cloture trimestrielle ? Le silence est la pire reponse possible.

Passez ces quatre etapes et le pattern se choisit souvent tout seul. La plupart des industriels finissent en hybride : lots pour les donnees de base, evenements pour le statut de commande et de livraison, appel synchrone pour les deux ou trois controles qui doivent etre vivants, virtualisation pour l'archive que personne ne veut copier.

Ou les industriels se trompent-ils ?

Tout synchroniser. Chaque champ copie est un champ a reconcilier pour toujours. Copiez ce qu'un processus Salesforce utilise reellement.
Pas de correspondance d'identifiants stable. Rapprocher sur le nom du client ou le libelle article marche en demo et echoue en production. Portez la cle SAP comme external ID.
Une creation de commande non idempotente. Une reprise qui cree une seconde commande dans SAP est le bug le plus couteux de cette categorie. Chaque ecriture a besoin d'une cle de correlation.
Aucun job de reconciliation. La derive n'est pas une eventualite, c'est une certitude. Quelque chose doit compter les deux cotes et publier l'ecart.
Acheter le middleware d'abord. L'outil dicte alors l'architecture, et celle-ci herite de ce que cet outil sait faire.

La marque du middleware compte-t-elle malgre tout ?

Oui, en second. Salesforce propose des integrations MuleSoft Direct pour Manufacturing Cloud qui synchronisent les donnees client, produit et commande avec SAP. Data 360 propose un connecteur SAP HANA dont l'ingestion par lots est generalement disponible tandis que la federation zero copy reste en beta, ce qu'il vaut mieux savoir avant de batir une couche analytique autour. SAP Integration Suite, Boomi et le developpement d'API restent valides. Chacun est un pattern sous forme packagee. Choisissez d'abord le pattern, puis le produit qui l'implemente avec le moins de code a maintenir.

Le gain est operationnel, pas cosmetique. Sur un programme d'actifs connectes pour ASSA ABLOY, nous sommes passes de 3 000 a 350 requetes par semaine, une reduction de 93% sur 11 000 appareils et jusqu'a 2,5 millions d'evenements par semaine, sans ajouter de personnel support. C'etait possible parce que le volume d'evenements etait route par pattern plutot que pousse dans une synchronisation generique. Tekunda integre Salesforce avec plus de 70 systemes d'entreprise, SAP compris, en tant que SI, ISV et PDO Salesforce certifie.

FAQ

Salesforce ou SAP doit-il etre proprietaire de la commande de vente ?

SAP, a partir de la confirmation. Salesforce doit posseder le devis et l'opportunite puis relire le statut de la commande, afin qu'il existe un seul endroit ou vit une commande confirmee.

Le temps reel est-il toujours preferable ?

Non. Le temps reel augmente le cout, le couplage et la surface de panne. Reservez-le aux cas ou une valeur obsolete provoquerait un engagement errone envers un client, et utilisez le lot partout ailleurs.

Faut-il MuleSoft pour integrer Salesforce et SAP ?

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

Combien de temps prend une integration Salesforce et SAP ?

Cela depend bien plus du nombre d'objets synchronises que de l'outillage. Deux ou trois objets bien attribues peuvent partir en production en quelques semaines ; un modele de propriete non tranche peut bloquer un projet un an.