Salesforce Apex-handledning för nybörjare

⚡ Smart sammanfattning

Apex-programmering ger Salesforce-utvecklare ett objektorienterat, starkt typspråk för att lägga till anpassad affärslogik i CRM-systemet. Det driver klasser, triggers och batchjobb medan styrningsgränser håller den delade plattformen för flera hyresgäster stabil.

  • 🧱 Foundation: Apex är ett språk som inte känsligt för gemener och Java-liknande syntax som körs direkt på Salesforce Lightning-plattformen.
  • 🗃️ Datatillgång: SOQL-frågor och DML-satser låter din kod läsa och skriva sObject-poster direkt i Salesforce-databasen.
  • 🛠️ Genomförande: Klasser, egenskaper och utlösare kopplar anpassad logik till postinlägg, uppdateringar, borttagningar och andra systemhändelser.
  • 📦 Skala: Batch-Apex och andra asynkrona alternativ bearbetar miljontals poster i block utan att bryta mot plattformens gränser.
  • 🚦 Guvernörens gränser: Begränsningar per transaktion, såsom 100 synkrona SOQL-frågor och 150 DML-satser, skyddar delade resurser.
  • Kvalitet: Enhetstester måste täcka minst 75 procent av Apex-koden före produktionsdistribution.

Översikt över APEX Salesforce-programmering

Vad är Apex i Salesforce?

Apex är ett objektorienterat och starkt typat programmeringsspråk utvecklat av Salesforce för att bygga SaaS- och CRM-applikationer (Software as a Service). Apex hjälper utvecklare att skapa SaaS-applikationer från tredje part och lägga till affärslogik till systemhändelser genom att tillhandahålla backend-databasstöd och klient-server-gränssnitt.

Apex hjälper utvecklare att lägga till affärslogik till systemhändelser som knappklick, relaterade postuppdateringar och Visualforce-sidor. Apex har en syntax som liknar Java. Registrera dig för Salesforce för att lära sig hur CRM fungerar.

Funktioner i Apex programmeringsspråk

Här är de viktiga funktionerna i Salesforce Apex:

  • Apex är ett språk som inte känsligt för gemener och versaler.
  • Du kan utföra DML-operationer som INSERT, UPDATE, UPSERT och DELETE på sObject-poster med Apex.
  • Du kan fråga sObject-poster med hjälp av SOQL (Salesforce Object Query Language) och SOSL (Salesforce Object Search Language) i Apex.
  • Låter dig skapa en enhetstest och kör den för att verifiera kod täckning och effektiviteten hos koden i Apex.
  • Apex körs i en miljö med flera hyresgäster, och Salesforce har definierade styrningsgränser som förhindrar att en användare monopoliserar de delade resurserna. All kod som överskrider en Salesforce-styrningsgräns misslyckas och ett fel visas.
  • Ett Salesforce-objekt kan användas som en datatyp i Apex. Till exempel:
    Account acc = new Account();

    Här är Konto ett standard Salesforce-objekt.

  • Apex uppgraderas automatiskt med varje Salesforce-version.

När bör en utvecklare välja Apex?

Apex-kod bör endast skrivas om ett affärsscenario är för komplext för att implementeras med den förbyggda peka-och-klicka-funktionen som tillhandahålls av Salesforce.

Följande är några scenarier där du behöver skriva Apex-kod:

  • Att skapa webbtjänster som integrerar Salesforce med andra applikationer.
  • För att implementera anpassad validering på sObjects.
  • För att köra anpassad Apex-logik när en DML-operation utförs.
  • För att implementera funktionalitet som inte kan byggas med befintliga deklarativa automatiseringsverktyg som Flow.
  • Att ställa in e-posttjänster som bearbetar innehållet, rubrikerna och bilagorna i inkommande e-post.

När du väl vet när Apex är rätt val är nästa steg att förstå vad som händer med din kod efter att du sparat den.

Apex arbetsstruktur

