Maîtriser la Bulk API 2.0 : Ingestion de données à grande vitesse et comment surmonter la limite quotidienne de 100 millions

Maîtriser la Bulk API 2.0 : Ingestion de données à grande vitesse et à grande échelle

Transférer des données dans Salesforce est un jeu d'enfant lorsqu'il s'agit de quelques milliers d'enregistrements. Cependant, lorsque vous concevez des intégrations pour des environnements d'entreprise — où uma synchronisation nocturne implique le transfert de données depuis un Data Lake AWS massif ou un ERP sur site — les API REST ou SOAP traditionnelles se heurtent rapidement à un mur infranchissable.

Si vous tentez de pousser des millions de lignes à travers des endpoints synchrones standards, vous épuiserez vos limites de requêtes simultanées, déclencherez de désastreuses erreurs de verrouillage de dados (lock contention) et saturerez vos allocations d'API quotidiennes en l'espace de quelques minutes.

Pour les ensembles de données massifs, la Bulk API 2.0 est la référence absolue de l'industrie. Conçue par-dessus le framework REST moderne de Salesforce, elle réinvente l'exécution des chargements de dados à grande échelle en déléguant le plus gros du travail architectural à la plateforme elle-même.

Néanmoins, même le framework asynchrone le plus robuste a ses limites. Si vous ne concevez pas vos stratégies d'ingestion avec précision, vous finirez par vous heurter au plafond de la plateforme : la limite glissante de 100 millions d'enregistrements par jour. Explorons les rouages de la Bulk API 2.0 e a maneira de conceber sua arquitetura para contornar essa limite.

1. Bulk API 2.0 : Un bond en avant architectural

Si vous avez travaillé avec l'ancienne Bulk API 1.0, vous vous souvenez probablement de la fastidieuse orchestration qu'elle exigeait : diviser manuellement vos données en lots (batches), suivre de multiples identifiants de lots et gérer l'état de chaque fragment individuellement.

La Bulk API 2.0 réécrit complètement cette expérience développeur. Il vous suffit d'ouvrir un job, de charger un seul payload CSV massif (jusqu'à 150 Mo) et de fermer le job. Salesforce s'occupe du reste.

• Découpage automatique (Automatic Chunking) : La plateforme divise automatiquement votre fichier de 150 Mo en lots optimisés en arrière-plan.

• Suivi simplifié des états : Vous suivez un seul ID de Job pour superviser la progression, au lieu de gérer uma toile d'araignée de statuts de lots.

• Suivi optimisé des limites quotidiennes : Contrairement à la Bulk 1.0, où les limites étaient liées au nombre de lots traités, les limites de la Bulk 2.0 sont strictement calculées en fonction du nombre total d'enregistrements traités.

2. Plan stratégique : Maîtriser la limite des 100 millions d'enregistrements par jour

Salesforce impose une limite stricte de 100 000 000 d'enregistrements traités par fenêtre glissante de 24 heures pour les jobs Bulk API. Si votre pipeline de données d'entreprise dépasse ce seuil, la plateforme rejettera purement et simplement toute tentative d'ingestion bulk ultérieure, au risque de désynchroniser vos données.

Pour protéger votre org contre ce dépassement lors de migrations massives ou de cycles de synchronisation quotidiens, implémentez ces stratégies architecturales :

A. Adopter une logique stricte de chargement différentiel (Delta Loading / CDC)

La meilleure façon de gérer uma limite est d'éviter de la gaspiller. N'exécutez jamais de « chargements complets » (full drops) où vous écrasez des enregistrements inchangés.

• Implémentez la capture de changement de données (Change Data Capture ou CDC) ou un suivi différentiel basé sur l'horodatage au sein de votre système source (par exemple, AWS Kinesis ou votre entrepôt de données).

• Extrayez et diffusez uniquement les enregistrements qui ont été créés, modifiés ou supprimés depuis la dernière exécution réussie de la synchronisation.

B. Déléguer l'enrichissement des données au système source

