Asynchrone verwerking vergroot de schaalbaarheid door hogere limieten per context toe te staan. Asynchrone verzoeken worden achter de schermen in hun eigen threads uitgevoerd, zodat gebruikers werk aan de clientzijde kunnen blijven uitvoeren terwijl de asynchrone taken op de achtergrond worden uitgevoerd.

Het Salesforce Lightning Platform biedt een verscheidenheid aan asynchrone technologieën die kunnen worden gebruikt om een bepaalde gebruikscase op te lossen. Elke technologie heeft voordelen en limieten waarmee u rekening moet houden bij het selecteren van een benadering voor elke gebruikscase.

Bij het kiezen van een technologie voor implementatie zijn drie belangrijke overwegingen om in gedachten te houden:

1. Asynchrone verwerking is niet de beste aanpak voor elk probleem. Het kan verleidelijk zijn om elk proces dat niet direct interactie van de gebruiker vereist, te zien als een goede kandidaat voor asynchrone verwerking, maar er zijn enkele nadelen. Ten eerste hebben asynchrone processen geen SLA, wat betekent dat er geen garantie is dat een asynchroon proces binnen een bepaalde hoeveelheid tijd wordt voltooid. Ten tweede is er geen garantie voor consistente reactielatentie. Als een asynchroon proces binnen een bepaalde hoeveelheid tijd wordt voltooid, kan het voltooien van een volgend proces een andere hoeveelheid tijd vergen. Zelfs als een gebruiker niet direct op een reactie wacht, is asynchrone verwerking mogelijk niet geschikt voor uw scenario als u daaropvolgende processen hebt die afhankelijk zijn van een reactie, of als u bang bent dat buitensporige reactietijden ertoe leiden dat uw gegevens niet meer synchroon lopen met de gegevens in een extern systeem.
2. Er zijn verschillende manieren om asynchrone verzoeken te verwerken op het Salesforce Platform, dus zorg ervoor dat u de beste aanpak kiest. Technologieën die asynchrone verwerking op het Salesforce Platform ondersteunen, werken anders "onder de motorkap", en sommige zijn ontworpen voor zeer specifieke gebruikscases.
3. Als een technologie asynchroon is aan de clientzijde, betekent dit niet noodzakelijk dat alle end-to-end verwerking parallel wordt uitgevoerd. Afhankelijk van de keuzes die u maakt, kunnen de berichten van de client soms nog steeds een serienummer krijgen aan de serverzijde.

Als u de verkeerde technologieën of de verkeerde combinaties van technologieën gebruikt voor een taak, kunnen er onbedoelde gevolgen optreden die de voordelen van asynchrone verwerking tenietdoen. Deze handleiding geeft uitleg en aanbevelingen, evenals potentiële nadelen en antipatronen voor verschillende asynchrone gebruikscases, samen met de reden voor die aanbevelingen. Het biedt ook inzicht in de manier waarop verschillende asynchrone implementatietechnieken werken en worden gereguleerd op het Salesforce Platform.

Als u een beslissing neemt over welke technologie u wilt gebruiken, is er een gerichte gids voor beslissingen over asynchrone verwerking die een snelle toewijzing van typische gebruikscases aan de best passende technologie geeft.

Het Salesforce Lightning Platform is een uitgebreid, AI-gestuurd platform dat werknemers, autonome AI-agenten, bedrijfsgegevens en toepassingen verenigt in één vertrouwd systeem om de productiviteit en klantervaring te verbeteren. Het maakt het mogelijk om een "agentische onderneming" te maken door Customer 360 apps, Data Cloud en Slack te verbinden voor end-to-end automatisering.

Dit document behandelt geen technologieën in andere ecosystemen zoals MuleSoft, Informatica, Commerce Cloud, Tableau en Marketing Cloud.

Deze handleiding richt zich uitsluitend op asynchrone verwerking binnen het Salesforce Lightning Platform. Als u op zoek bent naar informatie over asynchrone integratiepatronen, raadpleegt u Event-Driven Architecture.