Följande är flödet av åtgärder för Apex-kod:

  • Utvecklaråtgärd: När utvecklaren sparar kod på plattformen kompileras all Apex-kod till en uppsättning instruktioner som Apex runtime-interpretatorn kan förstå, och dessa instruktioner sparas sedan som metadata på plattformen.
  • Slutanvändaråtgärd: När en användarhändelse kör Apex-kod hämtar plattformsservern de kompilerade instruktionerna från metadata och kör dem genom Apex-tolken innan resultatet returneras.

Diagrammet nedan visar hur utvecklarens och slutanvändarens åtgärder interagerar med Lightning Platform-applikationsservern:

Arbetsstruktur av Apex

Apex utvecklingsmiljö

Apex-kod kan utvecklas antingen i en sandlåda eller i en Developer Edition-organisation av Salesforce.

Det är en god idé att utveckla koden i en sandlådemiljö och sedan distribuera den till produktionsmiljön, som illustreras nedan:

Apex utvecklingsmiljö

Apex-kodutvecklingsverktyg: Följande är de tre verktyg som finns tillgängliga för att utveckla Apex-kod i alla versioner av Salesforce:

  • Utvecklarkonsol
  • Visual Studio Code med Salesforce Extension Pack (detta ersätter den pensionerade Force.com IDE)
  • Code redigeraren i Salesforce Setup-gränssnittet

När din miljö är redo, låt oss titta på själva språkets byggstenar, med början i datatyper.

Datatyper i Apex

Följande är de datatyper som stöds av Apex:

Primitiv

Heltal Double, Long, Date, Datetime, Decimal, Time, Blob, String, ID och Boolean betraktas som primitiva datatyper. Alla primitiva datatyper skickas via värde, inte via referens.

Kollektioner

Tre typer av samlingar finns tillgängliga i Apex:

  • Lista: Det är en ordnad samling av primitiver, sObjects, samlingar eller Apex-objekt baserade på index.
  • Set: En oordnad samling av unika element som inte innehåller dubbletter.
  • Karta: Det är en samling unika nycklar som mappas till enskilda värden, vilka kan vara primitiver, sObjects, samlingar eller Apex-objekt.

sObjekt

Detta är en speciell datatyp i Salesforce. Det liknar ett bord i SQL och innehåller fält som liknar kolumner i SQL.

Enums

Enum är en magmuskeltract-datatyp som lagrar ett värde av en ändlig mängd specificerade identifierare.

Klasser, objekt och gränssnitt

Användardefinierade Apex-klasser och gränssnitt kan också användas som datatyper. Ett objekt refererar till en instans av en datatyp som stöds i Apex.

Apex syntax

Variabel deklaration

Eftersom Apex är ett språk med starka typer är det obligatoriskt att deklarera en variabel med en datatyp i Apex.

Till exempel:

Contact con = new Contact();

Här deklareras variabeln con med Contact som datatyp.

SOQL-fråga

SOQL står för Salesforce Object Query Language. SOQL används för att hämta sObject-poster från Salesforce-databasen. Till exempel:

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

Ovanstående fråga hämtar en kontopost från Salesforce-databasen.

Loop Statement

En loop-sats används för att iterera över posterna i en lista. Antalet iterationer är lika med antalet poster i listan. Till exempel:

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

I kodavsnittet ovan är listOfAccounts en variabel av datatypen List.

Flödeskontrolldeklaration

En flödeskontrollsats är fördelaktig när du vill köra några rader kod baserat på vissa villkor.

Till exempel:

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
}

Ovanstående kodavsnitt frågar efter kontoposter från databasen och kontrollerar liststorleken.

DML-uttalande

DML står för Data Manipulation Language. DML-satser används för att manipulera data i Salesforce-databasen. Till exempel:

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

Apex Access Specificers

Följande är de åtkomstspecifikationer som stöds av Apex:

offentliga

Denna åtkomstspecifikation ger åtkomst till en klass, metod eller variabel som ska användas av Apex inom ett namnutrymme.

Privat

Denna åtkomstspecifikation ger åtkomst till en klass, metod eller variabel som ska användas lokalt, eller inom den del av koden där den är definierad. Alla metoder och variabler som inte har en definierad åtkomstspecifikation får standardåtkomstspecifikationen private.

