Salesforce Apex-vejledning for begyndere

Apex hjælper udviklere med at tilføje forretningslogik til systemhændelser som knapklik, relaterede postopdateringer og Visualforce-sider. Apex har en syntaks, der ligner Java. Tilmeld dig Salesforce for at lære, hvordan CRM fungerer.

Funktioner i Apex-programmeringssproget

Her er de vigtige funktioner i Salesforce Apex:

• Apex er et sprog, der ikke skelner mellem store og små bogstaver.
• Du kan udføre DML-operationer som INSERT, UPDATE, UPSERT og DELETE på sObject-poster ved hjælp af Apex.
• Du kan forespørge sObject-poster ved hjælp af SOQL (Salesforce Object Query Language) og SOSL (Salesforce Object Search Language) i Apex.
• Giver dig mulighed for at oprette en enhedstest og udfør den for at verificere kodedækning og effektiviteten af ​​koden i Apex.
• Apex udføres i et miljø med flere lejere, og Salesforce har definerede styregrænser, der forhindrer en bruger i at monopolisere de delte ressourcer. Enhver kode, der overskrider en Salesforce-styregrænse, fejler, og der vises en fejl.
• Et Salesforce-objekt kan bruges som en datatype i Apex. For eksempel:

  Account acc = new Account();

  Her er Konto et standard Salesforce-objekt.

• Apex opgraderer automatisk med hver Salesforce-udgivelse.

Hvornår bør en udvikler vælge Apex?

Apex-kode bør kun skrives, hvis et forretningsscenarie er for komplekst til at blive implementeret ved hjælp af den præbyggede peg-og-klik-funktionalitet, der leveres af Salesforce.

Følgende er et par scenarier, hvor du skal skrive Apex-kode:

• At skabe webtjenester, der integrerer Salesforce med andre applikationer.
• At implementere brugerdefineret validering på sObjects.
• At udføre brugerdefineret Apex-logik, når en DML-handling udføres.
• At implementere funktionalitet, der ikke kan bygges med eksisterende deklarative automatiseringsværktøjer som f.eks. Flow.
• At oprette e -mail -tjenester der behandler indholdet, overskrifterne og vedhæftede filer i indgående e-mails.

Når du ved, hvornår Apex er det rigtige valg, er næste skridt at forstå, hvad der sker med din kode, når du har gemt den.

Apex' arbejdsstruktur

Følgende er handlingsforløbet for Apex-kode:

• Udviklerhandling: Når udvikleren gemmer kode på platformen, kompileres al Apex-koden til et sæt instruktioner, som Apex runtime-fortolkeren kan forstå, og disse instruktioner gemmes derefter som metadata på platformen.
• Slutbrugerhandling: Når en brugerhændelse udfører Apex-kode, henter platformserveren de kompilerede instruktioner fra metadataene og kører dem gennem Apex-fortolkeren, før resultatet returneres.

Diagrammet nedenfor viser, hvordan udvikler- og slutbrugerhandlingerne interagerer med Lightning Platform-applikationsserveren:

Apex udviklingsmiljø

Apex-kode kan udvikles enten i en sandkasse eller i en Developer Edition-organisation i Salesforce.

Det er bedst at udvikle koden i et sandkassemiljø og derefter implementere den i produktionsmiljøet, som illustreret nedenfor:

Apex-kodeudviklingsværktøjer: Følgende er de tre værktøjer, der er tilgængelige til at udvikle Apex-kode i alle udgaver af Salesforce:

• Developer Console
• Visual Studio Code med Salesforce Extension Pack (denne erstatter den udgåede Force.com IDE)
• Code editor i Salesforce-opsætningsbrugergrænsefladen

Når dit miljø er klar, lad os se på selve sprogets byggesten, startende med datatyper.

Datatyper i Apex

Følgende er de datatyper, der understøttes af Apex:

Primitive

Heltal, Double, Long, Date, Datetime, Decimal, Time, Blob, String, ID og Boolean betragtes som primitive datatyper. Alle primitive datatyper sendes efter værdi, ikke efter reference.

Kollektioner

Tre typer samlinger er tilgængelige i Apex:

• Liste: Det er en ordnet samling af primitiver, sObjects, samlinger eller Apex-objekter baseret på indekser.
• Sæt: En uordnet samling af unikke elementer, der ikke indeholder dubletter.
• Kort: Det er en samling af unikke nøgler, der knyttes til enkelte værdier, som kan være primitiver, sObjects, samlinger eller Apex-objekter.

sObjekt

Dette er en speciel datatype i Salesforce. Det ligner et bord i SQL og indeholder felter, der ligner kolonner i SQL.

Enums

En enum er en mavemuskeltract-datatype, der lagrer én værdi af et endeligt sæt af specificerede identifikatorer.

Klasser, objekter og grænseflader

Brugerdefinerede Apex-klasser og -grænseflader kan også bruges som datatyper. Et objekt refererer til en forekomst af enhver datatype, der understøttes i Apex.

Apex syntaks

Variabel erklæring

Da Apex er et sprog med stærke typer, er det obligatorisk at deklarere en variabel med en datatype i Apex.

For eksempel:

Contact con = new Contact();

Her er variablen con deklareret med Contact som datatype.

SOQL-forespørgsel

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

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

Ovenstående forespørgsel henter en kontopost fra Salesforce-databasen.

Løkkeerklæring

En loop-sætning bruges til at iterere over posterne i en liste. Antallet af iterationer er lig med antallet af 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 ovenstående kodestykke er listOfAccounts en variabel af datatypen List.

Flowkontrolerklæring

En flowkontrolsætning er nyttig, når du vil udføre nogle linjer kode baseret på bestemte 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
}

Ovenstående kodestykke forespørger kontoposter fra databasen og kontrollerer listestørrelsen.

DML-erklæring

DML står for Data Manipulation Language. DML-sætninger bruges til at manipulere data i Salesforce-databasen. For eksempel:

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

Apex Access Specificators

Følgende er de adgangsspecifikationer, der understøttes af Apex:

offentlige

Denne adgangsspecifikation giver adgang til en klasse, metode eller variabel, der skal bruges af Apex i et navneområde.

Privat

Denne adgangsspecifikation giver adgang til en klasse, metode eller variabel, der kan bruges lokalt eller inden for den del af koden, hvor den er defineret. Alle metoder og variabler, der ikke har en defineret adgangsspecifikation, bruger standardadgangsspecifikationen private.

Beskyttet

Denne adgangsspecifikation giver adgang til en metode eller variabel, der kan bruges af alle indre klasser inden for den definerende Apex-klasse.

Global

Denne adgangsspecifikation giver adgang til en klasse, metode eller variabel, der skal bruges af Apex inden for et navneområde såvel som uden for navneområdet. Det er god praksis ikke at bruge det globale nøgleord, medmindre det er nødvendigt.

Nøgleord i Apex

Med deling

Hvis en klasse er defineret med dette nøgleord, håndhæves alle de delingsregler, der gælder for den aktuelle bruger. Hvis dette nøgleord mangler, udføres koden i systemkontekst.

For eksempel:

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

Uden at dele

Hvis en klasse er defineret med dette nøgleord, håndhæves de delingsregler, der gælder for den aktuelle bruger, ikke.

For eksempel:

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

statisk

En variabel eller metode defineret med nøgleordet static initialiseres én gang og associeres med klassen. Statiske variabler og metoder kan kaldes direkte med klassenavnet uden at oprette en instans af klassen.

Endelig

En konstant eller metode defineret med nøgleordet final kan ikke tilskrives. For eksempel:

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

Hvis du forsøger at tilsidesætte værdien af ​​denne INT_CONST-variabel, får du undtagelsen – System.FinalException: Den endelige variable er allerede initialiseret.

Returnering

Dette søgeord returnerer en værdi fra en metode. For eksempel:

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

Null

Den definerer en nulkonstant og kan tildeles en variabel. For eksempel:

Boolean b = null;

Virtual

Hvis en klasse er defineret med nøgleordet virtual, kan den udvides og tilskrives.

Abstract

Hvis en klasse er defineret med abstract-søgeordet, skal det indeholde mindst én metode med søgeordet abstract, og den metode skal kun have en signatur.

For eksempel:

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

Apex streng

En streng er et sæt tegn uden tegnbegrænsning. For eksempel:

String name = 'Test';

Der er adskillige indbyggede metoder i String-klassen i Salesforce. Følgende er et par ofte anvendte metoder:

forkorte (maxWidth)

