Steve Trucking, ce que j'architecturerais

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 6 sur 6 du chapitre Données maîtres et identité, chapitre 6 du cours Data Architect, et la fin de la partie 1. Précédent : Quand l’autorité est partagée · Suivant : la partie 2 commence avec Concevoir pour le volume (coming soon)

La question à laquelle répond ce point de contrôle : savez-vous assembler la partie 1 sur un scénario réel ?

Essayez d’abord le défi. Ceci est mon parcours commenté du défi du point de contrôle 1. Si vous n’avez pas encore dessiné votre propre conception, faites-le avant de continuer. La valeur est dans la comparaison de votre raisonnement avec le mien, pas dans la lecture de la réponse.

Voici « Ce que j’architecturerais » : une solution viable possible, pas la réponse, avec les compromis nommés et mes positions prises. Nous n’avons pas encore couvert les gros volumes de données, la conception des requêtes, les modèles d’intégration, la migration ni les transactions, et c’est voulu : l’architecture se développe à mesure que vous en apprenez davantage. Mais la partie 1 nous donne assez pour poser l’ossature.

Commencez par les chiffres

D’après le dossier : environ 3 300 livraisons par jour ouvré, un million par an, en hausse de 30 % par an. Environ 1,6 article par livraison (1,6 million par an) ; environ huit changements de statut par livraison (8 millions par an) ; quatre à cinq millions de photos par an ; environ 200 000 relevés GPS par jour ; environ 180 000 requêtes par an ; trois partenaires distributeurs qui envoient leurs manifestes de trois façons différentes ; neuf centres de distribution ; 330 camions avec des équipes de deux personnes. Et Steve Trucking a déjà une organisation Salesforce avec Service Cloud, Field Service et un portail partenaire. Comptez les zéros avant de dessiner la moindre boîte. Ils trancheront plusieurs points ci-dessous.

Le cœur des livraisons : regardez le vaisseau mère

Les livraisons sont le cœur de l’affaire, et Field Service fait déjà la répartition. Je commence donc par le modèle standard de Field Service, comme l’a fait l’extrait du chapitre 3 :

Concept métier	Objet Salesforce	Pourquoi
Partenaire distributeur	Account (type d’enregistrement Retail Partner)	Une entreprise avec laquelle Steve Trucking a un contrat ; porte les contrats, les requêtes et l’accès au portail
Personnel des partenaires (responsables de centre, personnel des magasins)	Contact	Les utilisateurs du portail doivent être des contacts
Une livraison : un destinataire, une adresse, une commande partenaire, un jour	Work Order	L’unité de travail de Field Service ; la planification, l’application mobile et les rapports de service s’y rattachent
Chaque article ou service : le réfrigérateur, l’installation, l’enlèvement	Work Order Line Item	Découpe le travail, pilote les listes de contrôle et la facturation
Le type d’arrêt : livraison seule, avec installation, avec enlèvement	Work Type	Fixe la durée, les compétences et la liste de contrôle d’installation
La visite planifiée et son créneau	Service Appointment	Ce que Field Service planifie et ce qu’affiche l’application de l’équipe
Équipes et camions ; zones de répartition des centres	Service Resource, Service Crew, Service Territory	Field Service planifie une équipe comme une seule ressource
Demandes des destinataires, réclamations des partenaires	Case	La console de service, les droits, le courriel vers requête
La liste du partenaire pour mardi au centre de Phoenix	Manifest__c (personnalisé)	Rien de standard ne représente l’unité de réception, de rapprochement et de rejeu

Tout le reste reste standard. Résister à davantage d’objets personnalisés est délibéré : la question du chapitre 1 était de savoir quand un architecte doit résister à un objet de plus, et ici la réponse est « presque toujours ». La ligne de commande du partenaire, par exemple, n’est pas un nouvel objet. C’est l’ordre d’exécution (Work Order), identifié par la référence du partenaire.

Click to enlarge

Il prolonge le schéma final du chapitre 3 (Concevoir le modèle physique Salesforce) : les mêmes objets aux mêmes places, avec l’équipe, la zone de répartition, la requête et ce que le point de contrôle 1 garde hors du cœur en plus.

