Salesforce Apex-veiledning for nybegynnere

Apex hjelper utviklere med å legge til forretningslogikk i systemhendelser som knappeklikk, relaterte postoppdateringer og Visualforce-sider. Apex har en syntaks som ligner på Java. Registrer deg for Salesforce for å lære hvordan CRM-systemet fungerer.

Funksjoner i Apex programmeringsspråk

Her er de viktige funksjonene til Salesforce Apex:

• Apex er et språk som ikke skiller mellom store og små bokstaver.
• Du kan utføre DML-operasjoner som INSERT, UPDATE, UPSERT og DELETE på sObject-poster ved hjelp av Apex.
• Du kan spørre sObject-poster ved hjelp av SOQL (Salesforce Object Query Language) og SOSL (Salesforce Object Search Language) i Apex.
• Lar deg lage en enhetstest og utfør den for å bekrefte kodedekning og effektiviteten til koden i Apex.
• Apex kjøres i et miljø med flere leietakere, og Salesforce har definerte styregrenser som hindrer en bruker i å monopolisere de delte ressursene. All kode som krysser en Salesforce-styregrense mislykkes, og det vises en feil.
• Et Salesforce-objekt kan brukes som en datatype i Apex. For eksempel:

  Account acc = new Account();

  Her er Konto et standard Salesforce-objekt.

• Apex oppgraderer automatisk med hver Salesforce-utgivelse.

Når bør en utvikler velge Apex?

Apex-kode bør bare skrives hvis et forretningsscenario er for komplekst til å implementeres ved hjelp av den forhåndsbygde pek-og-klikk-funksjonaliteten som tilbys av Salesforce.

Følgende er noen scenarier der du må skrive Apex-kode:

• For å lage webtjenester som integrerer Salesforce med andre applikasjoner.
• For å implementere tilpasset validering på sObjects.
• For å utføre tilpasset Apex-logikk når en DML-operasjon utføres.
• Å implementere funksjonalitet som ikke kan bygges med eksisterende deklarative automatiseringsverktøy som Flow.
• Å sette opp e -posttjenester som behandler innholdet, overskriftene og vedleggene i innkommende e-post.

Når du vet når Apex er det riktige valget, er neste trinn å forstå hva som skjer med koden din etter at du lagrer den.

Arbeidsstrukturen til Apex

Følgende er handlingsflyten for Apex-kode:

• Utviklerhandling: Når utvikleren lagrer kode på plattformen, kompileres all Apex-koden til et sett med instruksjoner som Apex-kjøretidstolken kan forstå, og disse instruksjonene lagres deretter som metadata på plattformen.
• Sluttbrukerhandling: Når en brukerhendelse utfører Apex-kode, henter plattformserveren de kompilerte instruksjonene fra metadataene og kjører dem gjennom Apex-tolkeren før resultatet returneres.

Diagrammet nedenfor viser hvordan utvikler- og sluttbrukerhandlingene samhandler med Lightning Platform-applikasjonsserveren:

Apex utviklingsmiljø

Apex-kode kan utvikles enten i en sandkasse eller i en Developer Edition-organisasjon av Salesforce.

Det er lurt å utvikle koden i et sandkassemiljø og deretter distribuere den til produksjonsmiljøet, som illustrert nedenfor:

Apex-kodeutviklingsverktøy: Følgende er de tre verktøyene som er tilgjengelige for å utvikle Apex-kode i alle versjoner av Salesforce:

• Utviklerkonsoll
• Visual Studio Code med Salesforce Extension Pack (dette erstatter den utgåtte Force.com IDE-en)
• Code redigeringsprogrammet i brukergrensesnittet for Salesforce-oppsettet

Når miljøet ditt er klart, la oss se på byggeklossene i selve språket, og starte med datatyper.

Datatyper i Apex

Følgende er datatypene som støttes av Apex:

Primitive

Heltall, Double, Long, Date, Datetime, Decimal, Time, Blob, String, ID og Boolean regnes som primitive datatyper. Alle primitive datatyper sendes etter verdi, ikke etter referanse.

Kategorier

Tre typer samlinger er tilgjengelige i Apex:

• Liste: Det er en ordnet samling av primitiver, sObjects, samlinger eller Apex-objekter basert på indekser.
• Sett: En uordnet samling av unike elementer som ikke inneholder duplikater.
• Kart: Det er en samling av unike nøkler som tilordnes til enkeltverdier, som kan være primitiver, sObjects, samlinger eller Apex-objekter.

sObjekt

Dette er en spesiell datatype i Salesforce. Det ligner på et bord i SQL og inneholder felt som ligner på kolonner i SQL.

Opptegnelser

En enum er en magemuskeltract-datatype som lagrer én verdi av et endelig sett med spesifiserte identifikatorer.

Klasser, objekter og grensesnitt

Brukerdefinerte Apex-klasser og -grensesnitt kan også brukes som datatyper. Et objekt refererer til en forekomst av en hvilken som helst datatype som støttes i Apex.

Apex-syntaks

Variabel erklæring

Siden Apex er et språk med sterk typede egenskaper, er det obligatorisk å deklarere en variabel med en datatype i Apex.

For eksempel:

Contact con = new Contact();

Her deklareres variabelen con med Contact som datatype.

SOQL-spørring

SOQL står for Salesforce Object Query Language. SOQL brukes til å hente sObject-poster fra Salesforce-databasen. For eksempel:

Account acc = [SELECT Id, Name FROM Account LIMIT 1];

Spørringen ovenfor henter en kontopost fra Salesforce-databasen.

Loop Statement

En løkkesetning brukes til å iterere over postene i en liste. Antall iterasjoner er lik antall poster i listen. For eksempel:

List<Account> listOfAccounts = [SELECT Id, Name FROM Account LIMIT 100];
// iteration over the list of accounts
for(Account acc : listOfAccounts){
	//your logic
}

I kodebiten ovenfor er listOfAccounts en variabel av datatypen List.

Flytkontrollerklæring

En flytkontrollsetning er nyttig når du vil kjøre noen linjer med kode basert på visse betingelser.

For eksempel:

List<Account> listOfAccounts = [SELECT Id, Name FROM Account LIMIT 100];
// execute the logic if the size of the account list is greater than zero
if(listOfAccounts.size() > 0){
	//your logic
}

Kodebiten ovenfor spør etter kontoposter fra databasen og kontrollerer listestørrelsen.

DML-erklæring

DML står for Data Manipulation Language. DML-setninger brukes til å manipulere data i Salesforce-databasen. For eksempel:

Account acc = new Account(Name = 'Test Account');
insert acc; //DML statement to create account record.

Apex Access-spesifikasjoner

Følgende er tilgangsspesifikasjonene som støttes av Apex:

offentlig

Denne tilgangsspesifikatoren gir tilgang til en klasse, metode eller variabel som skal brukes av Apex i et navneområde.

Privat

Denne tilgangsspesifikatoren gir tilgang til en klasse, metode eller variabel som skal brukes lokalt, eller innenfor den delen av koden der den er definert. Alle metoder og variabler som ikke har en definert tilgangsspesifikator, tar standard tilgangsspesifikatoren private.

beskyttet

Denne tilgangsspesifikatoren gir tilgang til en metode eller variabel som skal brukes av alle indre klasser innenfor den definerende Apex-klassen.

Global

Denne tilgangsspesifikatoren gir tilgang til en klasse, metode eller variabel som skal brukes av Apex innenfor et navneområde så vel som utenfor navneområdet. Det er god praksis å ikke bruke det globale nøkkelordet med mindre det er nødvendig.

Nøkkelord i Apex

Med deling

Hvis en klasse er definert med dette nøkkelordet, håndheves alle delingsreglene som gjelder for den gjeldende brukeren. Hvis dette nøkkelordet mangler, kjøres koden under systemkontekst.

For eksempel:

public with sharing class MyApexClass{
// sharing rules enforced when code in this class executes
}

Uten å dele

Hvis en klasse er definert med dette nøkkelordet, håndheves ikke delingsreglene som gjelder for den gjeldende brukeren.

For eksempel:

public without sharing class MyApexClass{
// sharing rules are not enforced when code in this class executes
}

Statisk

En variabel eller metode definert med nøkkelordet static initialiseres én gang og assosieres med klassen. Statiske variabler og metoder kan kalles direkte med klassenavnet uten å opprette en instans av klassen.