Denne metode afkorter en streng til den angivne længde og returnerer den, hvis længden af ​​den givne streng er længere end den angivne længde; ellers returnerer den den oprindelige streng. Hvis værdien af ​​maxWidth-variablen er mindre end 4, udløser denne metode en runtime-undtagelse – System.StringException: Minimum forkortelsesbredde er 4.

For eksempel:

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

kapitaliser ()

Denne metode konverterer det første bogstav i en streng til store og små bogstaver og returnerer det.

For eksempel:

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

indeholder (understreng)

Denne metode returnerer sand, hvis strengen, der kalder metoden, indeholder den angivne delstreng.

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

er lig (stringOrId)

Denne metode returnerer sand, hvis den indtastede parameter ikke er null og repræsenterer den samme binære tegnsekvens som den streng, der kalder metoden.

Når man sammenligner id-værdier, er længderne af id'erne muligvis ikke ens. Hvis en streng, der repræsenterer et id på 15 tegn, f.eks. sammenlignes med et objekt, der repræsenterer et id på 18 tegn, returnerer denne metode stadig sand. For eksempel:

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

I ovenstående eksempel sammenligner equals-metoden et objekt-id på 15 tegn med et objekt-id på 18 tegn, og hvis begge ID'er repræsenterer den samme binære sekvens, returnerer den sand.

Brug denne metode til at foretage sammenligninger, der skelner mellem store og små bogstaver.

escapeSingle Quotes(stringToEscape)

Denne metode tilføjer et escape-tegn (\) før et enkelt anførselstegn i en streng og returnerer resultatet. Denne metode forhindrer SOQL-injektion under oprettelse af en dynamisk SOQL-forespørgsel. Den sikrer, at alle enkelt anførselstegn behandles som omsluttende strenge i stedet for databasekommandoer.

For eksempel:

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

fjern (understreng)

Denne metode fjerner alle forekomster af den nævnte delstreng fra den streng, der kalder metoden, og returnerer den resulterende streng.

For eksempel:

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

understreng (startindeks)

Denne metode returnerer en delstreng, der starter fra tegnet i startIndex og fortsætter til slutningen af ​​strengen.

For eksempel:

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

baglæns()

Denne metode vender alle tegnene i en streng om og returnerer den. For eksempel:

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

trimme ()

Denne metode fjerner alle førende og efterfølgende mellemrum fra en streng og returnerer den.

valueOf(toConvert)

Denne metode returnerer strengrepræsentationen af ​​det overførte objekt.

Strenge, klasser og nøgleord mødes, når du begynder at pakke logik i genanvendelige enheder, hvilket er præcis, hvad Apex-klasser er til for.

Apex klasse

En Apex-klasse er en blueprint eller skabelon, som objekter oprettes ud fra. Et objekt er en forekomst af en klasse.

Der er tre måder at oprette Apex-klasser i Salesforce:

• Developer Console
• Visual Studio Code med Salesforce-udvidelsespakken
• Apex-klassedetaljeside i Opsætning

I Apex kan du definere en ydre klasse, også kaldet en topniveauklasse, og du kan også definere klasser inden for en ydre klasse, kaldet indre klasser.

Det er obligatorisk at bruge en adgangsmodifikator som global eller public i deklarationen af ​​en outer klasse.

Det er ikke nødvendigt at bruge en adgangsmodifikator i deklarationen af ​​indre klasser.

En Apex-klasse defineres ved hjælp af nøgleordet class efterfulgt af klassenavnet.

Nøgleordet extends bruges til at udvide en eksisterende klasse i en Apex-klasse, og nøgleordet implements bruges til at implementere en grænseflade i en Apex-klasse.

Salesforce Apex understøtter ikke multipel nedarvning; en Apex-klasse kan kun udvide én eksisterende Apex-klasse, men kan implementere flere grænseflader.

En Apex-klasse kan indeholde en brugerdefineret konstruktør, og hvis en brugerdefineret konstruktør ikke er tilgængelig, bruges en standardkonstruktør. Koden i en konstruktør udføres, når en instans af en klasse oprettes.

Syntaks for en Apex-klasse:

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

Nøgleordet new bruges til at oprette en instans af en Apex-klasse. Nedenfor er syntaksen for oprettelse af en instans af en Apex-klasse:

myApexClass obj = new myApexClass();