La clé qui rapproche la commande d’un partenaire d’une livraison

Chaque ligne de manifeste devient un ordre d’exécution, lié à son manifeste. La clé est la question à laquelle je tiens le plus : comment savons-nous que cette ligne du partenaire est cette livraison-là ? Ma réponse : un ID externe sur l’ordre d’exécution construit à partir du partenaire distributeur et de la référence de commande et de livraison propre au partenaire (quelque chose comme KEYSTONE-PHX-8843119-1), marqué unique. Un champ par source, en un-à-un. C’est l’identifiant du partenaire, pas le nôtre : les « plusieurs identifiants pour une même chose » du chapitre 2, et le « le partenaire possède sa référence de commande » du module 1.

Pourquoi c’est important : les manifestes arrivent un à deux jours à l’avance et sont révisés le jour même. Avec cette clé, chaque manifeste renvoyé ou révisé fait un upsert au lieu de créer des doublons. La révision met à jour l’ordre d’exécution, un champ la consigne, et un changement sur une livraison déjà affectée à une tournée alerte le coordinateur : le changement du partenaire est appliqué, mais signalé jusqu’à ce que la répartition le confirme. C’est aussi ce qui change par rapport à l’image du chapitre 4. Aujourd’hui, chaque manifeste atterrit dans RouteDesk, et les coordinateurs ressaisissent les tournées dans Salesforce, puis les arrêts terminés dans l’autre sens. Dans cette conception, les manifestes arrivent directement dans Salesforce, en upsert par la clé du partenaire ; RouteDesk est retiré, et la ressaisie s’arrête. Le chapitre sur l’intégration conçoit les trois formats entrants. La décision de données, c’est la clé.

Le destinataire : compte personnel, contact, ou ni l’un ni l’autre ?

C’est la décision de données la plus intéressante de la partie 1, alors voici les options, puis mon choix.

Option A : les comptes personnels. Chaque destinataire devient un compte personnel, lié à chaque livraison. Pour : standard, fonctionne naturellement avec Service Cloud, la messagerie et la console, reconnaît les destinataires récurrents. Contre : environ un million de nouveaux destinataires par an, chacun un compte personnel pesant environ deux fois le stockage d’un compte professionnel (Estimated Record Size by Object Type (opens in a new tab), en anglais), donc en deux ans l’un des plus gros objets de l’organisation. Et les destinataires ne sont pas les clients de Steve Trucking. Ce sont les clients de chaque partenaire distributeur, et Steve Trucking ne doit jamais mélanger le client d’un partenaire avec celui d’un autre (S2).

Option B : des contacts sous le compte du partenaire distributeur. Contre : un million de contacts sous trois ou quatre comptes, c’est un déséquilibre parent-enfant à une échelle massive, bien au-delà de la recommandation de Salesforce d’environ 10 000 enfants par parent (Considerations for Object Relationships (opens in a new tab) ; Parent-Child Data Skew (opens in a new tab), en anglais). C’est l’option à montrer, puis à rejeter.

Option C : le destinataire vit sur la livraison. Le nom, le téléphone, le courriel, l’adresse et les notes de livraison du destinataire sont des champs de l’ordre d’exécution (les champs d’adresse y sont déjà standard), saisis à partir du manifeste. Pour : pas de nouvel objet volumineux ; les données vivent exactement aussi longtemps que la livraison en a besoin ; la suppression se fait par livraison, selon le calendrier du partenaire ; et l’isolement entre partenaires est gratuit, car chaque livraison appartient à un seul partenaire. Contre : un destinataire récurrent n’est pas reconnu comme la même personne.