Slutten

En konstant eller metode definert med nøkkelordet final kan ikke overstyres. For eksempel:

public class myCls {
static final Integer INT_CONST = 10;
}

Hvis du prøver å overstyre verdien til denne INT_CONST-variabelen, vil du få unntaket – System.FinalException: Den endelige variabelen er allerede initialisert.

Tilbake

Dette nøkkelordet returnerer en verdi fra en metode. For eksempel:

public String getName() {
return 'Test';
}

Null

Den definerer en nullkonstant og kan tilordnes en variabel. For eksempel:

Boolean b = null;

virtuelle

Hvis en klasse er definert med nøkkelordet virtual, kan den utvides og overstyres.

Abstract

Hvis en klasse er definert med abstract-nøkkelordet, må det inneholde minst én metode med nøkkelordet abstract, og den metoden skal bare ha en signatur.

For eksempel:

public abstract class MyAbstractClass {
abstract Integer myAbstractMethod1();
}

Apex-streng

En streng er et sett med tegn uten tegnbegrensning. For eksempel:

String name = 'Test';

Det finnes flere innebygde metoder i String-klassen i Salesforce. Følgende er noen ofte brukte metoder:

forkorte (maxWidth)

Denne metoden avkorter en streng til den angitte lengden og returnerer den hvis lengden på den gitte strengen er lengre enn den angitte lengden; ellers returnerer den den opprinnelige strengen. Hvis verdien av maxWidth-variabelen er mindre enn 4, kaster denne metoden et kjøretidsunntak – System.StringException: Minimum forkortelsesbredde er 4.

For eksempel:

String s = 'Hello World';
String s2 = s.abbreviate(8);
System.debug('s2: ' + s2); //Hello...

kapitaliser ()

Denne metoden konverterer den første bokstaven i en streng til store og små bokstaver og returnerer den.

For eksempel:

String s = 'hello';
String s2 = s.capitalize();
System.assertEquals('Hello', s2);

inneholder (understreng)

Denne metoden returnerer sann hvis strengen som kaller metoden inneholder den angitte delstrengen.

String name1 = 'test1';
String name2 = 'test';
Boolean flag = name1.contains(name2);
System.debug('flag:: ' + flag); //true

lik(stringOrId)

Denne metoden returnerer sann hvis parameteren som sendes ikke er null og representerer den samme binære tegnsekvensen som strengen som kaller metoden.

Når man sammenligner ID-verdier, kan det hende at lengden på ID-ene ikke er like. Hvis for eksempel en streng som representerer en ID på 15 tegn sammenlignes med et objekt som representerer en ID på 18 tegn, returnerer denne metoden fortsatt sann. For eksempel:

String stringValue15 = '001D000000Ju1zH';
Id idValue18 = '001D000000Ju1zHIAR';
Boolean result = stringValue15.equals(idValue18);
System.debug('result: ' + result); //true

I eksemplet ovenfor sammenligner equals-metoden en objekt-ID på 15 tegn med en objekt-ID på 18 tegn, og hvis begge ID-ene representerer den samme binære sekvensen, returnerer den sann.

Bruk denne metoden for å gjøre sammenligninger som skiller mellom store og små bokstaver.

escapeSingle Quotes(stringToEscape)

Denne metoden legger til et escape-tegn (\) foran et enkelt anførselstegn i en streng og returnerer resultatet. Denne metoden forhindrer SOQL-injeksjon når man oppretter en dynamisk SOQL-spørring. Den sikrer at alle enkelt anførselstegn behandles som omsluttende strenger i stedet for databasekommandoer.

For eksempel:

String s = 'Hello \'Tom\'';
String escapedStr = String.escapeSingleQuotes(s);
System.debug(escapedStr); // Outputs Hello \'Tom\'

fjern (understreng)

Denne metoden fjerner alle forekomster av den nevnte delstrengen fra strengen som kaller metoden og returnerer den resulterende strengen.

For eksempel:

String s1 = 'Salesforce and force.com';
String s2 = s1.remove('force');
System.debug('s2: ' + s2); // 'Sales and .com'

understreng(startindeks)

Denne metoden returnerer en delstreng som starter fra tegnet i startindeksen og fortsetter til slutten av strengen.

For eksempel:

String s1 = 'hamburger';
String s2 = s1.substring(3);
System.debug('s2: ' + s2); //burger

omvendt()

Denne metoden reverserer alle tegnene i en streng og returnerer den. For eksempel:

String s = 'Hello';
String s2 = s.reverse();
System.debug('s2:::: ' + s2); // olleH

listverk ()

Denne metoden fjerner alle innledende og etterfølgende mellomrom fra en streng og returnerer den.

valueOf(toConvert)

Denne metoden returnerer strengrepresentasjonen av det sendte objektet.

Strenger, klasser og nøkkelord kommer sammen når du begynner å pakke logikk til gjenbrukbare enheter, og det er nettopp det Apex-klasser er til for.

Apex klasse

En Apex-klasse er en blåkopi eller mal som objekter opprettes fra. Et objekt er en forekomst av en klasse.

Det finnes tre måter å opprette Apex-klasser i Salesforce på:

• Utviklerkonsoll
• Visual Studio Code med Salesforce-utvidelsespakken
• Apex-klassedetaljside i Oppsett

I Apex kan du definere en ytre klasse, også kalt en toppnivåklasse, og du kan også definere klasser innenfor en ytre klasse, kalt indre klasser.

Det er obligatorisk å bruke en tilgangsmodifikator som global eller public i deklarasjonen av en ytre klasse.

Det er ikke nødvendig å bruke en tilgangsmodifikator i deklarasjonen av indre klasser.

En Apex-klasse defineres ved hjelp av nøkkelordet class etterfulgt av klassenavnet.

Nøkkelordet extends brukes til å utvide en eksisterende klasse i en Apex-klasse, og nøkkelordet implements brukes til å implementere et grensesnitt i en Apex-klasse.

Salesforce Apex støtter ikke multippel arv; en Apex-klasse kan bare utvide én eksisterende Apex-klasse, men kan implementere flere grensesnitt.

En Apex-klasse kan inneholde en brukerdefinert konstruktør, og hvis en brukerdefinert konstruktør ikke er tilgjengelig, brukes en standardkonstruktør. Koden i en konstruktør kjøres når en forekomst av en klasse opprettes.

Syntaks for en Apex-klasse:

public class myApexClass{
// variable declaration
//constructor
	public myApexClass(){
	}
//methods declaration
}

Nøkkelordet new brukes til å opprette en forekomst av en Apex-klasse. Nedenfor finner du syntaksen for å opprette en forekomst av en Apex-klasse:

myApexClass obj = new myApexClass();

Apex Getter og Setter

En Apex-egenskap ligner på en Apex-variabel. En getter og en setter er nødvendige for en Apex-egenskap. De kan brukes til å kjøre kode før egenskapsverdien åpnes eller endres. Koden i get-tilgangen kjøres når en egenskapsverdi leses. Koden i set-tilgangen kjøres når en egenskapsverdi endres. Enhver egenskap som bare har en get-tilgang regnes som skrivebeskyttet, en hvilken som helst egenskap som bare har en set-tilgang regnes som skrivebeskyttet, og en hvilken som helst egenskap som har både get- og set-tilgang regnes som lese-skrive. Syntaks for en Apex-egenskap:

public class myApexClass {
// Property declaration
	access_modifier return_type property_name {
	get {
			//code
		}
		set{
			//code
		}
	}
}

Her er access_modifier tilgangsmodifikatoren til egenskapen, return_type er datatypen til egenskapen, og property_name er navnet på egenskapen.

Nedenfor er et eksempel på en Apex-egenskap som har både get- og set-tilgangsenheter:

public class myApex{
	public String name{
		get{ return name; }
		set{ name = value; }
	}
}

Her er egenskapsnavnet navn, det er en offentlig egenskap, og den returnerer en String-datatype.

Det er ikke obligatorisk å ha kode i get- og set-blokkene. Disse blokkene kan stå tomme for å definere en automatisk egenskap. For eksempel:

public double MyReadWriteProp{ get; set; }

Get- og set-tilgangsgrupper kan også defineres med egne tilgangsmodifikatorer. Hvis en tilgangsgruppe er definert med en modifikator, overstyrer den tilgangsmodifikatoren til egenskapen. For eksempel:

public String name{private get; set;}// name is private for read and public for write.

Klasser definerer gjenbrukbar logikk som du kaller eksplisitt. Utløsere, som dekkes nedenfor, kjøres automatisk når poster endres.

Apex Trigger

Apex-utløsere lar deg kjøre tilpasset Apex før og etter at en DML-operasjon er utført.

Apex støtter følgende to typer triggere:

Før triggere: Disse utløserne brukes til å validere og oppdatere verdien til et felt før posten lagres i databasen.

Etter triggere: Disse utløserne brukes til å få tilgang til feltverdier (som post-ID og LastModifiedDate-feltet) som angis av systemet etter at en post er lagret i databasen. Disse feltverdiene kan brukes til å endre andre poster. Poster som utløses etter utløsere er skrivebeskyttet.

Det er god praksis å skrive masseutløsere. En masseutløser kan behandle én enkelt post så vel som flere poster samtidig.

Syntaks for en Apex-utløser:

trigger TriggerName on ObjectName (trigger_events) {
	//Code_block
 }

Her er TriggerName navnet på utløseren, ObjectName er navnet på objektet som utløseren er skrevet på, og trigger_events er en kommaseparert liste over hendelser.

Følgende er hendelsene som støttes av Apex-utløsere: før innsetting, før oppdatering, før sletting, etter innsetting, etter oppdatering, etter sletting, etter angret sletting.

Statiske nøkkelord kan ikke brukes i en Apex-utløser. Alle nøkkelordene som gjelder for indre klasser kan brukes i en Apex-utløser.

Det finnes implisitte variabler definert av hver utløser som returnerer kjøretidskonteksten. Disse variablene er definert i System.Trigger-klassen og kalles kontekstvariabler. De to skjermbildene nedenfor viser kontekstvariablene som støttes av Apex-utløsere:

Følgende er hensynene for kontekstvariabler i Apex-utløsere:

• Ikke bruk trigger.new og trigger.old i DML-operasjoner.
• Trigger.new kan ikke slettes.
• Trigger.new er skrivebeskyttet etter triggere.
• Trigger.new kan brukes til å endre verdiene til felt på samme objekt, kun før triggere.

De to skjermbildene nedenfor viser hva man bør vurdere om man skal gjøre i ulike utløserhendelser:

Utløsere håndterer sanntidslogikk, men noen jobber er rett og slett for store for en enkelt transaksjon. Det er her batch-Apex kommer inn i bildet.

Batch-klasse i Apex

En batchklasse i Salesforce brukes til å behandle et stort antall poster som ville overskride Apex-styregrensene hvis de ble behandlet normalt. En batchklasse kjører koden asynkront.

Følgende er fordelene med en batchklasse:

• En batchklasse behandler dataene i deler, og hvis én del ikke behandles, blir ikke de vellykkede delene rullet tilbake.
• Hver datadel i en batchklasse behandles med et nytt sett med guvernørgrenser, som sikrer at koden kjøres innenfor guvernørens utførelsesgrenser.

Database.Batchable-grensesnittet må implementeres av en Apex-klasse for å kunne brukes som en batchklasse. Det tilbyr tre metoder som må implementeres av batchklassen:

1. start()

Denne metoden genererer omfanget av poster eller objekter som skal behandles av grensesnittmetoden execute. Den kalles bare én gang under kjøringen av batchen. Denne metoden returnerer enten et Database.QueryLocator-objekt eller en Iterable. Antall poster som kan hentes av en SOQL-spørring ved hjelp av Database.QueryLocator-objektet er 50 millioner, men ved bruk av en Iterable er det totale antallet poster som kan hentes av SOQL-spørringen bare 50 000. En Iterable brukes til å generere et komplekst omfang for batchklassen.

Syntaks for startmetoden:

global (Database.QueryLocator | Iterable<sObject>) start(Database.BatchableContext bc) {}

2. utfør()

Denne metoden brukes til å behandle hver dataenhet. Utførelsesmetoden kalles for hver dataenhet. Standard batchstørrelse for utførelse er 200 poster. Utførelsesmetoden tar to argumenter:

En referanse til Database.BatchableContext-objektet,

En liste over sObjects, for eksempel List , eller en liste over parameteriserte typer. Syntaks for execute-metoden:

global void execute(Database.BatchableContext bc, List<P> records){}

3. ferdig()

Finish-metoden kalles én gang under utførelsen av batchklassen. Etterbehandlingsoperasjoner kan utføres i Finish-metoden. For eksempel: sending av en bekreftelses-e-post. Denne metoden kalles når alle batchene er behandlet. Syntaks for Finish-metoden:

global void finish(Database.BatchableContext bc){}

Database.BatchableContext-objekt

Hver metode i Database.Batchable-grensesnittet har en referanse til et Database.BatchableContext-objekt.

Dette objektet brukes til å track fremdriften til batchjobben.

Følgende er instansmetodene som tilbys av BatchableContext:

• getChildJobId(): Denne metoden returnerer ID-en til batchjobben som behandles.
• getJobId(): Denne metoden returnerer IDen til batchjobben.

Nedenfor er syntaksen til en batchklasse:

global class MyBatchClass implements Database.Batchable<sObject> {
	global (Database.QueryLocator | Iterable<sObject>) start(Database.BatchableContext bc) {
// collect the batches of records or objects to be passed to execute
}
global void execute(Database.BatchableContext bc, List<P> records){
// process each batch of records
}
global void finish(Database.BatchableContext bc){
// execute any post-processing operations
}
}

Database.executeBatch-metode

Database.executeBatch-metoden brukes til å kjøre en batch-klasse.

Denne metoden tar to parametere: en forekomst av batchklassen som skal behandles, og en valgfri omfangsparameter for å spesifisere batchstørrelsen. Hvis den ikke er spesifisert, brukes standardstørrelsen på 200.

Syntaks for Database.executeBatch:

Database.executeBatch(myBatchObject, scope)

Utfører en batchklasse kalt MyBatchClass:

MyBatchClass myBatchObject = new MyBatchClass();
Id batchId = Database.executeBatch(myBatchObject, 100);

Database.Stateful

En batchklasse er som standard tilstandsløs. Hver gang execute-metoden kalles, mottas en ny kopi av objektet, og alle variablene i klassen initialiseres.

Database.Stateful er implementert for å gjøre en batchklasse tilstandsfull.

Hvis batchklassen din implementerer Database.Stateful-grensesnitt, alle instansvariablene beholder verdiene sine, men statiske variabler tilbakestilles mellom transaksjoner.

Asynkron Apex Beyond Batch

Batch Apex er bare én av flere måter å kjøre kode asynkront på. Salesforce tilbyr fire asynkrone alternativer, og valget av det riktige avhenger av hvor mye data du behandler og om jobber må kjedes eller planlegges.

• Fremtidige metoder: Disse er annotert med @future, og er best for enkle operasjoner man bare kan avfyre ​​og glemme, som for eksempel utkall til eksterne webtjenester.
• Købar Apex: Implementerer Queueable-grensesnittet, godtar komplekse objekttyper, returnerer en jobb-ID og støtter kjedekobling av én jobb til en annen.
• Batch Apex: Behandler svært store datamengder i deler, som beskrevet ovenfor.
• Planlagt topp: Implementerer det planlagte grensesnittet slik at en klasse kjører på et bestemt tidspunkt, for eksempel en nattlig oppryddingsjobb.

typen	Best For	Nøkkelevne
Fremtidig metode	Enkle oppfordringer	Brann og glem
Købar Apex	Sekvensiell prosessering	Jobbkjede og overvåking
Batch Apex	Millioner av poster	Delvis prosessering
Planlagt Apex	Gjentakende jobber	Cron-basert timing

Uansett hvilken utførelsesmodell du velger, måles hver transaksjon fortsatt mot de plattformomfattende styringsgrensene som er oppført nedenfor.

Apex-guvernørgrenser

Apex-regulatorgrenser er grensene som håndheves av Apex-kjøretidsmotoren for å sikre at eventuell Apex-kode og -prosesser som ikke fungerer, ikke monopoliserer de delte ressursene og ikke forstyrrer behandlingen til andre brukere i flerleietakermiljøet. Disse grensene verifiseres mot hver Apex-transaksjon. Følgende er regulatorgrensene som er definert av Salesforce for hver Apex-transaksjon:

Tekniske beskrivelser	Grense
SOQL-spørringer som kan gjøres i en synkron transaksjon	100
SOQL-spørringer som kan utføres i en asynkron transaksjon	200
Poster som kan hentes med en SOQL-spørring	50,000
Poster som kan hentes av Database.getQueryLocator	10,000
SOSL-spørringer som kan utføres i en Apex-transaksjon	20
Poster som kan hentes ved en SOSL-spørring	2,000
DML-setninger som kan gjøres i en Apex-transaksjon	150
Poster som kan behandles som et resultat av en DML-setning, Approval.process eller database.emptyRecycleBin	10,000
Utrop som kan gjøres i en Apex-transaksjon	100
Kumulativ tidsavbruddsgrense for alle utrop som utføres i en Apex-transaksjon	120 sekunder
Begrensning på Apex-jobber som kan legges til i køen med System.enqueueJob	50
Utførelsestidsgrense for hver Apex-transaksjon	10 minutter
Begrensning på tegn som kan brukes i en Apex-klasse og -utløser	1 millioner
CPU-tidsgrense for en synkron transaksjon	10,000 millisekunder
CPU-tidsgrense for en asynkron transaksjon	60,000 millisekunder
Total heapstørrelse	6 MB (synkron) / 12 MB (asynkron)

Slik skriver du en testklasse i Apex

Salesforce krever at minst 75 prosent av Apex-koden din dekkes av enhetstester før du kan distribuere den til produksjon, og hver utløser må ha en viss dekning. Å skrive testklasser er derfor en sentral Apex-ferdighet, ikke et valgfritt tillegg.

En testklasse er annotert med @isTest, og hver testmetode er også merket med @isTest. Testmetoder lagrer ikke data i databasen og ser ikke de fleste eksisterende organisasjonsdata, så hver test oppretter sine egne poster. Metodene Test.startTest() og Test.stopTest() gir koden som testes et nytt sett med styregrenser, og påstander bekrefter at logikken oppførte seg som forventet.

Her er en enkel testklasse for logikk for kontooppretting:

@isTest
private class AccountHandlerTest {
    @isTest
    static void testCreateAccount() {
        Account acc = new Account(Name = 'Test Account');
        Test.startTest();
        insert acc;
        Test.stopTest();
        Account result = [SELECT Id, Name FROM Account WHERE Id = :acc.Id];
        System.assertEquals('Test Account', result.Name);
    }
}

Følg disse retningslinjene når du skriver tester:

• Bruk @testSetup-metoden til å opprette delte testdata én gang for alle testmetodene i klassen.
• Test masseoppførsel ved å sette inn 200 poster, ikke bare én.
• Dekk positive, negative og brukerbegrensede scenarioer.
• Inkluder alltid meningsfulle System.assert-setninger; dekning uten påstander beviser ingenting.

Apex beste praksis

Nybegynnere skriver ofte Apex som fungerer for én post, men som mislykkes i reelle bulkoperasjoner. Fremgangsmåtene nedenfor holder koden innenfor kontrollørgrensene og er enklere å vedlikeholde:

• Massiviser alt: Skriv logikk som håndterer samlinger av poster, fordi utløsere kan motta opptil 200 poster i en enkelt batch.
• Hold SOQL og DML utenfor løkker: Spør før løkken, samle inn endringer i en liste og utfør én DML-setning etter løkken.
• Én trigger per objekt: Hold utløsere logikkfrie og deleger arbeidet til handlerklasser, noe som gjør rekkefølgen på utførelse forutsigbar.
• Bruk med deling: Håndhev sikkerhet på postnivå med mindre det finnes en dokumentert grunn til å kjøre i systemkontekst.
• Unngå hardkoding av ID-er: Post-ID-er varierer mellom sandkasser og produksjon, så spør etter dem eller bruk tilpassede metadata i stedet.
• Overvåk grenser i kode: Metodene i Limits-klassen, som for eksempel Limits.getQueries(), lar deg sjekke ressursforbruket under kjøretid.

👍 Tips: Kjør koden din mot 200 poster i en sandkasse før du distribuerer den. De fleste feil i styresgrenser oppstår bare ved bulkvolum, og det er mye billigere å oppdage dem tidlig enn å feilsøke dem i produksjon.

Spørsmål og svar