• Zorg er vóór het gebruik van asynchrone verwerking voor dat uw gebruikscases in het patroon passen. Asynchrone patronen hebben geen SLA, zijn onderworpen aan meerdere beheermechanismen, kunnen capaciteitslimieten hebben gedefinieerd op basis van licenties en kunnen verwerkingsvertragingen veroorzaken vanwege de beperkte aard van de resources die zijn toegewezen aan asynchrone infrastructuur binnen het Salesforce Platform. Houd rekening met deze beperkingen wanneer u asynchrone verwerking gebruikt in scenario's waarin een gebruiker een reactie van het systeem nodig heeft voordat deze verder kan gaan met zijn of haar werk.
• Asynchrone verwerking met Salesforce is geen oplossing voor grenzeloze schaalbaarheidsbehoeften. Het Salesforce Platform kan niet oneindig worden geschaald en asynchrone patronen zijn nog steeds onderworpen aan beperkingen. Asynchrone verwerking gebruikt threads, die de contextuele informatie bevatten die een CPU nodig heeft om een stroom instructies uit te voeren. Threads kunnen parallel worden uitgevoerd. Het aantal beschikbare threads in een CPU is beperkt, dus het platform heeft mechanismen om ervoor te zorgen dat de beschikbare threads zo efficiënt mogelijk worden gebruikt. Het stroomregelingsmechanisme van het platform voorkomt dat organisaties te veel threads verbruiken en andere organisaties negatief beïnvloeden. Het fair use-algoritme van het platform bepaalt het aantal threads dat een organisatie beschikbaar heeft voor elk bepaald berichttype.
• Weet wanneer transacties echt asynchroon zijn. Sommige architectuurpatronen werken asynchroon van begin tot eind. Andere processen werken echter asynchroon aan de client- of browserzijde, maar serialiseren verzoeken aan serverzijde, die dan onderworpen zijn aan synchrone beheerlimieten.
• Voor het samenstellen van grootschalige uitgaande integraties vanuit het Salesforce Platform gebruikt u platformevents en robuuste middleware in plaats van aanroepen via asynchrone Apex. Omdat er een beperkt aantal asynchrone threads beschikbaar is in het platform, zijn uitgaande integraties via asynchrone Apex beperkt schaalbaar. Als uw organisatie uitgaande integraties heeft met grote aantallen berichten, het aantal beschikbare threads overschrijdt en lange verwerkingstijden heeft, leidt het gebruik van asynchrone Apex onvermijdelijk tot vertragingen.
• Zorg ervoor dat u bewaking opneemt bij gebruik van asynchrone verwerking. Met bewaking kunt u problemen zo vroeg mogelijk detecteren en corrigeren voordat er zich grote prestatie-incidenten voordoen.
• Houd rekening met events die extreme belastingen kunnen veroorzaken. Wanneer u asynchrone processen ontwerpt, zorg er dan voor dat ze voorspelbaar pieken en pieken in de werkbelasting kunnen beheersen. Denk na over de manier waarop uw implementatie onverwachte gebeurtenissen, zoals stroomuitval, afhandelt, en ontwerp beveiligingen die gegevensverlies of functionaliteitsverlies beperken.

Wanneer u een benadering selecteert voor asynchrone verwerking aan serverzijde, evalueert u eerst de vereisten en beschikbare resources van uw organisatie. Uw doel is om een aanpak te kiezen die de implementatie- en onderhoudskosten minimaliseert, maar toch de schaalbaarheid garandeert en de kans op limietschendingen verkleint. Dit doel is afhankelijk van de technische overwegingen die in de volgende secties worden beschreven, evenals de samenstelling van uw team. Denk bijvoorbeeld aan de vraag of u Apex ontwikkelaars in uw team hebt die uw pro-code oplossing kunnen onderhouden. Anders kan een declaratieve benadering zinvoller zijn. Houd er ook rekening mee dat verschillende sets limieten van toepassing kunnen zijn op verschillende tools.

Denk aan de gebruikscase van een asynchroon bestelproces in Salesforce. Wanneer een order wordt opgeslagen, activeert deze een bericht naar een extern magazijnbeheersysteem met speciale instructies voor het verpakken en verzenden van een item. De gebruiker die de order plaatst, heeft geen onmiddellijke reactie van het magazijnbeheersysteem nodig, waardoor de aanvraag asynchroon kan worden verzonden. De asynchrone verwerking zorgt ervoor dat de gebruiker zonder vertraging kan doorgaan met zijn werk.

Overwegingen voor uw architectuur:

• Hoeveel gelijktijdige processen zijn er nodig?
• Hoe zal het gelijktijdige proces een interactie met elkaar hebben?
• Hoeveel SOQL-query's worden er binnen elk proces uitgevoerd?
• Hoeveel DML-bewerkingen worden er binnen elk proces uitgevoerd?
• Hoe lang duurt elk proces?
• Hoe gevoelig zijn processen voor specifieke timing?

De multitenantarchitectuur van het Salesforce Platform isoleert en ondersteunt tegelijkertijd de variërende vereisten van veel belanghebbenden (organisaties). Alle asynchrone Apex methoden die in deze handleiding worden behandeld, worden uitgevoerd binnen dezelfde asynchrone infrastructuur in het Salesforce Platform. Ze gebruiken een framework voor berichtenwachtrijen dat wordt bepaald door twee primaire afdwingingsmechanismen: stroombeheer en fair use.

De stroomregeling en fair use-mechanismen voorkomen dat één belanghebbende te veel serverresources gebruikt en te weinig resources overhoudt voor de resterende belanghebbenden. Hoewel het nuttig is om te begrijpen hoe deze mechanismen werken, is het belangrijk om te onthouden dat het volgen van best practices voor asynchrone verwerking, zoals die in de volgende secties, de kans aanzienlijk verkleint dat u er problemen mee ondervindt.

Het stroomregelingsmechanisme van het platform voorkomt dat één organisatie een bepaald berichttype overstroomt, wat te veel threads verbruikt en een negatieve invloed heeft op andere organisaties. Voordat het framework nieuwe items toevoegt aan de wachtrij die is gekoppeld aan een berichttype, controleert het de eerste paar duizend bestaande items in de wachtrij. Als het merendeel van de bestaande items is gekoppeld aan diezelfde organisatie en die organisatie al items in werknemersthreads heeft, worden de nieuw toegevoegde items naar achteren in de wachtrij verplaatst. Dit proces wordt opnieuw in de wachtrij geplaatst genoemd. Het opnieuw in de wachtrij plaatsen gebeurt doorgaans met batch Apex en Bulk API-processen, omdat deze vaak grote aantallen items tegelijkertijd in hun wachtrijen invoegen.

