Salesforce Customer 360 Platform offre una potente architettura multi-tenant basata sui metadati a ogni singola istanza tenant di Salesforce (detta anche «organizzazione»). Questo documento di base sull'architettura offre una panoramica delle aree in cui l'architettura sottostante di Salesforce Platform crea una considerazione chiave per le architetture delle soluzioni create sulla piattaforma.

Quando si progettano architetture in Salesforce Platform è necessario comprendere tre aspetti essenziali:

• Transazioni
• Metadati e dati
• API piattaforma

In Salesforce Platform, una transazione può essere istanziata mediante l'esecuzione di codice e/o un'operazione di database. Una competenza fondamentale per l'architettura in Salesforce è capire come la piattaforma definisce e controlla le transazioni per i tenant. Per mantenere le risorse per tutti i tenant, Salesforce impone dei limiti a ogni tenant, calcolati per transazione e per organizzazione.

A livello transazionale, Salesforce imposta limiti di esecuzione per garantire che le singole istanze di esecuzione del codice e le transazioni del database non monopolizzino le risorse di elaborazione condivise. A livello di organizzazione, Salesforce imposta dei limiti in base alla versione e tipo di funzione. I limiti dell'organizzazione includono anche un calcolo periodico dell'utilizzo dell'API in tutte le transazioni dell'organizzazione, che sono soggette ai limiti API.

Vediamo più in dettaglio due parti chiave delle transazioni in Salesforce Platform: il contesto di esecuzione e la manipolazione del database.

Salesforce calcola i limiti delle transazioni in base a un concetto di contesto di esecuzione. È importante tenere presente che per le applicazioni Salesforce ciò non riguarda esclusivamente le esecuzioni di codice personalizzato all'interno di una singola organizzazione Salesforce. Il contesto di esecuzione si basa sul motore di runtime piattaforma e su tutto il codice disponibile per il motore di runtime per un tenant specifico. Ciò significa che il codice personalizzato definito all'interno di un'organizzazione tenant, il codice dei pacchetti installati con tale organizzazione e il codice contenuto nei servizi Salesforce Platform possono istanziare una transazione. La piattaforma distingue i diversi tipi di Apex Code e calcola i limiti del governor in base a tali distinzioni.

Vedere la guida per sviluppatori Apex per ulteriori informazioni sui limiti delle transazioni Apex.

Quando una transazione implica la manipolazione del database, un ordine di esecuzione incorporato prescrive come si comporteranno le diverse parti della configurazione e del codice dell'organizzazione. Una chiave per capire come utilizzare correttamente l'ordine di esecuzione nelle applicazioni Salesforce è capire la solida integrità dei dati fornita da questo comportamento per le applicazioni Salesforce.

La piattaforma espone le variabili di contesto per lo stato delle operazioni del database sotto forma di variabili di contesto trigger. È importante capire che queste variabili di contesto dei trigger descrivono gli stati di runtime per tutte le transazioni di database nell'organizzazione Salesforce, indipendentemente dal fatto che nell'organizzazione siano stati definiti trigger Apex personalizzati. Sono disponibili per strumenti dichiarativi come Flusso Salesforce.

In Salesforce, i dati non vengono confermati (né le transazioni dei dati vengono finalizzate) fino a quando i comportamenti finali dopo il trigger descritti nell'ordine di esecuzione non vengono completati correttamente. Ciò significa che eventuali errori fatali o comportamenti non idonei durante una transazione di dati che si verificano in contesti precedenti o successivi causeranno il ritiro di tutte le operazioni sui dati all'interno della transazione. Le modifiche richieste ai dati dei record non vengono confermate nel database e non viene eseguita alcuna logica post-commit. (Apex espone i metodi del database per consentire un controllo più granulare dei punti di salvataggio e del comportamento di ritiro).

Un anti-schema chiave da evitare nell'architettura Salesforce è il tentativo di abbreviare o sostituire l'ordine di esecuzione incorporato della piattaforma.

Per un'analisi più approfondita della logica alla base di questi comportamenti di integrità dei dati incorporati, vedere Inside and Out: Transazioni nel blog di Salesforce Engineering.

Quando si sceglie come personalizzare ed estendere all'interno di un'organizzazione Salesforce, è importante capire quali dati verranno considerati e quali metadati verranno considerati dal punto di vista di Salesforce Platform. Per un'analisi approfondita dell'architettura sottostante a questa distinzione dati/metadati, nel documento Platform Multitenant Architecture Fundamentals doc.

Questa distinzione avrà effetto su molti aspetti del ciclo di vita dello sviluppo dell'applicazione, ad esempio: se un artefatto verrà copiato o meno negli ambienti di sviluppo Sandbox, come può essere migrato ad altri ambienti, se può o meno far parte di un pacchetto.

La tabella seguente offre un rapido confronto tra le prestazioni dei dati e i metadati in relazione alle parti chiave del ciclo di vita dell'applicazione:

A volte questa distinzione è abbastanza ovvia. Ad esempio, i singoli record di un'organizzazione Salesforce sono dati. I vari sObject di un'organizzazione sono metadati.

Le distinzioni possono essere più complesse quando si tratta di funzioni di configurazione dell'organizzazione. Un esempio chiave è Impostazioni personalizzate e Tipi di metadati personalizzati. Entrambe queste funzioni consentono di configurare le informazioni in un'organizzazione in modo che siano facilmente disponibili in fase di esecuzione e possano essere manipolate e gestite in modo simile ai record del database. Entrambe le funzioni sono destinate a consentire schemi di progettazione vagamente accoppiati e altamente flessibili nel codice e nell'automazione. Tuttavia, le impostazioni personalizzate sono memorizzate in un'organizzazione come dati e i tipi di metadati personalizzati come metadati.

È possibile determinare se un elemento è un metadati controllando se appare nel rapporto copertura metadati. Questo rapporto illustrerà anche i principali comportamenti di sviluppo e distribuzione per un particolare tipo di metadati.

Esistono molte API Salesforce Platform. Le API Salesforce Platform supportano diversi formati di dati e protocolli, diversi tipi di operazioni e tempistiche. Alcune API consentono di interagire con i dati di un'organizzazione Salesforce, mentre altre supportano le interazioni con i metadati di una determinata organizzazione. Alcune API sono create appositamente per gestire grandi volumi di transazioni, altre no. Salesforce aggiorna il numero di versione di tutte le API Salesforce Platform a ogni rilascio.

Una parte fondamentale dell'architettura di un'applicazione è assicurarsi che gli sviluppatori di applicazioni utilizzino l'API (e la versione API) corretta per un determinato caso d'uso. Sarà necessario considerare i limiti API incorporati per le organizzazioni Salesforce, molti dei quali sono determinati dalla versione e dall'attivazione delle funzioni. Le API Salesforce Platform supportano l'utilizzo compatibile con le versioni precedenti, il che significa che le implementazioni con una determinata versione devono funzionare con stabilità e coerenza, anche quando vengono rilasciate nuove versioni API. Se si desidera incorporare funzionalità nuove o modificate da una nuova versione API, può essere necessario eseguire il refactoring dell'app prima di aggiornare i riferimenti alla nuova versione API.

Le numerose API Salesforce Platform, insieme alla velocità delle versioni API Salesforce, aggiungono una complessità significativa al ciclo di vita di tutte le applicazioni che utilizzano le API Salesforce. Sarà necessario pianificare valutazioni periodiche dei riferimenti API Salesforce Platform nelle applicazioni e assegnare la priorità ai cicli di manutenzione API pianificati per mantenere le applicazioni in esecuzione in modo prevedibile e corretto.