C’est l’équilibre à trouver. Aura-t-on un jour besoin de reconnaître plusieurs livraisons comme étant la même personne, au même endroit ? De donner une connexion à cette personne ? C’est la ligne de partage entre un destinataire qui a besoin de son propre enregistrement et des informations de destinataire qui sont simplement des données sur la livraison. Et il existe une voie médiane. Portez l’ID client du partenaire distributeur lui-même comme champ sur la livraison, un ID client du partenaire distributeur (Retail Partner Customer ID). Il ne crée pas d’enregistrement de destinataire, mais il relie les livraisons qu’un partenaire envoie pour un même client, ce qui est le début d’une expérience client plus unifiée, et il ramène directement au système du partenaire distributeur, là où ce client vit vraiment. C’est leur identifiant, donc il n’a de sens qu’avec le partenaire : le client 4417 d’un partenaire n’a rien à voir avec celui d’un autre.

À mon avis de professionnel, l’option C est le bon choix. La non-reconnaissance est acceptable, et même souhaitable : Steve Trucking n’a aucune relation avec ces personnes au-delà de la livraison. C’est de nouveau le module 1 : le destinataire est le client du partenaire, et le partenaire fait autorité sur qui il est. Et c’est le chapitre 5 : des données personnelles qui atterrissent à un seul endroit, liées à une seule livraison, sont bien plus faciles à protéger, conserver et supprimer. Et cela tient face aux formes normales du chapitre 2 : les informations du destinataire sont en un-à-un avec la livraison, donc elles lui appartiennent. Un enfant Destinataire séparé économiserait quelques valeurs répétées au prix d’un objet de plus, d’une relation de plus et de leur surcoût, et la seule façon d’économiser davantage serait de traiter la même personne comme une seule à travers les partenaires distributeurs, ce que nous ne ferons pas. La livraison porte donc le destinataire, avec l’ID client du partenaire distributeur comme chemin de retour vers le propre système du partenaire.

Click to enlarge

Unifierais-je les destinataires entre partenaires ?

John Smith, 123 Main Street, apparaît dans le manifeste de Redrock et dans celui de Brightwave. Probablement la même personne. Steve Trucking doit-il les unifier ? Non, délibérément non. Unifier les destinataires entre partenaires distributeurs enfreindrait S2 : un partenaire ne doit jamais voir les destinataires d’un autre, et une identité unifiée est exactement la passerelle par laquelle cela fuit. C’est la position de ce chapitre appliquée : sous-rapprochez là où mélanger coûte cher, et ici, mélanger coûte très cher.

Si un partenaire distributeur veut plus tard reconnaître les destinataires récurrents au sein de ses propres livraisons, c’est un travail pour un outil de résolution d’identité, comme celui de Data 360, limité à ce partenaire : une carte de type registre, pas un compte personnel, et jamais entre partenaires. Une carte de qui est qui n’accorde pas la propriété, et elle n’accorde pas l’accès.

Ce qui reste dans l’organisation, et ce qui n’y reste pas

Le chapitre 3 demandait où les données doivent vivre. Ici, ce sont les zéros qui répondent :

• Le statut actuel vit sur le rendez-vous de service et l’ordre d’exécution. L’historique des changements de statut, environ 8 millions par an et en hausse, n’a pas besoin de vivre dans l’organisation principale. Chaque changement est publié comme un événement et conservé dans l’entrepôt de données, Snowflake. L’organisation garde l’état actuel ; l’historique reste disponible pour le service, les opérations et l’analytique, simplement pas dans la base de données opérationnelle.
• Les photos (quatre à cinq millions par an, dont certaines montrent des personnes ou l’intérieur d’un domicile) vivent hors du cœur dans un stockage conçu pour ce volume, téléversées directement depuis l’application de l’équipe. L’organisation ne garde que ce dont elle a besoin : un petit enregistrement d’index par photo, ou seulement un nombre et un indicateur « photos d’installation obligatoires complètes ». Ma préférence va à l’option la plus légère : garder l’organisation légère, et laisser le stockage des photos posséder son index et sa conservation.
• Les relevés GPS (200 000 par jour) restent dans FleetLink et vont dans Snowflake ; l’organisation n’a besoin que de la dernière position pour la page de suivi et la carte du répartiteur.
• Les huit ans d’historique de RouteDesk (environ 5 millions de livraisons) vont dans l’entrepôt de données ou une archive, accessibles pour les réclamations. Ce qui, le cas échéant, entre dans l’organisation est une décision de migration pour la partie 2.