Het fair use-mechanisme van het platform implementeert een op lagen gebaseerd systeem. Het systeem zorgt ervoor dat elke organisatie op het Salesforce Platform een redelijk deel van de verwerkingstijd krijgt voor een bepaald berichttype, inclusief de berichttypen Toekomst, Wachtrij en Batch. Als één organisatie een bepaald berichttype domineert in dezelfde tijd dat andere organisaties wachten op het uitvoeren van werk aan hetzelfde berichttype, reduceert het fair-use algoritme het aantal threads dat de organisatie beschikbaar heeft voor dat specifieke berichttype.

Een voordeel van het gebruik van asynchrone Apex methoden is dat bepaalde beheerlimieten, zoals SOQL querylimieten en heapgroottelimieten, hoger zijn. Vertrouw echter niet te veel op deze methoden. Vanwege de beperkte resources die zijn toegewezen aan asynchrone infrastructuur, kan intensief gebruik van Future, Queueable en Batch Apex verwerkingsvertragingen veroorzaken die voortvloeien uit beperkingen op basis van fair use en stroomregeling.

Uitgaande aanroepen die asynchrone Apex gebruiken, tellen mee voor de asynchrone Apex limiet. De dagelijkse limiet is momenteel 250.000 of 200 keer het aantal van toepassing zijnde gebruikerslicenties, afhankelijk van welke waarde groter is. Deze limiet kan een probleem zijn voor gebruikscases met groot volume. Als u de limiet overschrijdt, mislukken uw asynchrone Apex taken en de bijbehorende uitgaande aanroepen.

Omdat het platform een beperkt aantal asynchrone threads beschikbaar heeft, hebben uitgaande integraties via asynchrone Apex bovendien een beperkte schaalbaarheid. Alle uitgaande integraties met groot volume die het aantal beschikbare threads overschrijden, kunnen lange verwerkingstijden hebben en tot vertragingen leiden.

Overweeg voor gebruikscases met groot volume deze alternatieve benaderingen. API-aanroepen met deze benaderingen tellen mee voor de dagelijkse API-verzoeklimiet, die aanzienlijk hoger is dan de dagelijkse asynchrone Apex limiet. Deze benaderingen zijn dus schaalbaarder. Er zijn echter nog steeds fysieke beperkingen voor het aantal gelijktijdige verzoeken dat een CPU kan verwerken.

• Middleware geplande pull. Voorkom vertragingen in verband met uitgaande integratietaken met groot volume door middleware te gebruiken om de gegevens op geplande basis op te halen in plaats van ze te pushen via asynchrone Apex. Middleware, zoals het MuleSoft Anypoint Platform, kan native SOAP-API of REST-API synchroon gebruiken, zodat er weinig of geen vertragingen worden geïntroduceerd. Middleware kan ook de eigen Bulk-API gebruiken voor grote gegevensvolumes.

• Middlewarepull via Platform-eventkennisgeving. In plaats van Future, Queueable of Batch asynchrone Apex in een wachtrij te plaatsen voor het uitvoeren van uitgaande integraties, kunt u platformevents gebruiken. De platformevent kan de uitgaande informatie zelf leveren of een middlewaretool instrueren om de vereiste informatie op te halen via een native API en deze naar de eindbestemming te brengen. Geen van deze benaderingen is onderhevig aan de vertragingen die asynchrone Apex ondervindt. Platformeventlimieten zijn echter nog steeds van toepassing.

Met Apex met wachtrij kunt u Apex processen uitvoeren die uitgebreide databasebewerkingen of externe webserviceaanroepen asynchroon omvatten. Als u Apex met wachtrij wilt gebruiken, implementeert u de interface Wachtrij en voegt u vervolgens een taak toe aan de Apex taakwachtrij. Deze benadering zorgt ervoor dat de asynchrone Apex taak op de achtergrond wordt uitgevoerd in een eigen geïsoleerde thread en de uitvoering van uw belangrijkste Apex logica niet vertraagt. Elke in de wachtrij geplaatste taak wordt uitgevoerd wanneer systeemresources beschikbaar komen.

Apex vertegenwoordigt de evolutie van asynchrone Apex. Het biedt voorzieningen die niet beschikbaar zijn voor toekomstige Apex methoden, waaronder:

• Taak-ID's: Wanneer u een taak indient door de methode System.enqueueJob aan te roepen, retourneert de methode de ID van de nieuwe taak. U kunt deze ID gebruiken om uw taak te identificeren. Als u de voortgang ervan wilt bewaken, bekijkt u de pagina Apex Taken in Set-up van Salesforce of voert u een query uit op het object AsyncApexJob.
• Ondersteuning voor niet-primitieve typen: Wachtrijklassen kunnen lidvariabelen van niet-primitieve gegevenstypen bevatten, zoals sObjects of aangepaste Apex typen.
• Ondersteuning voor taakketens: U kunt wachtrijtaken aan elkaar koppelen door een tweede taak te starten vanuit een lopende taak. Deze techniek kan u helpen scenario's met procesafhankelijkheden aan te pakken.
• Maximale diepteregeling: U kunt wachtrijtaken configureren met een maximale stapeldiepte om ervoor te zorgen dat ketens van taken niet leiden tot onverwachte herhalingen.
• Deduplicaathandtekeningen: Wachtrijtaken bieden een optionele handtekening voor het detecteren en verwijderen van duplicaattaken.
• Configureerbare vertraging: U kunt een vertraging definiëren van maximaal 10 minuten voordat de taak Wachtrij wordt uitgevoerd.
• Transactieafronders: U kunt een volgorde na de actie bijvoegen bij een wachtrijtaak en relevante acties ondernemen op basis van het resultaat ervan. Zo kan een transactieafhandelaar een Wachtrijtaak die is mislukt vanwege een onverwerkte uitzondering, maximaal vijf keer opnieuw in de wachtrij plaatsen.

