Salesforce lar oss behandle eller utføre et bestemt antall uttalelser/poster om gangen. Det er noen grenser for DML -uttalelser, Apex -klasser osv., å utføre eller prosess. Disse grensene er kjent som guvernørgrenser. I denne opplæringen vil vi se hva guvernøren er og hvordan de kan håndteres. Salesforce Apex gir også "grense" -klassen for å kjenne grensene som er relatert til utrop, Apex -klasser, Lightning Web Components, SOSL og SOQL -uttalelser.
Guvernørgrenser
Tenk på et scenario der Alish og Subash er to personer som bruker Salesforce Org. Alice ønsker å behandle eller utføre 1000 DML -setninger i en transaksjon. Parallelt ønsker Subash å laste inn 5000 poster om gangen. Hvis de gjør det parallelt, vil Salesforce ikke akseptere og blir hektisk. Derfor kommer guvernørgrensene inn i bildet. I dette tilfellet kan Alish behandle 100 DML om gangen og Subash kan behandle 500 poster om gangen. De kan bruke AsynchronousBatch -spissen for å gjøre hver transaksjon på en egen tråd uten å forstyrre hver av dem og fullføre oppgaven sin.
I utgangspunktet begrenser guvernøren i Salesforce behandlingen og utførelsen i flere transaksjoner. "Per-transaksjons toppens grenser" teller for hver transaksjon og "størrelsesspesifikk Apex-grense" omhandler størrelsen på koden. Salesforce støtter to prosesser: synkrone og asynkrone prosesser. I den synkrone prosessen blir Apex -skriptet utført i en enkelt gang mens du er i den asynkrone prosessen, blir Apex -skriptet utført ved å dele opp i flere jobber.
Tillatt grenser
La oss diskutere grensetellingen for forskjellige scenarier:
Begrens klasseeksempel:
Apex kan spesifisere guvernørgrensene i "grensen" -klassen. Denne klassen gir noen metoder som forteller guvernørgrensene. La oss se på følgende eksempel som viser noen guvernørgrenser:
System.Debug ('Antall samlede spørsmål kan behandles:'+ grenser.getLimitAggregateQueries ());Produksjon:
Det kan også være mulig å sjekke hvor mange DML -setninger/rader som kan returneres ved hjelp av "kuppelen" -metodene som er til stede i "grense" -klassen.
Brukseksempel:
La oss skrive en SOQL -spørring som returnerer de to postene fra "Workorder" -objektet. Etter det, slett disse to postene ved å bruke “Slett” DML.
System.Debug ('DML -setninger:'+grenser.getDmlStatements ());Produksjon:
I det gitte eksemplet er det ingen DML -setninger og 0 rader. Den eksisterende CPU -tiden er 1 millisekunder. Etter å ha returnert 2 rader fra SOQL -spørringen og slettet disse to radene, er det totale antallet DML -setninger som returneres av grensene.getDmlStatements () er 1, de totale radene som returneres av grensene.getDmlrows () er 2, og CPU -tiden som er nødvendig for å utføre denne transaksjonen er 51 millisekunder.
Eksempel på beste praksis: "Bruk aldri DML inne i løkken"
La oss se hvordan vi kan kjøre koden uten å få guvernørgrensen. Vi oppretter først en post på "Produkt" -objektet (API - Product2) fra "Workorder" -objektet ved å tilordne "Workorder" underlagt "produktnavnet" i "for" -sløyfen i seg selv. La oss se følgende kode:
Product2 PROD_OBJ;Vi kan gjøre dette på en bedre måte ved å erklære en liste (prod_s) og deretter lagre prod_obj på listen. Vi kan sette inn denne listen i produktet utenfor løkken.
Liste prod_s = new List ();Konklusjon
Vi lærte nå hvilke spissgrenser som er i Salesforce med en detaljert forklaring. Det er bedre å gå med den asynkrone Apex -prosessen for å få bedre guvernørgrenser sammenlignet med synkron spiss. Vi lærte også om guvernørgrensene for forskjellige scenarier og ga en eksempler på demonstrasjonen angående grensetallet fra "grense" -klassen. Vi bekreftet også antallet DML -uttalelser, rader og CPU -tid ved å kjøre en DML -setning. Vi konkluderte med denne guiden ved å diskutere ett eksempler på beste praksis.