Skyddad

Denna åtkomstspecifikation ger åtkomst till en metod eller variabel som kan användas av alla inre klasser inom den definierande Apex-klassen.

Välgörenhet

Denna åtkomstspecifikation ger åtkomst till en klass, metod eller variabel som ska användas av Apex inom ett namnutrymme såväl som utanför namnutrymmet. Det är en god praxis att inte använda det globala nyckelordet om det inte är nödvändigt.

Nyckelord i Apex

Med delning

Om en klass definieras med detta nyckelord tillämpas alla delningsregler som gäller för den aktuella användaren. Om detta nyckelord saknas körs koden i systemkontext.

Till exempel:

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

Utan att dela

Om en klass definieras med detta nyckelord tillämpas inte de delningsregler som gäller för den aktuella användaren.

Till exempel:

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

Statisk

En variabel eller metod som definieras med nyckelordet static initieras en gång och associeras med klassen. Statiska variabler och metoder kan anropas direkt med klassnamnet utan att skapa en instans av klassen.

Slutlig

En konstant eller metod definierad med nyckelordet final kan inte åsidosättas. Till exempel:

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

Om du försöker åsidosätta värdet för denna INT_CONST-variabel får du undantaget – System.FinalException: Den sista variabeln har redan initialiserats.

Retur

Detta nyckelord returnerar ett värde från en metod. Till exempel:

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

Null

Den definierar en nullkonstant och kan tilldelas en variabel. Till exempel:

Boolean b = null;

Virtuell

Om en klass definieras med nyckelordet virtual kan den utökas och åsidosättas.

Abstract

Om en klass definieras med abstract-nyckelordet måste det innehålla minst en metod med nyckelordet abstract, och den metoden ska bara ha en signatur.

Till exempel:

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

Apex sträng

En sträng är en uppsättning tecken utan teckenbegränsning. Till exempel:

String name = 'Test';

Det finns flera inbyggda metoder som tillhandahålls av String-klassen i Salesforce. Följande är några vanliga metoder:

förkorta (maxWidth)

Den här metoden avkortar en sträng till den angivna längden och returnerar den om längden på den givna strängen är längre än den angivna längden; annars returnerar den den ursprungliga strängen. Om värdet på variabeln maxWidth är mindre än 4, utlöser metoden ett körtidsundantag – System.StringException: Minsta förkortningsbredd är 4.

Till exempel:

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

kapitalisera()

Denna metod konverterar den första bokstaven i en sträng till skiftläge och returnerar den.

Till exempel:

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

innehåller (delsträng)

Den här metoden returnerar sant om strängen som anropar metoden innehåller den angivna delsträngen.

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

lika(stringOrId)

Den här metoden returnerar sant om den skickade parametern inte är null och representerar samma binära teckensekvens som strängen som anropar metoden.

När man jämför ID-värden kanske längden på ID:na inte är lika. Om till exempel en sträng som representerar ett ID med 15 tecken jämförs med ett objekt som representerar ett ID med 18 tecken, returnerar den här metoden fortfarande sant. Till exempel:

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

I exemplet ovan jämför equals-metoden ett objekt-ID på 15 tecken med ett objekt-ID på 18 tecken, och om båda ID:na representerar samma binära sekvens returnerar den sant.

Använd den här metoden för att göra skiftlägeskänsliga jämförelser.

escapeSingle Quotes(stringToEscape)

Den här metoden lägger till ett escape-tecken (\) före varje enskilt citattecken i en sträng och returnerar resultatet. Den här metoden förhindrar SOQL-injektion när en dynamisk SOQL-fråga skapas. Den säkerställer att alla enkla citattecken behandlas som omslutande strängar istället för databaskommandon.

Till exempel:

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

remove(substring)

Den här metoden tar bort alla förekomster av den nämnda delsträngen från strängen som anropar metoden och returnerar den resulterande strängen.

Till exempel:

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

delsträng (startindex)