Apex Getter og Setter

En Apex-egenskab ligner en Apex-variabel. En getter og en setter er nødvendige for en Apex-egenskab. De kan bruges til at udføre kode, før egenskabsværdien tilgås eller ændres. Koden i get-tilgangen udføres, når en egenskabsværdi læses. Koden i set-tilgangen udføres, når en egenskabsværdi ændres. Enhver egenskab, der kun har en get-tilgang, betragtes som skrivebeskyttet, enhver egenskab, der kun har en set-tilgang, betragtes som skrivebeskyttet, og enhver egenskab, der har både get- og set-tilgange, betragtes som læse-skrivebeskyttet. Syntaks for en Apex-egenskab:

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

Her er access_modifier adgangsmodifikatoren for egenskaben, return_type er datatypen for egenskaben, og property_name er navnet på egenskaben.

Nedenfor er et eksempel på en Apex-egenskab, der har både get- og set-tilgangspunkter:

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

Her er egenskabsnavnet navn, det er en offentlig egenskab, og den returnerer en String-datatype.

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

public double MyReadWriteProp{ get; set; }

Get- og set-accessorer kan også defineres med deres egne adgangsmodifikatorer. Hvis en accessor er defineret med en modifikator, tilsidesætter den egenskabens adgangsmodifikator. For eksempel:

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

Klasser definerer genanvendelig logik, som du kalder eksplicit. Triggere, som dækkes nedenfor, kører automatisk, når poster ændres.

Apex Trigger

Apex-udløsere gør det muligt at udføre brugerdefineret Apex før og efter en DML-handling er udført.

Apex understøtter følgende to typer triggere:

Før udløsere: Disse udløsere bruges til at validere og opdatere et felts værdi, før posten gemmes i databasen.

Efter udløsere: Disse udløsere bruges til at få adgang til feltværdier (f.eks. post-ID og feltet LastModifiedDate), der angives af systemet, efter en post er blevet committet til databasen. Disse feltværdier kan bruges til at ændre andre poster. Poster, der udløses efter udløsere, er skrivebeskyttede.

Det er god praksis at skrive bulk-udløsere. En bulk-udløser kan behandle en enkelt post såvel som flere poster ad gangen.

Syntaks for en Apex-trigger:

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

Her er TriggerName navnet på triggeren, ObjectName er navnet på det objekt, som triggeren er skrevet på, og trigger_events er en kommasepareret liste over hændelser.

Følgende er de hændelser, der understøttes af Apex-udløsere: før indsættelse, før opdatering, før sletning, efter indsættelse, efter opdatering, efter sletning, efter undelete.

Statiske nøgleord kan ikke bruges i en Apex-trigger. Alle nøgleord, der gælder for indre klasser, kan bruges i en Apex-trigger.

Der er implicitte variabler defineret af hver trigger, der returnerer kørselskonteksten. Disse variabler er defineret i System.Trigger-klassen og kaldes kontekstvariabler. De to skærmbilleder nedenfor viser de kontekstvariabler, der understøttes af Apex-triggere:

Følgende er overvejelser vedrørende kontekstvariabler i Apex-udløsere:

• Brug ikke trigger.new og trigger.old i DML-operationer.
• Trigger.new kan ikke slettes.
• Trigger.new er skrivebeskyttet efter triggere.
• Trigger.new kan kun bruges til at ændre værdierne af felter på det samme objekt før triggere.

De to skærmbilleder nedenfor viser overvejelserne vedrørende specifikke handlinger i forskellige udløsende hændelser:

Triggere håndterer realtidslogik, men nogle job er simpelthen for store til en enkelt transaktion. Det er her, batch-Apex kommer ind i billedet.

Batch-klasse i Apex

En batchklasse i Salesforce bruges til at behandle et stort antal poster, der ville overskride Apex-regulatorgrænserne, hvis de blev behandlet normalt. En batchklasse udfører koden asynkront.

Følgende er fordelene ved en batchklasse:

• En batchklasse behandler dataene i bidder, og hvis ét bidder ikke behandles korrekt, rulles de korrekt behandlede bidder ikke tilbage.
• Hvert datastykke i en batchklasse behandles med et nyt sæt governor-grænser, som sikrer, at koden udføres inden for governor-udførelsesgrænserne.

