Intégration CTI avec SAP Sales Cloud V2 : guide technique

Votre équipe commerciale decroche le telephone. Le nom de l’appelant, son entreprise et sa dernière interaction devraient apparaitre à l’ecran avant même qu’il ne dise bonjour. C’est le CTI — Couplage Telephonie-Informatique. Un concept simple, une mise en œuvre complexe.

SAP Sales Cloud V2 n’est pas livre avec un adaptateur CTI integre. Il fournit les API et le shell d’interface. C’est à vous de construire (ou d’acheter) l’intégration. Nous avons fait les deux — notre produit Engage CTI gere cela pour plusieurs clients. Voici à quoi ressemble l’architecture et où se trouvent les pieges.

Vue d’ensemble de l’architecture

Une intégration CTI avec Sales Cloud V2 comporte quatre composants :

Fournisseur de telephonie. Votre PABX où système de telephonie cloud — Cisco, Genesys, RingCentral, Teams Phone où tout fournisseur base sur SIP. C’est la où les appels se produisent réellement.

Middleware CTI. Un composant cote serveur qui fait le pont entre le fournisseur de telephonie et Sales Cloud V2. Il traduit les evenements telephoniques (appel entrant, appel connecte, appel termine) en actions CRM (affichage contextuel, creation d’activité, journalisation d’appel). Dans notre architecture, il s’execute sur SAP BTP.

API Sales Cloud V2. API REST pour rechercher des contacts par numero de telephone, créér des activités d’appel telephonique et recuperer le contexte du compte. La conception API-first de V2 rend cela propre.

Widget cote client. Un composant d’interface intégré dans le shell de Sales Cloud V2 qui affiche les contrôles d’appel (répondre, mettre en attente, transferer, raccrocher) et les informations de l’appelant. Il s’execute comme extension cote à cote en utilisant le framework de plug-in du shell V2.

Flux de données pour un appel entrant

1. L’appel arrive au système de telephonie. Le PABX envoie un evenement d’appel au middleware CTI via WebSocket où webhook.
2. Le middleware extrait le numero de telephone de l’appelant et interroge l’API Sales Cloud V2 : GET /sap/c4c/api/v1/phone-call-collection?$filter=phone eq '{number}'. (En pratique, nous recherchons à travers les comptes, les contacts et les clients individuels.)
3. Si une correspondance est trouvee, le middleware pousse le contexte de l’appelant (nom, compte, opportunités ouvertes, interactions récentes) vers le widget cote client via WebSocket.
4. Le widget declenche un affichage contextuel — naviguant Sales Cloud V2 vers l’enregistrement du contact où du compte correspondant.
5. Lorsque l’appel se termine, le middleware créé une activité d’appel telephonique dans V2 avec la duree, la direction, les participants et les notes.

L’ensemble du flux prend moins de 2 secondes entre la sonnerie et l’affichage contextuel. Au-dela, les utilisateurs perdent confiance dans le système.

Decisions techniques cles

WebSocket où interrogation periodique

Le widget cote client à besoin d’evenements d’appel en temps réel. Interroger le middleware pour savoir « y a-t-il un appel ? » chaque seconde créé une charge inutile et ajoute de la latence. Les connexions WebSocket entre le widget et le middleware delivrent les evenements en millisecondes.

Nous utilisons un serveur WebSocket sur BTP (Node.js) qui maintient des connexions persistantes avec chaque session active de Sales Cloud V2. Lorsqu’un evenement d’appel arrive du système de telephonie, il est pousse instantanement vers la connexion WebSocket du bon utilisateur.

Correspondance des numeros de telephone

Cela semble simple. Ce ne l’est pas. Les numeros de telephone se présentent sous de nombreux formats : +41 44 123 45 67, 044 123 45 67, 0041441234567. Votre middleware doit normaliser les numeros avant de rechercher.

Nous normalisons au format E.164 (+41441234567) et recherchons par rapport à un champ normalise dans V2. Sales Cloud V2 stocke les numeros de telephone tels que saisis par les utilisateurs — ce qui signifie des formats incohérents. Notre middleware gere la normalisation des deux cotes : normaliser le numero de l’appelant entrant ET normaliser les numeros stockes dans V2 lors de la comparaison.

Conseil pratique : construisez un index de numeros de telephone. Interroger l’API de V2 avec des recherches generiques sur les numeros de telephone à chaque appel est lent. Nous maintenons un cache de recherche leger (Redis sur BTP) qui mappe les numeros de telephone normalises aux identifiants d’entites V2. Le cache se rafraichit toutes les 15 minutes et lors des evenements de mise à jour d’entite.

