Denna text har översatts med Salesforces automatiserade översättningssystem. Gå igenom vår undersökning för att ge feedback om detta innehåll och berätta vad du vill se härnäst.
Salesforce Customer 360 Platform tillhandahåller en kraftfull multitenant, metadatadriven arkitektur för varje enskild Salesforce-arrendatorinstans (även kallad ”org”). Detta grundläggande dokument för arkitektur ger en översikt av områden där den underliggande arkitekturen för Salesforce Platform skapar en viktig faktor för arkitekturen för lösningar byggda på plattformen.
Det finns tre viktiga områden att förstå vid utformning av arkitekturer på Salesforce Platform:
På Salesforce Platform kan en transaktion instansieras genom kodkörning och/eller en databasoperation. En grundläggande kompetens för arkitektarbete i Salesforce är att förstå hur plattformen definierar och styr transaktioner för arrendatorer. För att upprätthålla resurser för alla arrendatorer inför Salesforce gränser för varje arrendator, beräknade per transaktion och per organisation.
På transaktionsnivå anger Salesforce styrande och utförandegränser för att säkerställa att enskilda instanser av kodkörning och databastransaktioner inte monopoliserar delade beräkningsresurser. På organisationsnivå anger Salesforce gränser baserat på version och funktionstyp. Organisationsomfattande gränser inkluderar även en rullande beräkning av API-användning för alla transaktioner i organisationen, som är föremål för API-gränser.
Låt oss titta närmare på två viktiga delar av transaktioner på Salesforce Platform: utförandesammanhang och databasmanipulation.
Salesforce beräknar transaktionsgränser baserat på ett koncept för utförandesammanhang. Det är viktigt att förstå att för Salesforce-program är detta inte exklusivt för körning av egen kod inom en enskild Salesforce-organisation. Utförandesammanhang baseras på plattformens runtimemotor och all kod som är tillgänglig för runtimemotorn för en specifik arrendator. Detta innebär att egen kod som definieras i en arrendatororganisation, kod från paket som installerats med den organisationen samt kod som finns i Salesforce Platform-tjänster alla kan instansiera en transaktion. Plattformen skiljer mellan olika typer av Apex kod och beräknar styrande gränser baserat på dessa skillnader.
Se Apex utvecklarguide för mer information om Apex transaktionsgränser.
När en transaktion involverar databasmanipulation föreskriver en inbyggd ordning för utförande hur olika delar av din organisations konfiguration och kod kommer att bete sig. En nyckel till att förstå hur man korrekt använder ordningen för utförandet i dina Salesforce-program är att förstå den robusta dataintegritet detta beteende ger för dina Salesforce-program.
Plattformen visar sammanhangsvariabler för status för databasoperationer i form av utlösande sammanhangsvariabler. Det är viktigt att förstå att dessa utlösande sammanhangsvariabler beskriver körtidslägen för alla databastransaktioner i Salesforce-organisationen—oavsett om egna Apex har definierats inom organisationen eller inte. De är tillgängliga för deklarativa verktyg som Salesforce-flöde.
I Salesforce överlämnas inte data (inte heller slutförs datatransaktioner) förrän de slutgiltiga efter att utlösarbeteendena som beskrivs i utlösarordningen har slutförts. Detta innebär att eventuella fel eller diskvalificerande beteenden under en datatransaktion som inträffar före eller efter sammanhang kommer att göra att plattformen drar tillbaka alla dataoperationer inom transaktionen. Begärda ändringar av postdata binds inte till databasen och ingen logik efter bindning körs. (Apex visar databasmetoder för att möjliggöra mer detaljerad kontroll av sparpunkter och återföringsbeteende.)
Ett viktigt anti-mönster att undvika i din Salesforce-arkitektur är att försöka korta av eller ersätta plattformens inbyggda ordning för utförandebeteende.
För en djupare titt på logiken bakom dessa inbyggda beteenden för dataintegritet, se Inifrån och ut: Transaktioner på Salesforce Engineering-bloggen.
När du väljer hur du anpassar och utökar inom en Salesforce-organisation är det viktigt att förstå vad som kommer att betraktas som data och vad som kommer att betraktas som metadata ur Salesforce Platforms synvinkel. För en djupdykning i den underliggande arkitekturen bakom denna distinktion av data/metadata, i dokumentet Grundläggande plattformsarkitektur.
Denna skillnad kommer att påverka många aspekter av utvecklingslivscykeln för ditt program, till exempel: om en artefakt kommer att kopieras över till sandboxutvecklingsmiljöer, hur den kan migreras till andra miljöer, om den kan vara en del av ett paket eller inte.
Tabellen nedan ger en snabb jämförelse av prestandan för data vs. metadata som den relaterar till viktiga delar av programmets livscykel:
| Beteende | Data | Metadata |
|---|---|---|
| Kopierad från produktion till sandboxmiljöer | Nej* | Ja |
| Migrera efter Metadata API | Nej | Ja** |
| Migrera efter databelastning | Ja | Nej |
| Kan inkluderas i paket | Nej | Ja** |
| Räknas mot datalagringsgränser | Ja | Nej |
| *Sandboxar med fullständiga och delvisa kopior tillåter datareplikering från produktion. **Vissa metadatatyper är inte tillgängliga för användning med Metadata API och/eller paket. Du hittar undantag i Metadatatäckningsrapporten. |
||
Ibland är denna skillnad ganska uppenbar. Till exempel är individuella poster i en Salesforce-organisation data. De olika sObjects i en organisation är metadata.
Skillnader kan vara mer komplexa när det gäller organisationskonfigurationsfunktioner. Ett viktigt exempel är Egna inställningar vs Egna metadatatyper. Båda dessa funktioner låter dig konfigurera information i en organisation så att den är lätt tillgänglig vid runtime och kan manipuleras och hanteras på sätt som liknar databasposter. Båda funktionerna är avsedda att möjliggöra löst kopplade, mycket flexibla designmönster i kod och automatisering. Egna inställningar lagras dock i en organisation som data och Egna metadatatyper lagras som metadata.
Du kan avgöra om något är metadata genom att se om det visas i metadatatäckningsrapporten. Denna rapport kommer även att berätta om nyckelbeteenden för utveckling och distribution för en viss typ av metadata.
Det finns många Salesforce Platform API. Salesforce Platform API har stöd för olika dataformat och protokoll, olika operationstyper och timings. Vissa API låter dig interagera med data i en Salesforce-organisation, medan andra har stöd för interaktioner med metadata i en viss organisation. Vissa API
En viktig del av ljudprogramarkitekturen är att se till att programutvecklare använder rätt API (och API-version) för ett givet användningsfall. Du måste överväga de inbyggda API-gränserna för dina Salesforce-organisationer, varav många avgörs av version och funktionsaktivering. Salesforce Platform API har stöd för bakåtkompatibel användning, vilket innebär att implementeringar med en viss version ska fungera stabilt och enhetligt, även när nya API-versioner släpps. Om du vill införliva ny eller ändrad funktionalitet från en ny API-version kan du behöva omfaktorisera din app innan du uppgraderar referenser till den nya API-versionen.
De många olika Salesforce Platform API, tillsammans med hastigheten på Salesforce API-versioner, lägger till betydande komplexitet i livscykeln för alla program som använder Salesforce API. Du måste planera för regelbundna utvärderingar av Salesforce Platform API-referenser i dina program och prioritera planerade API-underhållscykler för att hålla program igång förutsägbart och korrekt.