Database.Batchable-grænsefladen skal implementeres af en Apex-klasse for at kunne bruges som en batchklasse. Den indeholder tre metoder, der skal implementeres af batchklassen:

1. start()

Denne metode genererer omfanget af poster eller objekter, der skal behandles af interfacemetoden `execute`. Den kaldes kun én gang under udførelsen af ​​batchen. Denne metode returnerer enten et Database.QueryLocator-objekt eller en Iterable. Antallet af poster, der kan hentes af en SOQL-forespørgsel ved hjælp af Database.QueryLocator-objektet, er 50 millioner, men ved brug af en Iterable er det samlede antal poster, der kan hentes af SOQL-forespørgslen, kun 50,000. En Iterable bruges til at generere et komplekst omfang for batchklassen.

Syntaks for startmetoden:

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

2. udfør()

Denne metode bruges til at behandle hver data-klump. Execute-metoden kaldes for hver data-klump. Standardbatchstørrelsen for udførelse er 200 poster. Execute-metoden tager to argumenter:

En reference til Database.BatchableContext-objektet,

En liste over sObjects, såsom List , eller en liste over parametriserede typer. Syntaks for execute-metoden:

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

3. finish()

Metoden finish kaldes én gang under udførelsen af ​​batchklassen. Efterbehandlingsoperationer kan udføres i finish-metoden. For eksempel: afsendelse af en bekræftelsesmail. Denne metode kaldes, når alle batcher er behandlet. Syntaks for finish-metoden:

global void finish(Database.BatchableContext bc){}

Database.BatchableContext-objekt

Hver metode i Database.Batchable-grænsefladen har en reference til et Database.BatchableContext-objekt.

Dette objekt bruges til at track status for batchjobbet.

Følgende er de instansmetoder, der leveres af BatchableContext:

• getChildJobId(): Denne metode returnerer ID'et for det batchjob, der i øjeblikket behandles.
• getJobId(): Denne metode returnerer batchjobbets ID.

Nedenfor er syntaksen for 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 bruges til at udføre en batchklasse.

Denne metode bruger to parametre: en instans af den batchklasse, der skal behandles, og en valgfri scope-parameter til at angive batchstørrelsen. Hvis den ikke er angivet, bruges standardstørrelsen på 200.

Syntaks for Database.executeBatch:

Database.executeBatch(myBatchObject, scope)

Udførelse af en batchklasse med navnet MyBatchClass:

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

Database.Stateful

En batchklasse er som standard tilstandsløs. Hver gang execute-metoden kaldes, modtages en ny kopi af objektet, og alle klassens variabler initialiseres.

Database.Stateful implementeres for at gøre en batchklasse stateful.

Hvis din batchklasse implementerer Database.Stateful-grænseflade, alle instansvariabler bevarer deres værdier, men statiske variabler nulstilles mellem transaktioner.

Asynkron Apex Beyond Batch

Batch Apex er kun én af flere måder at køre kode asynkront på. Salesforce tilbyder fire asynkrone muligheder, og valget af den rigtige afhænger af, hvor meget data du behandler, og om job skal kædes sammen eller planlægges.

• Fremtidige metoder: Disse er annoteret med @future og er bedst egnet til simple, glemte handlinger, såsom udkald til eksterne webtjenester.
• Købar Apex: Implementerer Queueable-grænsefladen, accepterer komplekse objekttyper, returnerer et job-ID og understøtter kædedannelse af ét job til et andet.
• Batch Apex: Behandler meget store datamængder i bidder, som beskrevet ovenfor.
• Planlagt apex: Implementerer den planlagte grænseflade, så en klasse kører på et bestemt tidspunkt, f.eks. et natligt oprydningsjob.

Type	Bedste For	Nøglefunktion
Fremtidig metode	Enkle opfordringer	Affyr og glem
Købar Apex	Sekventiel behandling	Jobkæde og overvågning
Batch Apex	Millioner af optegnelser	Chunking-behandling
Planlagt Apex	Tilbagevendende job	Cron-baseret timing

Uanset hvilken udførelsesmodel du vælger, måles hver transaktion stadig i forhold til de platformomfattende styringsgrænser, der er anført nedenfor.

Apex-guvernørgrænser