Den här metoden returnerar en delsträng som börjar från tecknet i startIndex och fortsätter till slutet av strängen.

Till exempel:

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

omvänd()

Den här metoden reverserar alla tecken i en sträng och returnerar den. Till exempel:

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

trim()

Den här metoden tar bort alla inledande och efterföljande vita mellanslag från en sträng och returnerar den.

valueOf(toConvert)

Den här metoden returnerar strängrepresentationen för det skickade objektet.

Strängar, klasser och nyckelord sammanförs när du börjar paketera logik till återanvändbara enheter, vilket är precis vad Apex-klasser är till för.

Apex klass

En Apex-klass är en ritning eller mall från vilken objekt skapas. Ett objekt är en instans av en klass.

Det finns tre sätt att skapa Apex-klasser i Salesforce:

  • Utvecklarkonsol
  • Visual Studio Code med Salesforce Extension Pack
  • Apex-klassens detaljsida i inställningar

I Apex kan du definiera en yttre klass, även kallad en toppnivåklass, och du kan också definiera klasser inom en yttre klass, kallade inre klasser.

Det är obligatoriskt att använda en åtkomstmodifierare som global eller public i deklarationen av en yttre klass.

Det är inte nödvändigt att använda en åtkomstmodifierare i deklarationen av inre klasser.

En Apex-klass definieras med hjälp av nyckelordet class följt av klassnamnet.

Nyckelordet extends används för att utöka en befintlig klass i en Apex-klass, och nyckelordet implements används för att implementera ett gränssnitt i en Apex-klass.

Salesforce Apex stöder inte multipel arv; en Apex-klass kan bara utöka en befintlig Apex-klass men kan implementera flera gränssnitt.

En Apex-klass kan innehålla en användardefinierad konstruktor, och om en användardefinierad konstruktor inte är tillgänglig används en standardkonstruktor. Koden i en konstruktor körs när en instans av en klass skapas.

Syntax för en Apex-klass:

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

Nyckelordet new används för att skapa en instans av en Apex-klass. Nedan följer syntaxen för att skapa en instans av en Apex-klass:

myApexClass obj = new myApexClass();

Apex Getter och Setter

En Apex-egenskap liknar en Apex-variabel. En getter och en setter är nödvändiga för en Apex-egenskap. De kan användas för att köra kod innan egenskapsvärdet nås eller ändras. Koden i get-åtkomstaren körs när ett egenskapsvärde läses. Koden i set-åtkomstaren körs när ett egenskapsvärde ändras. Alla egenskaper som bara har en get-åtkomstare betraktas som skrivskyddade, alla egenskaper som bara har en set-åtkomstare betraktas som skrivskyddade och alla egenskaper som har både get- och set-åtkomstare betraktas som läs- och skrivskyddade. Syntax för en Apex-egenskap:

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

Här är access_modifier egenskapens åtkomstmodifierare, return_type är egenskapens datatyp och property_name är egenskapens namn.

Nedan följer ett exempel på en Apex-egenskap som har både get- och set-åtkomstfunktioner:

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

Här är egenskapsnamnet namn, det är en publik egenskap och den returnerar en String-datatyp.

Det är inte obligatoriskt att ha kod i blocken get och set. Dessa block kan lämnas tomma för att definiera en automatisk egenskap. Till exempel:

public double MyReadWriteProp{ get; set; }

Get- och set-åtkomstfunktioner kan också definieras med egna åtkomstmodifierare. Om en åtkomstfunktion definieras med en modifierare åsidosätter den egenskapens åtkomstmodifierare. Till exempel:

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

Klasser definierar återanvändbar logik som du anropar explicit. Utlösare, som behandlas härnäst, körs automatiskt när poster ändras.

Apex trigger

Apex-utlösare gör att du kan köra anpassad Apex före och efter att en DML-operation utförs.

Apex stöder följande två typer av triggers:

Före triggers: Dessa utlösare används för att validera och uppdatera ett fälts värde innan posten sparas i databasen.