Salesforce gebruikt een op wachtrijen gebaseerd framework voor de afhandeling van asynchrone processen. Deze wachtrij wordt gebruikt om de werkbelasting van verzoeken te verdelen over organisaties. Als u ervoor wilt zorgen dat uw organisatie deze wachtrij zo efficiënt mogelijk gebruikt:

• Vermijd het in een wachtrij plaatsen van toekomstige of in een wachtrij te plaatsen methoden rechtstreeks vanuit acties die worden gegenereerd door grote volumes aan eindgebruikersactiviteit of integratie-API-aanroepen. Deze benadering kan de dagelijkse asynchrone Apex limieten snel uitputten, wat ernstige gevolgen heeft voor het bedrijf.
• Vermijd het in een wachtrij plaatsen van meer dan één asynchrone actie per synchrone actie. Wanneer meerdere asynchrone methoden vanuit één synchrone actie in een wachtrij worden geplaatst, worden de asynchrone activiteiten vaak tegelijkertijd uitgevoerd en dragen ze bij aan problemen met rijvergrendeling en/of time-outs bij rijvergrendeling.
• Vermijd het toevoegen van grote aantallen toekomstige of wachtrijbare methoden aan de asynchrone wachtrij.
• Zorg ervoor dat toekomstige en wachtrijbare methoden zo snel mogelijk worden uitgevoerd. Hoe langer het duurt om een toekomstige methode uit te voeren, hoe waarschijnlijker het is dat verzoeken erachter in de wachtrij worden vertraagd. Voor een snelle uitvoering van batchtaken minimaliseert u de aanroeptijden van webservices, stemt u query's af die in uw toekomstige methoden worden gebruikt en optimaliseert u alle andere objectautomatiseringen, waaronder Processamensteller-processen, werkstroomregels, stromen en Apex triggers.
• Test uw asynchrone methoden op schaal. Gebruik een omgeving die het maximale aantal methoden genereert dat u verwacht te verwerken. Aan de hand van deze tests kunt u bepalen of u problemen ondervindt met prestaties of limieten in uw productieomgeving. Denk ook aan de gevolgen voor cumulatieve dagelijkse limieten.
• Gebruik Batch Apex in plaats van toekomstige of wachtrijmethodes om grote aantallen records te verwerken. Batch Apex kan complexe, langlopende processen verwerken die worden uitgevoerd voor duizenden records en kunnen worden gepland voor uitvoering buiten kantooruren wanneer er meer resources beschikbaar zijn.

Gebruik geplande Apex voor uitvoering op een opgegeven tijdstip en met een herhaalde frequentie zoals gedefinieerd door een cron-expressie. Hoewel het plannen van Apex via de cron-expressie een asynchroon proces is, wordt de onderliggende code synchroon uitgevoerd wanneer de taak start. Geplande Apex is ideaal voor dagelijkse of wekelijkse onderhoudstaken.

• U kunt slechts 100 geplande Apex taken tegelijk hebben. Als u deze beperking wilt voorkomen, kunt u overwegen om een door planning geactiveerde stroom te gebruiken die Apex code aanroept in plaats van geplande Apex.
• Wees uiterst voorzichtig als u van plan bent om een les te plannen via een trigger. U moet kunnen garanderen dat de trigger niet meer geplande klassen toevoegt dan de limiet. Denk met name aan API-bulkupdates, importwizards, bulkrecordwijzigingen via de gebruikersinterface en alle gevallen waarin meer dan één record tegelijk kan worden bijgewerkt.
• Gebruik voor eenmalige taken die maximaal 10 minuten in de toekomst moeten worden gepland, een vertraagde wachtrijtaak. Deze benadering telt niet mee voor de limiet van 100 geplande taken.
• Geplande Apex wordt uitgevoerd in een synchrone context met synchrone limieten.
• Denk na over de duur van de geplande taak. Een langlopende taak kan overlappen met het begin van de volgende geplande taak.
• Salesforce plant de klasse voor uitvoering op het opgegeven tijdstip. Feitelijke uitvoering kan worden vertraagd op basis van beschikbaarheid van de service. Taken die zijn gepland voor uitvoering tijdens downtime van serviceonderhoud, worden gepland voor uitvoering nadat de service weer beschikbaar is.
• Gebruik System.scheduleBatch voor het plannen van batchtaken in plaats van een geplande taak met als enige doel een batchtaak in een wachtrij te plaatsen.