Click to enlarge

Point de contrôle 1 : ce que j’architecturerais. Les mêmes places que le paysage du chapitre 4 (Le paysage de Steve Trucking), sans la ressaisie ni le tableur.

Qui voit quoi, et qui a besoin d’une licence

• Les partenaires distributeurs ne voient que leurs propres livraisons (S2). Chaque ordre d’exécution porte son partenaire distributeur ; les utilisateurs du portail voient les livraisons de leur partenaire, et les responsables de centre seulement celles de leur centre.
• Les utilisateurs partenaires ont besoin d’une licence de portail qui prend en charge les règles de partage et les rôles : Customer Community Plus ou Partner Community. Les places du stade du chapitre 3 : les places les moins chères n’ont pas le partage dont cette conception a besoin. Les deux licences ont besoin de rôles pour les utilisateurs externes, et Salesforce prévient que plus de rôles ralentissent l’organisation (Experience Cloud User Licenses (opens in a new tab), en anglais). Un rôle par partenaire et par centre de distribution, ça va ; un rôle pour chaque magasin, non.

À savoir pour l’examen. Sachez quelles licences externes ont le partage standard : Customer Community Plus et Partner Community (avec des rôles pour les utilisateurs externes), pas Customer Community, qui utilise des ensembles de partage.

• Les destinataires n’ont besoin d’aucune licence. La page de suivi montre une livraison par un lien avec un jeton qui expire (S3), pas par une connexion.
• Surveillez le déséquilibre. Des centaines de milliers d’ordres d’exécution par an qui pointent vers trois ou quatre comptes partenaires, c’est un déséquilibre de données sur les comptes. Une option est un compte enfant par centre de distribution sous chaque partenaire, ce qui répartit les enfants sur neuf branches ou plus ; archiver les livraisons terminées après la période de réclamation garde bas le nombre d’enfants actifs par parent. La partie 2 s’en occupe.

Ce que je ne ferais pas

Je ne créerais pas un compte personnel pour chaque destinataire sous prétexte qu’un destinataire est un individu. Je n’accrocherais pas un million de contacts à trois comptes. Je ne construirais pas un objet Livraison personnalisé à côté de l’ordre d’exécution de Field Service. Je n’unifierais pas les destinataires entre partenaires. Je ne mettrais pas des millions de photos ou de relevés GPS dans le stockage du cœur. Et je n’appellerais pas un destinataire unifié un golden record à moins d’avoir réellement pris une décision de maîtrise.

Ce qui reste ouvert

La partie 1 a posé l’ossature ; la partie 2 la met à l’épreuve. La règle des gros volumes à l’an trois (les ordres d’exécution, les rendez-vous de service et les articles entrent tous en territoire de gros volumes d’ici deux à trois ans), la conception des requêtes pour les vues de liste limitées à un partenaire, les trois intégrations entrantes et les trois flux de statut, la migration de RouteDesk, les transactions le jour même, et la conception de la sécurité derrière le portail. Steve Trucking changera aussi. Gardez cette conception ; vous y reviendrez.

Ce qu’un architecte décide ici

• Quels objets standard portent le cœur (ici, ceux de Field Service), et quels objets personnalisés sont vraiment justifiés (ici, un seul).
• La clé qui rapproche chaque ligne de commande d’un partenaire d’une livraison, et pourquoi elle appartient au partenaire.
• Ce qu’est le destinataire, selon la relation que Steve Trucking a réellement avec lui.
• S’il faut unifier les identités, et où le mélange est trop coûteux pour être risqué.
• Ce qui reste dans l’organisation, ce qui vit hors du cœur, et de quelles licences dépend la conception.

Pour aller plus loin

• Le dossier et les défis Steve Trucking (en anglais ; D1, D3, DC1).
• Aide Salesforce, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) et Experience Cloud User Licenses (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (en anglais), comme cité au chapitre 3.