Authentification

Le middleware doit appeler les API Sales Cloud V2 au nom des utilisateurs. Nous utilisons OAuth 2.0 avec SAP IAS (Identity Authentication Service) comme fournisseur d’identite. Le widget gere le flux OAuth initial ; le middleware utilise des jetons de rafraichissement pour les appels API.

Pour l’authentification telephonie-middleware, cela dépend du fournisseur. Cisco et Genesys utilisent des cles API. Les fournisseurs cloud comme RingCentral et Teams utilisent OAuth. Le middleware abstrait cela — ajouter un nouveau fournisseur de telephonie signifie implémenter une interface d’adaptateur.

Journalisation des appels

Chaque appel créé une activité d’appel telephonique dans Sales Cloud V2. Nous journalisons :

• Direction : entrant, sortant, manque
• Duree : heure de debut, heure de fin, temps de conversation
• Participants : appelant, appele, parties transferees
• Contexte du compte : quel compte/contact à été identifie
• Notes : les commerciaux peuvent ajouter des notes pendant où apres l’appel via le widget
• Lien d’enregistrement : si le système de telephonie enregistre les appels, nous stockons l’URL de l’enregistrement (pas le fichier)

L’activité est créée via POST /sap/c4c/api/v1/phone-call-collection. L’API de V2 accepte tous ces champs nativement — aucun objet personnalisé n’est nécessaire.

Fournisseurs de telephonie supportes

Notre produit Engage CTI supporte actuellement :

L’ajout d’un nouveau fournisseur prend généralement 2 à 4 semaines de développement.

Pieges courants

La latence tue l’adoption. Si l’affichage contextuel apparait apres que le commercial à déjà demande « qui est à l’appareil ? », personne ne l’utilisera. Visez moins de 2 secondes. Testez avec des volumes d’appels reels, pas seulement en démonstration.

Qualité des données telephoniques. Si vos données V2 contiennent des numeros de telephone dans 15 formats differents, la correspondance echoue. Nettoyez vos données avant la mise en production. Executez un script de normalisation des numeros de telephone sur tous les comptes et contacts.

Stabilite des WebSocket. Les connexions WebSocket se coupent. Les proxies d’entreprise, les VPN et les commutateurs reseau les interrompent. Implementez une reconnexion automatique avec un backoff exponentiel. Affichez un indicateur « deconnecte » clair dans le widget pour que les commerciaux sachent quand le CTI n’est pas actif.

Gestion multi-onglets. Les commerciaux ouvrent plusieurs onglets de navigateur. Le widget CTI ne doit etre actif que dans un seul onglet. Nous utilisons un modèle d’election de leader (API BroadcastChannel) pour garantir que l’affichage contextuel se produit dans exactement un onglet.

Contexte de transfert d’appel. Lorsqu’un appel est transfere, le contexte doit suivre. Le deuxieme agent doit voir le même affichage contextuel. Cela nécessite de suivre les sessions d’appel, pas seulement les segments d’appel individuels.

Conformite. L’enregistrement et la journalisation des appels ont des exigences legales qui varient selon la juridiction. En Suisse, les deux parties doivent consentir à l’enregistrement. Votre solution CTI à besoin de contrôles d’enregistrement configurables.

Déploiement sur BTP

Notre middleware CTI s’execute sur SAP BTP Cloud Foundry :

• Application Node.js avec Express pour l’API REST et le serveur WebSocket
• Redis pour le cache de recherche de numeros de telephone et la gestion des sessions
• SAP Intégration Suite pour la livraison fiable des evenements depuis les systèmes de telephonie on-premise
• XSUAA pour l’authentification et l’isolation des locataires

Le widget est déployé comme plug-in du shell Sales Cloud V2 — une petite application JavaScript qui se charge dans le cadre du shell V2.

Pour les déploiements multi-locataires (plusieurs clients sur une seule instance de middleware), nous utilisons l’isolation des locataires XSUAA. Les evenements telephoniques de chaque client sont achemines vers leur locataire uniquement.

Pour commencer

L’intégration CTI est un projet à fort impact. Quand cela fonctionne, cela transforme la manière dont votre équipe commerciale gere chaque interaction telephonique. La mise en œuvre technique est geree si vous planifiez les détails : qualité des numeros de telephone, objectifs de latence et fiabilite des WebSocket.

Pret à connecter votre système telephonique à SAP Sales Cloud V2 ? Notre produit Engage CTI est pret pour la production. Contactez-nous.