Efter triggers: Dessa utlösare används för att komma åt fältvärden (som post-ID och fältet LastModifiedDate) som anges av systemet efter att en post har sparats i databasen. Dessa fältvärden kan användas för att ändra andra poster. Poster som utlöses efter utlösare är skrivskyddade.

Det är en god idé att skriva bulkfördelade utlösare. En bulkfördelad utlösare kan bearbeta en enda post såväl som flera poster samtidigt.

Syntax för en Apex-utlösare:

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

Här är TriggerName namnet på utlösaren, ObjectName är namnet på objektet som utlösaren är skriven på och trigger_events är en kommaseparerad lista med händelser.

Följande är de händelser som stöds av Apex-utlösare: före infogning, före uppdatering, före borttagning, efter infogning, efter uppdatering, efter borttagning, efter återställning.

Statiska nyckelord kan inte användas i en Apex-utlösare. Alla nyckelord som är tillämpliga på inre klasser kan användas i en Apex-utlösare.

Det finns implicita variabler definierade av varje trigger som returnerar körtidskontexten. Dessa variabler definieras i System.Trigger-klassen och kallas kontextvariabler. De två skärmdumparna nedan listar de kontextvariabler som stöds av Apex-triggers:

Kontextvariabler för Apex-utlösare

Kontextvariabler för Apex-utlösare (fortsättning)

Följande är överväganden för kontextvariabler i Apex-utlösare:

  • Använd inte trigger.new och trigger.old i DML-operationer.
  • Trigger.new kan inte tas bort.
  • Trigger.new är skrivskyddad efter triggers.
  • Trigger.new kan användas för att ändra värdena på fält på samma objekt, endast före triggers.

De två skärmdumparna nedan listar överväganden kring specifika åtgärder vid olika utlösande händelser:

Att tänka på vid Apex-utlösarhändelser

Att beakta vid Apex-utlösarhändelser (fortsättning)

Triggers hanterar realtidslogik, men vissa jobb är helt enkelt för stora för en enda transaktion. Det är där batch-Apex kommer in i bilden.

Batchklass i Apex

En batchklass i Salesforce används för att bearbeta ett stort antal poster som skulle överskrida Apex-regulatorns gränser om de bearbetades normalt. En batchklass kör koden asynkront.

Följande är fördelarna med en batchklass:

  • En batch-klass bearbetar data i segment, och om en segment misslyckas med att bearbetas, återställs inte de bearbetade segmenten.
  • Varje datablock i en batchklass bearbetas med en ny uppsättning guvernörgränser, vilket säkerställer att koden körs inom guvernörens körningsgränser.

Gränssnittet Database.Batchable måste implementeras av en Apex-klass för att kunna användas som en batchklass. Det tillhandahåller tre metoder som måste implementeras av batchklassen:

1. starta()

Den här metoden genererar omfånget för poster eller objekt som ska bearbetas av gränssnittsmetoden execute. Den anropas bara en gång under körningen av batchen. Metoden returnerar antingen ett Database.QueryLocator-objekt eller en Iterable. Antalet poster som kan hämtas av en SOQL-fråga med Database.QueryLocator-objektet är 50 miljoner, men med en Iterable är det totala antalet poster som kan hämtas av SOQL-frågan endast 50 000. En Iterable används för att generera ett komplext omfång för batchklassen.

Syntax för startmetoden:

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

2. execute()

Den här metoden används för att bearbeta varje datasegment. Metoden execute anropas för varje datasegment. Standardbatchstorleken för exekvering är 200 poster. Metoden execute tar två argument:

En referens till Database.BatchableContext-objektet,

En lista med sObjects, till exempel List , eller en lista med parametriserade typer. Syntax för execute-metoden:

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

3. finish()

Metoden finish anropas en gång under körningen av batchklassen. Efterbehandlingsoperationer kan utföras i finish-metoden. Till exempel: skicka ett bekräftelsemejl. Denna metod anropas när alla batchar har bearbetats. Syntax för finish-metoden:

global void finish(Database.BatchableContext bc){}

Database.BatchableContext-objekt