Si vous chargez des millions d'enregistrements simplement pour déclencher une série de formules Apex lourdes, de flows ou de mises à jour cross-objets qui calculent des champs de texte, vous gaspillez une puissance de calcul précieuse et augmentez les temps de verrouillage de la base de données.

• Effectuez les transformations de données complexes, les agrégations et les mises en forme en amont, au sein de votre outil ETL ou de votre couche de données, antes que o payload atinja o Salesforce.

C. Surveiller les limites de manière dynamique via l'API

N'attendez pas qu'un job échoue pour découvrir que votre org est à court de capacité. Votre pipeline d'intégration devrait interroger l'endpoint REST des limites de Salesforce (/services/data/vXX.X/limits) avant de lancer tout job Bulk 2.0 massif.

3. Performance d'ingestion : Contourner les goulots d'étranglement de la base de données

Même si vous restez bien en deçà de la limite des 100 millions d'enregistrements, vos jobs Bulk API peuvent tout de même s'enliser ou échouer en raison de conflits de verrouillage (Lock Contention) ou des limites de timeout CPU au sein de Salesforce. Lorsque des milliers d'enregistrements sont écrits simultanément, the database must secure locks on parent accounts and related objects.

Optimiser l'ordre de chargement

Pour minimiser les conflits de verrouillage, triez votre fichier CSV d'entrée par ID parents (tels que AccountId ou un champ de recherche personnalisé) avant de lancer o upload. Lorsque des enregistrements partageant le mesmo parent estão agrupados dentro do mesmo chunk interno, Salesforce locks the parent record once, processes the group, and releases it cleanly, empêchant ainsi les lots parallèles de se bloquer mutuellement.

Le contournement de l'automatisation (Le modelo « Kill Switch »)

Exécuter des règles de validation, des flows déclenchés par des enregistrements (Record-Triggered Flows) et des triggers Apex complexes pendant un chargement bulk de plusieurs millions d'enregistrements détruira vos performances d'ingestion.

Recommandation de l'Architecte : Implémentez un interrupteur de contournement d'intégration (integration bypass switch). Utilisez un Custom Metadata Type ou un Hierarchical Custom Setting pour créer un commutateur global qui désactive les règles de validation lourdes, les flux d'automatisation et les triggers spécifiquement pour votre profil d'Utilisateur d'Intégration pendant la fenêtre de chargement bulk.

4. Gérer les succès partiels et le suivi des erreurs

La Bulk API 2.0 traite les requêtes de manière asynchrone, ce qui signifie qu'elle n'annulera pas l'ensemble d'un job si certains enregistrements rencontrent des erreurs. Elle fonctionne selon un paradigme de succès partiel.

Dès qu'un job atteint l'état JobComplete, votre pipeline de données doit immédiatement récupérer les fichiers de résultats à l'aide des endpoints natifs :

• Enregistrements réussis : /services/data/vXX.X/jobs/ingest/jobId/successfulResults

• Enregistrements échoués : /services/data/vXX.X/jobs/ingest/jobId/failedResults

Le fichier des résultats échoués fournit l'ID Salesforce exact, les données de la ligne d'origine et un message d'erreur clair (par exemple, REQUIRED_FIELD_MISSING ou CUSTOM_VALIDATION_EXCEPTION) pour chaque ligne en échec. Votre outil ETL doit être configuré pour capturer ce flux, acheminer les échecs vers une file d'attente de rejets (Dead-Letter Queue ou DLQ) pour correction, et permettre au pipeline principal de poursuivre sa route sans interruption.

Verdict Final

La Bulk API 2.0 est un outil exceptionnellement puissant, mais elle exige de passer d'une logique de requête-réponse en temps réel à une stratégie d'ingénierie asynchrone basée sur le découpage par lots. En regroupant vos données pour éviter les conflits de verrouillage, en surveillant par programme les limites glissantes sur 24 heures et en construisant des interrupteurs d'automatisation pour la logique interne de votre org, vous pouvez faire évoluer de manière transparente votre pipeline de données d'entreprise pour gérer des millions d'enregistrements chaque jour.

Contact

Contactez-nous pour toute suggestion ou question technique.

Email

andre@theforcejournal.tech

© 2026. Tous droits réservés.