Historisch gezien vielen synchrone aanroepen die werden gedaan vanuit een Apex methode die werd uitgevoerd in een synchrone Apex transactiecontext, zoals een Visualforce controller of een Lightning component controller, onder de Apex gelijktijdigheidslimiet voor langlopende verzoeken. Met ingang van Winter '19 worden synchrone aanroepen niet langer als langdurig geteld. Hoewel Apex voortzettingen aanvankelijk zijn gemaakt als een oplossing voor synchrone aanroepen die resulteerden in langlopende verzoeken, bieden ze ook enkele extra voordelen.

• Eén synchrone actie kan maximaal drie vervolgacties uitvoeren. De vorige voortzetting moet zijn voltooid voordat een nieuwe voortzettingsactie wordt uitgevoerd.
• Elke vervolgactie kan maximaal drie aanroepen uitvoeren, die parallel worden uitgevoerd.
• Wanneer alle aanroepen die door een voortzettingsactie worden uitgevoerd, zijn voltooid, roept het platform de callback-methode voor voortzetting aan om de resultaten af te handelen.

Hoewel voortzettingen asynchroon worden uitgevoerd met betrekking tot de oorspronkelijke synchrone actie, zijn er belangrijke verschillen tussen Apex voortzettingen en andere asynchrone Apex technieken zoals toekomstige methoden, wachtrij of batch. Belangrijke verschillen zijn:

• Voortzettingen worden op geen enkele manier in de wachtrij geplaatst.
• Voortzettingen dragen niet bij aan de dagelijkse asynchrone Apex uitvoeringslimiet.
• Voortzettingen schakelen van threadcontext op de toepassingsserver over van een zwaargewicht Apex platform-thread naar een lichtgewicht thread die alleen aanroepen uitvoert. Voor het uitvoeren van aanroepen die maximaal 120 seconden kunnen duren, bieden voortzettingen aanzienlijke geheugenbesparingen voor de toepassingsserver.
• Oorspronkelijk konden voortzettingen alleen worden uitgevoerd vanuit een Visualforce JavaScript-remoting-aanroep. In Summer '19 werden echter officieel vervolgen toegevoegd aan het Lightning Component-framework, waardoor Visualforce niet meer nodig was.

Platform-events zijn de implementatie door het Salesforce Platform van een puur eventgestuurde architectuur. U vindt meer details over de componenten die zijn gekoppeld aan dit type architectuur in de Architectenhandleiding voor eventgestuurde architectuur.

Platformevents en platformeventtriggers/-stromen zijn vaak prima alternatieven voor het uitvoeren van asynchrone Apex. Ze zijn ook een prima manier om verwerking buiten het platform aan te roepen. Zo kunt u een combinatie van AWS-eventrelays (Amazon Web Services) en platformevents gebruiken om serverloze rekenfunctionaliteit aan te roepen in AWS Lambda. Werk dat relatief snel en zonder aanroepen wordt uitgevoerd (wat niet mogelijk is vanuit een platformeventtrigger of -stroom) is een prima kandidaat voor een combinatie van platformevent/trigger of event/stroom.

De events die naar de bus worden gepubliceerd via publiceren na vastleggen, worden in volgorde geleverd en kunnen in bulk worden verwerkt door de trigger of stroom in een afzonderlijke synchrone context. De context is synchroon en dwingt alle synchrone beheerlimieten af. Kies zorgvuldig de platformeventtrigger/batchgrootte van de stroom om te voorkomen dat limieten worden bereikt.

• Aangezien events worden gepubliceerd in de eventbus, zijn ze beschikbaar voor consumenten. In het geval van eventtriggers (Apex of stroom) worden deze events verzonden naar beschikbare synchrone threads op de applaag (één thread per eventtrigger/stroom). Dit proces heeft geen SLA.
• Wanneer publicatiebewerkingen aan de wachtrij worden toegevoegd, wordt het resultaat van het wachtrijproces opgeslagen in het object Database.SaveResult. Deze items geven alleen aan of de wachtrijbewerking is geslaagd. Als u het eindresultaat wilt van een event dat is gepubliceerd via de eventbus, implementeert u een Apex publish callback. Met deze aanvullende informatie kunt u beslissingen nemen over verdere acties, zoals een poging om mislukte events opnieuw te publiceren.
• Hoewel platformevents niet onderworpen zijn aan dezelfde limieten als asynchrone Apex, hebben ze wel hun eigen sets governorlimieten. Als u problemen ondervindt met limieten, kunt u uitgebreide meetgegevens over eventgebruik inschakelen om te bepalen of specifieke events meer van uw toewijzingen verbruiken dan u van plan was. Als u meer doorvoer nodig hebt voor eventtriggers, kunt u overwegen om parallelle abonnementen te gebruiken om events tegelijkertijd te verwerken in plaats van in één stroom. Met parallelle abonnementen kunt u Apex Platform-eventtriggers schalen om grote volumes events te verwerken. Parallelle abonnementen zijn beschikbaar voor aangepaste platformevents met groot volume, maar niet voor standaardevents of wijzigingsevents.
• Platform-events hebben twee opties voor publicatiewerking:
  • Onmiddellijk publiceren: Events worden onmiddellijk tijdens de transactie gepubliceerd, vóór de definitieve databaseverbintenis. Events die op deze manier worden gepubliceerd, worden niet gegarandeerd in de juiste volgorde gepubliceerd.
  • Publiceren na verbintenis: Events worden gepubliceerd op het moment dat de databasetransactie met succes wordt doorgevoerd. Events die op deze manier worden gepubliceerd, worden gegarandeerd op volgorde gepubliceerd.

