Salesforce Customer 360 Platform gir hver enkelt Salesforce-leietagerforekomst (også kalt «organisasjon») en kraftig multitender-metadatadrevet arkitektur. Dette grunnleggende dokumentet for arkitektur gir en oversikt over områder der den underliggende arkitekturen til Salesforce Platform oppretter en nøkkelvurdering for arkitekturene til løsninger som bygger på plattformen.
Det er tre viktige områder du må forstå når du utformer arkitekturer på Salesforce Platform:
På Salesforce Platform kan en transaksjon instansieres ved utføring av kode og/eller en databaseoperasjon. En grunnleggende kompetanse for arkitektur på Salesforce er å forstå hvordan plattformen definerer og kontrollerer transaksjoner for leietagere. For å opprettholde ressurser for alle leietagere pålegger Salesforce grenser for hver leietager, beregnet per transaksjon og per organisasjonsbasis.
På transaksjonsnivå angir Salesforce styrings- og utførelsesgrenser for å sikre at individuelle forekomster av kodeutførelse og databasetransaksjoner ikke monopoliserer delte databehandlingsressurser. På organisasjonsomfattende nivå angir Salesforce grenser basert på versjon og funksjonstype. Organisasjonsomfattende grenser inkluderer også en rullende beregning av API-bruk på tvers av alle transaksjoner i organisasjonen, som er underlagt API-grenser.
La oss se nærmere på to viktige deler av transaksjoner på Salesforce Platform: utførelseskontekst og databasemanipulering.
Salesforce beregner transaksjonsgrenser basert på et konsept av utførelseskontekst. Det er viktig å forstå at for Salesforce-programmer er dette ikke eksklusivt for utføring av tilpasset kode i en enkelt Salesforce-organisasjon. Utførelseskonteksten er basert på plattformkjøretidsmotoren og all kode som er tilgjengelig for kjøretidsmotoren for en bestemt leietaker. Det betyr at tilpasset kode som er definert i en leietagerorganisasjon, kode fra pakker som er installert med denne organisasjonen, og kode som finnes i Salesforce Platform-tjenester, alle kan instansiere en transaksjon. Plattformen skiller mellom forskjellige typer Apex og beregner styringsgrenser basert på disse forskjellene.
Se Apex-utviklerveiledningen for å få mer informasjon om Apex-transaksjonsgrenser.
Når en transaksjon involverer databasemanipulering, bestemmer en innebygd utførelsesrekkefølge hvordan ulike deler av organisasjonens konfigurasjon og kode vil virke. En nøkkel for å forstå hvordan du bruker utførelsesrekkefølgen riktig i Salesforce-programmene dine, er å forstå den robuste dataintegriteten denne virkemåten gir for Salesforce-programmene dine.
Plattformen viser kontekstvariabler for tilstanden til databaseoperasjoner i form av utløserkontekstvariabler. Det er viktig å forstå at disse utløserkontekstvariablene beskriver kjøretidstilstander for alle databasetransaksjoner i Salesforce-organisasjonen, enten tilpassede Apex er definert eller ikke i den organisasjonen. De er tilgjengelig for deklarative verktøy som Salesforce-flyt.
I Salesforce blir data ikke bekreftet (og datatransaksjoner er ikke fullført) før den endelige virkemåten etter utløseren som er beskrevet i utførelsesrekkefølgen, er fullført. Dette betyr at eventuelle fatale feil eller diskvalifiserende virkemåter under en datatransaksjon som skjer i kontekster før eller etter kontekster, vil føre til at plattformen ruller tilbake alle dataoperasjoner i transaksjonen. Forespurte endringer i postdata bekreftes ikke til databasen, og ingen post-commit-logikk utføres. (Apex viser databasemetoder for å muliggjøre mer detaljert kontroll av lagringspunkter og tilbakestillingsvirkemåte.)
Et viktig anti-mønster som bør unngås i Salesforce-arkitekturen, er å forsøke å forkorte eller erstatte plattformens innebygde virkemåte ved utførelse.
Hvis du vil se nærmere på logikken bak disse innebygde virkemåtene for dataintegritet, kan du se Inside and Out: Transaksjoner på Salesforce Engineering-bloggen.
Når du velger hvordan du tilpasser og utvider i en Salesforce-organisasjon, er det viktig å forstå hva som skal vurderes som data og hva som skal vurderes som metadata fra Salesforce Platform-perspektivet. For en dypere innsikt i den underliggende arkitekturen bak denne forskjellen mellom data og metadata, i Platform Multitenant Architecture fundamentals doc.
Denne forskjellen vil påvirke mange aspekter av utviklingslivssyklusen for programmet ditt, for eksempel om en gjenstand vil bli kopiert over til Sandbox-utviklingsmiljøer, hvordan den kan overføres til andre miljøer, om den kan være en del av en pakke eller ikke.
Tabellen nedenfor gir en rask sammenligning av ytelsen til data kontra metadata i forhold til viktige deler av programlivssyklusen:
| Virkemåte | Data | Metadata |
|---|---|---|
| kopieres fra produksjon til Sandbox-miljøer | Nei* | Ja |
| Overføre etter Metadata API | Nei | Ja** |
| Overføre etter datalasting | Ja | Nei |
| Kan inkluderes i pakker | Nei | Ja** |
| Teller mot datalagringsgrenser | Ja | Nei |
| *Full kopi- og delvis kopi-Sandbox-organisasjoner tillater datareplikering fra produksjonsorganisasjonen. **Enkelte metadatatyper er ikke tilgjengelig for bruk med Metadata API og/eller pakker. Du finner unntak i Metadatadekningsrapporten. |
||
Noen ganger er denne forskjellen ganske åpenbar. Enkeltposter i en Salesforce-organisasjon er for eksempel data. De forskjellige sObjects i en organisasjon er metadata.
Forskjeller kan være mer komplekse når det gjelder organisasjonskonfigurasjonsfunksjoner. Et viktig eksempel er Tilpassede innstillinger kontra Tilpassede metadatatyper. Med begge disse funksjonene kan du konfigurere informasjon i en organisasjon slik at den enkelt er tilgjengelig ved kjøretid, og kan manipuleres og behandles på måter som ligner databaseposter. Begge funksjonene er ment å tillate løst koblede, svært fleksible designmønstre i kode og automatisering. Tilpassede innstillinger lagres imidlertid som data i en organisasjon, og tilpassede metadatatyper lagres som metadata.
Du kan finne ut om noe er metadata ved å se om det vises i Metadata-dekningsrapporten. Denne rapporten forteller deg også om viktige utviklings- og distribusjonsvirkemåter for en bestemt type metadata.
Det finnes mange Salesforce Platform APIer. Salesforce Platform-API-er støtter forskjellige dataformater og protokoller, ulike operasjonstyper og tidspunkter. Enkelte API-er lar deg samhandle med dataene i en Salesforce-organisasjon, mens andre støtter interaksjoner med metadataene i en gitt organisasjon. Noen API-er er bygget spesielt for å håndtere store transaksjonsvolumer, andre er ikke det. Salesforce oppdaterer versjonsnummeret for alle Salesforce Platform-API-er med hver utgivelse.
En viktig del av lydprogramarkitekturen er å sørge for at programutviklere bruker riktig API (og API-versjon) for et gitt bruksområde. Du må vurdere de innebygde API-grensene for Salesforce-organisasjonene, mange av dem bestemmes av versjon og funksjonsaktivering. Salesforce Platform API-ene støtter bakoverkompatibel bruk, noe som betyr at implementeringer med en bestemt versjon skal fungere stabilt og konsistent, selv om nye API-versjoner utgis. Hvis du vil innlemme ny eller endret funksjonalitet fra en ny API-versjon, kan det hende du må omgjøre appen før du oppgraderer referanser til den nye API-versjonen.
De mange forskjellige Salesforce Platform API-ene, sammen med hastigheten på Salesforce API-versjoner, legger til betydelig kompleksitet i livssyklusen til eventuelle programmer som bruker Salesforce API-er. Du må planlegge regelmessige evalueringer av Salesforce Platform API-referansene i programmene og prioritere planlagte API-vedlikeholdssykluser for å holde programmene i gang på forutsigbar og riktig måte.