Apex-regulatorgrænser er de grænser, der håndhæves af Apex-kørselsprogrammet for at sikre, at eventuel ustabil Apex-kode og -processer ikke monopoliserer de delte ressourcer og ikke forstyrrer andre brugeres behandling i multi-tenant-miljøet. Disse grænser verificeres mod hver Apex-transaktion. Følgende er de regulatorgrænser, der er defineret af Salesforce for hver Apex-transaktion:

Beskrivelse	Begræns
SOQL-forespørgsler, der kan udføres i en synkron transaktion	100
SOQL-forespørgsler, der kan udføres i en asynkron transaktion	200
Records, der kan hentes af en SOQL-forespørgsel	50,000
Records, der kan hentes af Database.getQueryLocator	10,000
SOSL-forespørgsler, der kan udføres i en Apex-transaktion	20
Records, der kan hentes ved en SOSL-forespørgsel	2,000
DML-udsagn, der kan udføres i en Apex-transaktion	150
Records, der kan behandles som et resultat af en DML-sætning, Approval.process eller database.emptyRecycleBin	10,000
Udkald, der kan udføres i en Apex-transaktion	100
Kumulativ timeoutgrænse for alle udkald, der udføres i en Apex-transaktion	120 sekunder
Begrænsning af Apex-job, der kan føjes til køen med System.enqueueJob	50
Udførelsestidsgrænse for hver Apex-transaktion	10 minutter
Begrænsning af tegn, der kan bruges i en Apex-klasse og -udløser	1 millioner
CPU-tidsgrænse for en synkron transaktion	10,000 millisekunder
CPU-tidsgrænse for en asynkron transaktion	60,000 millisekunder
Samlet bunkestørrelse	6 MB (synkron) / 12 MB (asynkron)

Sådan skriver du en testklasse i Apex

Salesforce kræver, at mindst 75 procent af din Apex-kode er dækket af enhedstests, før du kan implementere den i produktion, og hver trigger skal have en vis dækning. At skrive testklasser er derfor en central Apex-færdighed, ikke et valgfrit ekstraudstyr.

En testklasse er annoteret med @isTest, og hver testmetode er også markeret med @isTest. Testmetoder committer ikke data til databasen og ser ikke de fleste eksisterende organisationsdata, så hver test opretter sine egne poster. Metoderne Test.startTest() og Test.stopTest() giver den testede kode et nyt sæt af styregrænser, og assertions verificerer, at logikken opførte sig som forventet.

Her er en simpel testklasse til logik for oprettelse af konto:

@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 retningslinjer, når du skriver prøver:

• Brug @testSetup-metoden til at oprette delte testdata én gang for alle testmetoder i klassen.
• Test masseadfærd ved at indsætte 200 poster, ikke kun én.
• Dæk positive, negative og scenarier med begrænsede brugere.
• Inkluder altid meningsfulde System.assert-udsagn; dækning uden assertions beviser intet.

Apex Bedste Practices

Begyndere skriver ofte Apex, der fungerer for én post, men mislykkes i masseoperationer i den virkelige verden. Fremgangsmåderne nedenfor holder din kode inden for grænserne for styringssystemet og er nemmere at vedligeholde:

• Massér alt: Skriv logik, der håndterer samlinger af poster, fordi udløsere kan modtage op til 200 poster i en enkelt batch.
• Hold SOQL og DML ude af loops: Forespørg før løkken, indsaml ændringer i en liste, og udfør én DML-sætning efter løkken.
• Én trigger pr. objekt: Hold triggere logisk frie og deleger arbejdet til handlerklasser, hvilket gør udførelsesrækkefølgen forudsigelig.
• Brug med deling: Håndhæv sikkerhed på postniveau, medmindre der er en dokumenteret grund til at køre i systemkontekst.
• Undgå hardkodning af ID'er: Post-ID'er varierer mellem sandkasser og produktionsbaserede, så forespørg efter dem, eller brug brugerdefinerede metadata i stedet.
• Overvågningsgrænser i kode: Metoderne i Limits-klassen, f.eks. Limits.getQueries(), giver dig mulighed for at kontrollere ressourceforbruget under kørsel.

💡 Tip: Kør din kode mod 200 poster i en sandkasse før udrulning. De fleste fejl i governor-grænser opstår kun ved bulkvolumen, og det er langt billigere at opdage dem tidligt end at fejlfinde dem i produktion.

Ofte Stillede Spørgsmål