Het is handig om Onmiddellijk publiceren te gebruiken voor gebruikscases zoals vastleggen, waarbij u de vastleggingsevent wilt publiceren, ongeacht of de transactie slaagt en wordt uitgevoerd, of mislukt en wordt teruggedraaid. Het is mogelijk om onmiddellijk een platformevent te publiceren die wordt verbruikt door een platformeventtrigger. De platformeventtrigger concurreert vervolgens om een databaserijvergrendeling met de transactie die deze heeft gepubliceerd. Controleer alle ontwerpen grondig voordat u platformevents onmiddellijk publiceert om ervoor te zorgen dat u dit scenario vermijdt.

Asynchrone stromen bieden low-code alternatieven voor asynchrone Apex. Net als bij andere vormen van asynchrone verwerking worden ze op de achtergrond uitgevoerd wanneer resources beschikbaar zijn. Asynchrone stromen hebben ook geen SLA's en kunnen onvoorspelbare wachttijden hebben.

Geplande trajecten zijn op cron-triggers gebaseerd om op een specifiek tijdstip te worden uitgevoerd. Ze worden uitgevoerd wanneer records worden gemaakt, bijgewerkt of verwijderd, en geven u gedetailleerde controle over wanneer de automatisering moet worden uitgevoerd ten opzichte van de recordwijziging. (Voorbeeld: een e-mailbericht verzenden naar een gebruiker één uur voordat een taak moet worden uitgevoerd.) In tegenstelling tot Apex future-methoden, die zijn beperkt tot maximaal 50 methoden die in een synchrone transactie in de wachtrij zijn geplaatst, hebben geplande stroomacties momenteel geen maximale wachtrijlimiet per transactie. Er is echter een batchgrootteconfiguratie binnen de definitie van het geplande traject, die enige controle mogelijk maakt over hoeveel records worden afgehandeld door de uitvoering van de geplande trajectstroom.

Asynchrone paden kunnen worden toegevoegd aan door records geactiveerde stromen. Ze worden op de achtergrond uitgevoerd en vertragen niet de uitvoering van de transactie die de stroom oorspronkelijk heeft geactiveerd. U kunt een asynchroon pad gebruiken om een langlopende bewerking uit te voeren of elke bewerking die u op een eigen tijdstip wilt uitvoeren. Asynchrone paden kunnen gemengde DML-fouten voorkomen die optreden wanneer u een waarde moet bijwerken voor een gerelateerde record die geen deel uitmaakt van de record die de stroom heeft geactiveerd.

Opmerking: Uitgaand berichtenverkeer is een verouderde voorziening en platformevents (beschreven in de vorige sectie) zijn een modernere benadering en bieden meer flexibiliteit. Platform-events zijn het aanbevolen patroon van Salesforce voor eventgestuurde integratie.

Uitgaande berichten bieden een manier van asynchrone uitgaande communicatie via de SOAP-API. Indien geconfigureerd in Salesforce, produceert de definitie van het uitgaande bericht een SOAP WSDL die kan worden verbruikt door een externe webserviceprovider. Uitgaande berichten kunnen via een trigger worden geactiveerd vanuit werkstroomregels, Processamensteller-processen of Lightning na opslaan. Een uitgaand SOAP-bericht kan maximaal 100 kennisgevingen bevatten. Elke kennisgeving bevat de object-ID en een verwijzing naar de gekoppelde sObject-gegevens. Als de informatie in het onderliggende object verandert nadat de kennisgeving in de wachtrij is geplaatst, maar voordat deze wordt verzonden, worden alleen de nieuwste gegevens geleverd en niet de tussentijdse wijzigingen.

Wanneer een luisteraar van uitgaande berichten (de webservice die u hebt geconfigureerd met de gegenereerde WSDL) een bericht ontvangt, gebruikt deze de opgenomen sessie-ID-gegevens om de Lightning Platform-API aan te roepen om de record in Salesforce bij te werken die het uitgaande bericht heeft geactiveerd.

• Uitgaande berichten worden niet verwerkt via de op wachtrij gebaseerde asynchrone infrastructuur in Salesforce die activiteiten uitvoert zoals toekomstige methoden, Apex in wachtrij, Batch Apex, Bulk-API, enzovoort. In plaats daarvan worden records lokaal opgeslagen in het object OutboundMessage. Berichten worden verzonden en opnieuw geprobeerd via een lokaal gepland achtergrondproces.
• Berichten worden niet synchroon verzonden wanneer de actie voor uitgaande berichten wordt uitgevoerd door de initiërende automatisering (bijvoorbeeld een stroomtrigger voor na opslaan). In plaats daarvan blijven ze in het object OutboundMessage totdat ze met succes worden verzonden of totdat ze na 24 uur van mislukte levering worden verwijderd.
• Als u een oneindige lus van uitgaande berichten wilt voorkomen, zorgt u ervoor dat de gebruiker die de objecten bijwerkt, niet de machtiging Uitgaande berichten verzenden heeft.

E-mail-naar-case werkt normaal gesproken synchroon. Er is een limiet van vier synchrone threads voor het afhandelen van inkomende e-mail-naar-case-verzoeken. De synchrone vorm van de handler onderhoudt een verbinding met de inkomende Salesforce-mailserver (MTA) die de e-mail ontvangt. Er zijn echter redenen waarom E-mail-naar-case asynchroon kan worden afgehandeld:

• E-mail-naar-case is onderworpen aan threadlimieten, met name 10 threads van handlers per appserver: vier threads voor synchrone verwerking en zes threads voor asynchrone verwerking.
• Als een synchrone e-mailhandler een uitvoeringstijd van 15 seconden overschrijdt, wordt dat specifieke e-mailserviceadres gedurende een periode van 30 minuten gemarkeerd als asynchroon. Volgende verzoeken van de handler voor dat serviceadres resulteren in een bericht dat in de wachtrij wordt geplaatst voor MessageTypeName = MAILCATCHER_EMAIL_TO_CASE, samen met een verwijzing naar de e-mailinhoud.
• Als er al een synchrone thread in gebruik is voor een bepaalde organisatie en een bepaald serviceadres, worden extra verzoeken voor dat serviceadres asynchroon in de wachtrij geplaatst.
• Als een synchroon afgehandeld e-mailbericht een fout ondervindt, zoals een time-out voor rijvergrendeling, wordt het verzoek opgeslagen en asynchroon in de wachtrij geplaatst.
• Als er geen synchrone handlerthreads beschikbaar zijn, wordt het verzoek asynchroon in de wachtrij geplaatst.

• Er is een deduplicatieoptie wanneer u E-mail-naar-case configureert, maar bijlagen worden pas gededupliceerd nadat de e-mail is verwerkt. Deze deduplicatie bespaart ruimte in de database, maar verkort de verwerkingstijden van e-mail niet. U kunt de prestaties echter verbeteren door een aangepaste Apex Email-naar-case-handler voor berichtverwerking te implementeren. Deze implementatie heeft geen invloed op beheerlimieten, maar geeft de handler wel toegang tot het e-mailbericht en alle bijlagen ervan voordat er iets wordt vastgelegd in de database. Met deze toegang kunt u controlesommen berekenen voor alle opgenomen bijlagen en alle bijlagen waarvan u besluit dat ze overbodig zijn, inclusief duplicaten, bekende handtekeningafbeeldingen of ongewenste bestandstypen, negeren.
• Het opnemen van e-mailbijlagen in Salesforce Files is verantwoordelijk voor het grootste deel van de verwerkingstijd van e-mail. Naarmate de antwoorden op of van de contactpersoon toenemen en de e-mailketen groter wordt, wordt de verwerkingstijd voor elke e-mail ook groter. Als de e-mailoptie "Alleen antwoorden met nieuwe inhoud" niet is geselecteerd, worden e-mailketens met elk antwoord groter. Daarom wordt aangeraden om een Apex E-mail-naar-case-handler te gebruiken met logica die het verwijderen van bijlagen implementeert op het moment van verwerking.
• Ondanks de aanroeping van Apex triggers als onderdeel van de afhandeling, zijn E-mail-naar-case handlers vrijgesteld van de gelijktijdige Apex limiet.

Als u grote volumes records asynchroon wilt verwerken, kunt u een van de volgende benaderingen gebruiken.

U kunt Batch Apex gebruiken voor het samenstellen van complexe, langlopende processen waarbij duizenden records zijn betrokken. Batch Apex werkt door uw recordset op te delen en deze te verwerken in beheersbare blokken. U kunt bijvoorbeeld een archiveringsoplossing samenstellen die elke nacht wordt uitgevoerd en records ouder dan een bepaalde datum toevoegt aan een archief. U kunt ook een bewerking voor het opschonen van gegevens samenstellen, die elke nacht alle accounts en opportunities bekijkt en eventuele noodzakelijke updates uitvoert op basis van een set vooraf gedefinieerde criteria.