Varje metod i Database.Batchable-gränssnittet har en referens till ett Database.BatchableContext-objekt.

Detta objekt används för att track förloppet för batchjobbet.

Följande är instansmetoderna som tillhandahålls av BatchableContext:

  • getChildJobId(): Den här metoden returnerar ID:t för det batchjobb som för närvarande bearbetas.
  • getJobId(): Denna metod returnerar batchjobbets ID.

Nedan följer syntaxen för en batchklass:

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-metod

Metoden Database.executeBatch används för att köra en batch-klass.

Den här metoden använder två parametrar: en instans av batchklassen som ska bearbetas och en valfri scope-parameter för att ange batchstorleken. Om den inte anges används standardstorleken 200.

Syntax för Database.executeBatch:

Database.executeBatch(myBatchObject, scope)

Köra en batchklass med namnet MyBatchClass:

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

Database.Tillståndsfull

En batchklass är som standard tillståndslös. Varje gång execute-metoden anropas tas en ny kopia av objektet emot och alla variabler i klassen initieras.

Database.Stateful implementeras för att göra en batch-klass tillståndsfull.

Om din batchklass implementerar Databas.Stateful-gränssnitt, alla instansvariabler behåller sina värden, men statiska variabler återställs mellan transaktioner.

Asynkron Apex Beyond Batch

Batch Apex är bara ett av flera sätt att köra kod asynkront. Salesforce erbjuder fyra asynkrona alternativ, och valet av rätt alternativ beror på hur mycket data du bearbetar och om jobb behöver kedjas eller schemaläggas.

  • Framtida metoder: Dessa är kommenterade med @future och passar bäst för enkla, avfyrningsbara åtgärder som till exempel anrop till externa webbtjänster.
  • Köbar Apex: Implementerar Queueable-gränssnittet, accepterar komplexa objekttyper, returnerar ett jobb-ID och stöder kedjan av ett jobb till ett annat.
  • Batch Apex: Bearbetar mycket stora datavolymer i bitar, som beskrivs ovan.
  • Schemalagd topp: Implementerar gränssnittet schemaläggbart så att en klass körs vid en specifik tidpunkt, till exempel ett nattligt rensningsjobb.
Typ bäst för Viktig kapacitet
Framtida metod Enkla utrop Avfyra och glöm
Köbar Apex Sekventiell bearbetning Jobbkedja och övervakning
Batch Apex Miljontals poster Chunked bearbetning
Schemalagd Apex Återkommande jobb Cron-baserad timing

Oavsett vilken exekveringsmodell du väljer mäts varje transaktion fortfarande mot de plattformsomfattande styrgränserna som anges nedan.

Apex Governor Limits

Apex-styrningsgränser är de gränser som tillämpas av Apex runtime-motorn för att säkerställa att eventuell skenande Apex-kod och -processer inte monopoliserar de delade resurserna och inte stör bearbetningen av andra användare i miljön med flera hyresgäster. Dessa gränser verifieras mot varje Apex-transaktion. Följande är styrningsgränserna som definieras av Salesforce för varje Apex-transaktion:

BESKRIVNING Begränsa
SOQL-frågor som kan göras i en synkron transaktion 100
SOQL-frågor som kan göras i en asynkron transaktion 200
Poster som kan hämtas med en SOQL-fråga 50,000
Poster som kan hämtas av Database.getQueryLocator 10,000
SOSL-frågor som kan göras i en Apex-transaktion 20
Poster som kan hämtas med en SOSL-fråga 2,000
DML-satser som kan göras i en Apex-transaktion 150
Poster som kan bearbetas som ett resultat av en DML-sats, Approval.process eller database.emptyRecycleBin 10,000
Anrop som kan göras i en Apex-transaktion 100
Kumulativ timeout-gräns för alla anrop som utförs i en Apex-transaktion 120 sekunder
Begränsning av Apex-jobb som kan läggas till i kön med System.enqueueJob 50
Utförandetidsgräns för varje Apex-transaktion 10 minuter
Begränsning av tecken som kan användas i en Apex-klass och utlösare 1 miljoner
CPU-tidsgräns för en synkron transaktion 10,000 millisekunder
CPU-tidsgräns för en asynkron transaktion 60,000 millisekunder
Total högstorlek 6 MB (synkron) / 12 MB (asynkron)

