Salesforce Customer 360 Platform leverer en effektiv flertillænder-metadata-styret arkitektur til hver enkelt Salesforce-lejerforekomst (også kaldet "organisation"). Dette arkitektoniske basisdokument giver en oversigt over områder, hvor den underliggende arkitektur for Salesforce Platform opretter en nøgleovervejelse for arkitekturer for løsninger, der bygger på platformen.
Der er tre vigtige områder, du skal forstå, når du designer arkitekturer på Salesforce Platform:
På Salesforce Platform kan en transaktion oprettes af kodeudførelse og/eller en databasehandling. En grundlæggende kompetence for arkitektur på Salesforce er at forstå, hvordan platformen definerer og kontrollerer transaktioner for lejere. For at vedligeholde ressourcer for alle lejere pålægger Salesforce grænser på hver lejer, beregnet på pr. transaktion og pr. organisationsbasis.
På transaktionsniveau angiver Salesforce administrator- og kørselsgrænser for at sikre, at individuelle forekomster af kodeeksport og databasetransaktioner ikke monopoliserer delte beregningsressourcer. På organisationsniveau angiver Salesforce grænser baseret på version og funktionstype. Grænser for hele organisationen inkluderer også en rullende beregning af API-anvendelse på tværs af alle transaktioner i organisationen, som er underlagt API-grænser.
Lad os se nærmere på to vigtige dele af transaktioner på Salesforce Platform: kørselskontekst og databasemanipulation.
Salesforce beregner transaktionsbegrænsninger baseret på et koncept af kørselskontekst. Det er vigtigt at forstå, at for Salesforce-applikationer er dette ikke eksklusivt for kørsler af tilpasset kode i en enkelt Salesforce-organisation. Kørselskonteksten er baseret på platformens kørselssystem og al kode, der er tilgængelig for kørselssystemet for en bestemt lejer. Dette betyder, at tilpasset kode, der er defineret i en lejers organisation, kode fra pakker, der er installeret med den pågældende organisation, samt kode, der er indeholdt i Salesforce Platform-tjenester, alle kan oprette en transaktion. Platformen skelner mellem forskellige typer Apex og beregner styringsbegrænsninger baseret på disse forskelle.
Se Apex-udviklerens vejledning for at få mere at vide om Apex-transaktionsgrænser.
Når en transaktion involverer databasemanipulation, bestemmer en indbygget udførelsesrækkefølge, hvordan forskellige dele af din organisations konfiguration og kode skal fungere. En nøgle til at forstå, hvordan du korrekt bruger kørselsrækkefølgen i dine Salesforce-applikationer, er at forstå den robuste dataintegritet, denne adfærd giver for dine Salesforce-applikationer.
Platformen viser kontekstvariabler for tilstanden af databasehandlinger i form af udløserkontekstvariabler. Det er vigtigt at forstå, at disse udløserkontekstvariabler beskriver kørselstilstande for alle databasetransaktioner i Salesforce-organisationen – uanset om der er defineret tilpassede Apex i den pågældende organisation. De er tilgængelige for deklarative værktøjer som Salesforce-forløb.
I Salesforce bekræftes data ikke (og datatransaktioner afsluttes ikke), før den endelige efter udløsningsadfærd, der er beskrevet i kørselsrækkefølgen, er fuldført. Dette betyder, at eventuelle fatale fejl eller diskvalificerende adfærd under en datatransaktion, der forekommer i kontekster før eller efter kontekster, vil få platformen til at rulle tilbage alle datatransaktioner i transaktionen. Anmodede ændringer af registreringsdata bekræftes ikke i databasen, og der afvikles ingen efter-bekræftelseslogik. (Apex viser databasemetoder for at muliggøre mere detaljeret kontrol af lagringspunkter og tilbagerulningsadfærd).
Et nøgle-modemønster, der skal undgås i din Salesforce-arkitektur, er et forsøg på at afkorte eller erstatte platformens indbyggede kørselsadfærd.
Hvis du vil se nærmere på logikken bag disse indbyggede dataintegritetsadfærd, kan du se Inside og Out: Transaktioner på Salesforce Engineering-bloggen.
Når du vælger, hvordan du tilpasser og udvider i en Salesforce-organisation, er det vigtigt at forstå, hvad der skal betragtes som data, og hvad der skal betragtes som metadata fra Salesforce Platforms synspunkt. For en dybdegående indsigt i den underliggende arkitektur bag denne data/metadata-forskel, i Platform Multitenant Architecture fundamentals doc.
Denne forskel vil påvirke mange aspekter af udviklingslivscyklussen for din applikation, f.eks.: om et artefakt vil blive kopieret over i sandbox-udviklingsmiljøer, hvordan det kan migreres til andre miljøer, om det kan være en del af en pakke eller ej.
Tabellen nedenfor tilbyder en hurtig sammenligning af ydeevnen af data i forhold til metadata, da de er relateret til vigtige dele af applikationens livscyklus:
| Adfærd | Data | Metadata |
|---|---|---|
| Kopieret fra produktion til sandbox-miljøer | Nej* | Ja |
| Migrer efter metadata-API | Nej | Ja** |
| Migrer efter dataindlæsning | Ja | Nej |
| Kan inkluderes i pakker | Nej | Ja** |
| Tæller med i datalagringsgrænser | Ja | Nej |
| *Fuld kopi og delvise kopi-sandboxes tillader datareplikering fra produktion. **Nogle metadatatyper er ikke tilgængelige for brug med Metadata API og/eller pakker. Du kan finde undtagelser i Metadata Coverage Report. |
||
Nogle gange er denne forskel temmelig åbenlys. F.eks. er individuelle registreringer i en Salesforce-organisation data. De forskellige sObjects i en organisation er metadata.
Forskelle kan være mere komplekse, når det gælder organisationskonfigurationsfunktioner. Et vigtigt eksempel er tilpassede indstillinger i forhold til tilpassede metadatatyper. Begge disse funktioner giver dig mulighed for at konfigurere oplysninger i en organisation, så de er nemt tilgængelige på kørselstidspunktet og kan manipuleres og administreres på måder, der svarer til databaseregistreringer. Begge funktioner er beregnet til at tillade løst sammenkoblede, meget fleksible designmønstre i kode og automatisering. Men Tilpassede indstillinger lagres i en organisation som data, og Tilpassede metadatatyper lagres som metadata.
Du kan bestemme, om noget er metadata ved at se, om det vises i Metadata Coverage Report. Denne rapport vil også fortælle dig om nøgleudvikling og implementeringsadfærd for en bestemt type metadata.
Der findes mange Salesforce Platform-API'er. Salesforce Platform-API'er understøtter forskellige dataformater og -protokoller, forskellige handlingstyper og tidsangivelser. Nogle API'er giver dig mulighed for at interagere med data i en Salesforce-organisation, mens andre understøtter interaktioner med metadata i en given organisation. Nogle API'er er bygget specielt til at håndtere store transaktionsmængder, andre er ikke. Salesforce opdaterer versionsnummeret for alle Salesforce Platform-API'er med hver version.
En vigtig del af en sund applikationsarkitektur er at sikre, at applikationsudviklere bruger den korrekte API (og API-version) til en given anvendelsessituation. Du skal overveje de indbyggede API-grænser for dine Salesforce-organisationer, hvoraf mange bestemmes af version og funktionsaktivering. Salesforce Platform-API'er understøtter bagudkompatibel brug, hvilket betyder, at implementeringer med en bestemt version skal fungere stabilt og ensartet, selv når der frigives nye API-versioner. Hvis du ønsker at indarbejde ny eller ændret funktionalitet fra en ny API-version, skal du muligvis omstrukturere din app, før du opgraderer referencer til den nye API-version.
De mange forskellige Salesforce Platform-API'er sammen med hastigheden af Salesforce API-versioner føjer væsentlig kompleksitet til livscyklussen for alle applikationer, der bruger Salesforce-API'er. Du skal planlægge regelmæssige evalueringer af Salesforce Platform API-referencer i dine applikationer og prioritere planlagte API-vedligeholdelsescyklusser for at holde applikationer kørende forudsigeligt og korrekt.