• Batch Apex is het best in het verwerken van grote hoeveelheden gegevens, omdat asynchrone Apex hogere limieten heeft dan synchrone Apex. Batch Apex werkt ook efficiënter wanneer het meer items per batch verwerkt, omdat het bulkbewerkingen gebruikt die minder overhead veroorzaken door wachtrijbeheer. Als u wilt voorkomen dat het stroomregelingsmechanisme via queue flooding wordt geactiveerd en de dagelijkse asynchrone Apex limiet niet wilt uitputten, maakt u daarom geen batches met een klein bereik of met snelle verwerkingstijden.
• Vermijd batchtaken rechtstreeks in een wachtrij te plaatsen vanuit acties die worden gegenereerd door grote volumes activiteit van eindgebruikers of API-aanroepen voor integratie. Deze benadering kan de flexwachtrij snel uitputten. Als u van plan bent om een batchtaak aan te roepen vanuit een trigger, moet u ervoor zorgen dat de trigger niet meer batchtaken toevoegt dan de limiet.
• Batch Apex is beperkt tot maximaal vijf gelijktijdige threads, wat de doorvoer veel meer beperkt dan toekomstige methoden of Apex met wachtrij.
• Batchtaken waarbij grote hoeveelheden gegevens zijn betrokken, moeten idealiter worden gepland voor uitvoering buiten kantooruren om resources vrij te maken voor processen die realtime of vrijwel realtime reacties vereisen.
• Wanneer u System.scheduleBatch aanroept, plant het platform uw taak voor uitvoering op het door u opgegeven tijdstip. Feitelijke uitvoering vindt plaats op of na dat tijdstip, afhankelijk van beschikbaarheid van de service.
• De planner wordt uitgevoerd in systeemcontext. Alle klassen worden uitgevoerd, ongeacht of de gebruiker die de uitvoering heeft gepland, gemachtigd is om de klasse uit te voeren.
• Alle geplande Apex limieten gelden voor batchtaken die zijn gepland met behulp van System.scheduleBatch. Nadat de batchtaak in de wachtrij is geplaatst (met de status In wachtstand of In wachtrij geplaatst), zijn alle batchtaaklimieten van toepassing en telt de taak niet langer mee voor geplande Apex limieten.
• Denk bij een batchtaak met een terugkerende planning aan de juiste werking als de vorige taak nog steeds wordt uitgevoerd wanneer de nieuwe taak wordt uitgevoerd.
• Batchtaken die vanuit synchrone Apex transacties in een wachtrij zijn geplaatst, gebruiken de flexwachtrij. De flexibele wachtrij is beperkt tot maximaal 100 items op elk punt. Als een transactie probeert meer items toe te voegen, genereert het platform fouten en dient het de batchtaak niet in.
• Aanroepen en andere niet-transactionele bewerkingen van batchtaken moeten rekening houden met idempotente ontwerpoverwegingen. Batchtaken die in de wachtrij zijn geplaatst voordat er een downtime van Salesforce-serviceonderhoud optreedt, blijven in de wachtrij. Nadat de downtime van de service is beëindigd en systeemresources beschikbaar zijn, worden de in de wachtrij geplaatste batchtaken uitgevoerd. Als een batchtaak wordt uitgevoerd wanneer downtime optreedt, wordt de batchuitvoering teruggedraaid en opnieuw gestart nadat de service is hersteld. Omdat uitvoeringsmethoden daarom meerdere malen kunnen worden uitgevoerd, kunnen alle niet-transactieve bewerkingen, zoals aanroepen, opnieuw worden geprobeerd.
• Overweeg het configureren van de batchtaak om BatchApexErrorEvent-events te activeren voor het afhandelen van fout- en uitzonderingsscenario's.

Een door planning geactiveerde stroom is een stroom die is gepland voor uitvoering op een opgegeven tijdstip en met een herhaalde frequentie (dagelijks, wekelijks of eenmalig) voor het uitvoeren van acties op een batch records. (Voorbeeld: werk een veld in alle gevallen bij met de status "Open" om 2 uur 's nachts.) Geplande stromen worden uitgevoerd via het cron-triggermechanisme en worden in bulk verwerkt.

• Een door planning geactiveerde stroom voert 200 records per aanroep uit, maar wordt uitgevoerd met meerdere gelijktijdige threads als er meer dan 200 records aanwezig zijn.
• Door planning geactiveerde stromen worden uitgevoerd in een synchrone context met synchrone limieten.
• Er is momenteel geen manier om het aantal records te bepalen dat per geplande stroomaanroep wordt verwerkt. Als de uitvoering betrekking heeft op meer dan 200 records, bestaat er een reëel gevaar van gelijktijdige Apex fouten.

Bulk-API is gebaseerd op REST-principes en is geoptimaliseerd voor het werken met grote sets gegevens. U kunt het gebruiken om asynchroon vele records in te voegen, bij te werken, upsert, op te vragen of te verwijderen en de resultaten later te verwerken. Het Salesforce Platform verwerkt het verzoek op de achtergrond. De SOAP-API en REST-API gebruiken daarentegen synchrone verzoeken en zijn geoptimaliseerd voor realtime clienttoepassingen die slechts enkele records tegelijk bijwerken. U kunt beide API's gebruiken voor de verwerking van vele records, maar wanneer de gegevenssets honderdduizenden records bevatten, zijn ze minder praktisch. Het asynchrone framework van de Bulk-API is ontworpen om het verwerken van gegevens van enkele duizenden tot miljoenen records eenvoudig en efficiënt te maken.

De gemakkelijkste manier om de Bulk-API te gebruiken is deze in te schakelen voor het verwerken van records in Data Loader met behulp van CSV-bestanden. Met Data Loader hoeft u niet uw eigen clientapp te schrijven. Soms vereisen unieke vereisten echter het schrijven van een aangepaste app.

Er zijn twee Bulk-API's beschikbaar binnen het Salesforce Platform.

• Bulk-API 2.0 is de nieuwere API. Het biedt een gestroomlijnde en gebruiksvriendelijke werkstroom en is de focus voor uitbreidingen.
• De oorspronkelijke Bulk-API wordt nog steeds volledig ondersteund, maar wordt niet langer verbeterd. U wordt aangeraden om Bulk-API 2.0 te gebruiken waar mogelijk.

Zie Bulk-API-limieten en Bulk-API 2.0-limieten voor meer informatie over API-limieten.

Raadpleeg deze handleiding bij het samenstellen van of overwegen van asynchrone verwerking op het Salesforce Platform. Het is altijd een goed idee om inzicht te krijgen in het volledige scala aan opties dat voor u beschikbaar is, en hoe deze kunnen aansluiten op uw specifieke gebruikscase. Zorg ervoor dat u uw huidige landschap grondig beoordeelt voordat u wijzigingen aanbrengt in uw bestaande architecturen, vooral als uw huidige oplossing goed werkt.