Hur man skriver en testklass i Apex

Salesforce kräver att minst 75 procent av din Apex-kod täcks av enhetstester innan du kan distribuera den till produktion, och varje trigger måste ha någon form av täckning. Att skriva testklasser är därför en central Apex-färdighet, inte ett valfritt tillägg.

En testklass annoteras med @isTest, och varje testmetod är också markerad med @isTest. Testmetoder sparar inte data i databasen och ser inte de flesta befintliga organisationsdata, så varje test skapar sina egna poster. Metoderna Test.startTest() och Test.stopTest() ger koden som testas en ny uppsättning styrgränser, och assertioner verifierar att logiken betedde sig som förväntat.

Här är en enkel testklass för logik för kontoskapande:

@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ölj dessa riktlinjer när du skriver prov:

  • Använd @testSetup-metoden för att skapa delade testdata en gång för alla testmetoder i klassen.
  • Testa massbeteendet genom att infoga 200 poster, inte bara en.
  • Täck positiva, negativa och scenarier med begränsade användare.
  • Inkludera alltid meningsfulla System.assert-satser; täckning utan påståenden bevisar ingenting.

Apex bästa praxis

Nybörjare skriver ofta Apex som fungerar för en post men misslyckas i verkliga bulkoperationer. Metoderna nedan håller din kod inom guvernörsgränserna och är lättare att underhålla:

  • Massa upp allting: Skriv logik som hanterar samlingar av poster, eftersom utlösare kan ta emot upp till 200 poster i en enda batch.
  • Håll SOQL och DML borta från loopar: Fråga före loopen, samla ändringar i en lista och utför en DML-sats efter loopen.
  • En utlösare per objekt: Håll triggers logikfria och delegera arbetet till hanterarklasser, vilket gör exekveringsordningen förutsägbar.
  • Använd med delning: Tillämpa säkerhet på postnivå om det inte finns en dokumenterad anledning att köra i systemkontext.
  • Undvik hårdkodning av ID:n: Post-ID:n skiljer sig mellan sandlådor och produktion, så fråga efter dem eller använd anpassade metadata istället.
  • Övervakningsgränser i kod: Metoderna i Limits-klassen, som Limits.getQueries(), låter dig kontrollera resursförbrukningen vid körning.

👍 Dricks: Kör din kod mot 200 poster i en sandlåda innan du distribuerar den. De flesta fel i guvernörsgränser uppstår bara vid bulkvolymer, och att upptäcka dem tidigt är mycket billigare än att felsöka dem i produktion.

Vanliga frågor

Nej. Apex lånar Java-liknande syntax, men den är inte skiftlägeskänslig, körs endast på Salesforce Lightning-plattformen, integrerar SOQL direkt i språket och styrs av gränser per transaktion som Java har inte.

Registrera dig för en gratis Salesforce Developer Edition-organisation, som inkluderar Developer Console, och följ praktiska övningar på vandringsled, den officiella lärplattformen från Salesforce.

Visualforce är ett markupspråk för att bygga användargränssnittssidor, medan Apex är serverspråket som tillhandahåller logiken bakom dem. Visualforce-sidor anropar ofta Apex-kontrollklasser för att fråga efter och uppdatera data.

Ja. Agentforce för utvecklare, AI-assistenten från Salesforce för Visual Studio Code, genererar och förklarar Apex från naturligt språk. Granska och testa alltid AI-genererad kod mot styrningsgränser innan driftsättning.

Apex-klasser markerade med annoteringen @InvocableMethod kan exponeras som anpassade åtgärder, vilket låter Einstein-botar och Agentforce-agenter anropa din affärslogik, medan Apex också kan anropa Einstein-promptmallar och AI-modeller via plattforms-API:er.

Sammanfatta detta inlägg med: