Grands Volumes de Données (LDV) & Indexation : Architecturer des Requêtes SOQL pour 5M+ d'Enregistrements dans Salesforce et le Développement OmniStudio

Grands Volumes de Données (LDV) & Indexation : Survivre au Seuil des 5 Millions d'Enregistrements

Interroger 10 000 enregistrements est trivial. Interroger 5 000 000 d'enregistrements, c'est là que les systèmes s'effondrent, que les architectures échouent et que l'expérience utilisateur se dégrade.

Lorsque votre modèle de données d'entreprise pénètre sur le territoire des Grands Volumes de Données (LDV), les règles du jeu changent du tout au tout. Une requête SOQL qui fonctionnait parfaitement en Sandbox déclenchera soudainement la redoutable System.QueryException: Non-selective query against large object type en Production. Côté UI, les utilisateurs fixent des icônes de chargement infini jusqu'à ce que la transaction se termine violemment par un timeout.

Que vous extrayiez des données vers un Lightning Web Component (LWC) ou que vous exécutiez un lourd DataRaptor Extract dans OmniStudio, la plateforme appliquera impitoyablement ses Governor Limits. Pour concevoir des solutions qui passent à l'échelle sans accroc, vous devez changer de mentalité : passez de « l'interrogation de données » à « la conception de la sélectivité ».

Voici le plan architectural pour conquérir les LDV et garantir que vos requêtes et rapports n'échouent jamais.

1. Le Seuil de Sélectivité : Pourquoi Vos Requêtes Échouent

Salesforce ne vous permet pas d'effectuer des analyses de table complètes (full-table scans) sur des objets massifs. Si une requête SOQL prend trop de temps, elle consomme des ressources CPU partagées, ce qui est strictement interdit dans un environnement multi-tenant.

Pour éviter cela, Salesforce exige que les requêtes sur de grands objets (généralement > 100 000 enregistrements) soient sélectives. Une requête est sélective lorsque l'un des filtres cible un champ indexé et que ce filtre renvoie une portion suffisamment petite du total des données.

Les Règles d'Or de la Sélectivité :

• Index Standards (Id, Name, Lookup, Email) : Le filtre doit renvoyer moins de 30 % du premier million d'enregistrements, et 15 % des enregistrements au-delà du premier million.

• Index Personnalisés (External ID, Unique, ou Index Personnalisé demandé via le Support) : Le filtre doit renvoyer moins de 10 % du premier million d'enregistrements, et 5 % des enregistrements au-delà du premier million (jusqu'à un maximum de 333 333 enregistrements).

Si votre clause WHERE repose sur des champs non indexés, ou si votre filtre renvoie trop de lignes, le Query Optimizer de la plateforme abandonne l'index, tente un full-table scan et finit par lancer une erreur de timeout.

2. Stratégies Architecturales pour les LDV

Pour contourner ces limites strictes, les architectes doivent concevoir de manière proactive la couche de données pour une récupération à grande vitesse.

3. LDV dans l'Architecture OmniStudio

Dans OmniStudio, les requêtes non sélectives sont des tueurs silencieux. Lorsqu'une FlexCard appelle une Integration Procedure qui déclenche un DataRaptor Extract sur un objet Order de 5 millions de lignes, une clause WHERE non indexée brisera l'ensemble du processus de rendu de l'interface utilisateur.

Correction Architecturale : N'utilisez jamais d'instructions avec des jokers LIKE '%value%' dans les DataRaptors traitant des LDV, car cela force un full-table scan. Assurez-vous toujours que les paramètres transmis par l'OmniScript ou la FlexCard correspondent directement à des champs indexés (Standards, External IDs ou Custom Indexes). Si nécessaire, agrégez les données au préalable à l'aide de Batch Apex ou CRM Analytics pour injecter des données pré-calculées dans vos composants OmniStudio.

4. Exécution Front-End : Rechercher dans les LDV en Toute Sécurité avec LWC

Lors de la création de composants UI personnalisés pour interagir avec des tables massives, vous ne devez jamais essayer de charger des listes en masse. Obligez plutôt l'utilisateur à fournir des paramètres sélectifs, et utilisez les LWC avec le service @wire pour exécuter des requêtes propres et indexées sans ralentir le navigateur.

Voici un contrôleur LWC optimisé qui récupère des données en toute sécurité depuis une table massive à l'aide de paramètres indexés :

Verdict Final

Concevoir pour de Grands Volumes de Données (LDV) exige d'anticiper les échecs. N'attendez pas que votre organisation de production atteigne 5 millions d'enregistrements avant de penser à la sélectivité. Architecturez vos requêtes SOQL, vos DataRaptors OmniStudio et vos index personnalisés dès le premier jour pour garantir que, peu importe l'ampleur de votre catalogue ou de votre historique de transactions, votre expérience utilisateur reste ultra-rapide.

Contact

Contactez-nous pour toute suggestion ou question technique.

Email

andre@theforcejournal.tech

© 2026. Tous droits réservés.