Het Salesforce Customer 360 Platform biedt een krachtige multitenant, metagegevensgestuurde architectuur voor elk afzonderlijk Salesforce-exemplaar van belanghebbenden (aka 'organisatie'). Dit document over de basis van architectuur biedt een overzicht van gebieden waar de onderliggende architectuur van het Salesforce Platform een belangrijke overweging vormt voor de architecturen van oplossingen die op het platform zijn gebouwd.
Er zijn drie essentiële gebieden om te begrijpen bij het ontwerpen van architecturen op het Salesforce Platform:
Op het Salesforce Platform kan een transactie worden geïnstantieerd door code-uitvoering en/of een databasebewerking. Een fundamentele competentie voor het ontwerpen van Salesforce is inzicht in de manier waarop het platform transacties voor belanghebbenden definieert en controleert. Om resources voor alle belanghebbenden te onderhouden, legt Salesforce limieten op aan elke belanghebbende, berekend per transactie en per organisatie.
Op transactieniveau stelt Salesforce governor- en uitvoeringslimieten in om ervoor te zorgen dat afzonderlijke exemplaren van code-uitvoering en databasetransacties geen gedeelde rekenresources monopoliseren. Op organisatieniveau stelt Salesforce limieten in op basis van editie en voorzieningstype. Organisatiebrede limieten omvatten ook een voortschrijdende berekening van API-gebruik voor alle transacties in de organisatie, die onderworpen zijn aan API-limieten.
Laten we twee belangrijke onderdelen van transacties op het Salesforce Platform nader bekijken: uitvoeringscontext en databasemanipulatie.
Salesforce berekent transactielimieten op basis van een concept van uitvoeringscontext. Het is belangrijk om te begrijpen dat dit voor Salesforce-toepassingen niet alleen geldt voor uitvoeringen van aangepaste code binnen één Salesforce-organisatie. Uitvoeringscontext is gebaseerd op de run-time engine van het platform en alle code die beschikbaar is voor de run-time engine voor een bepaalde belanghebbende. Dit betekent dat aangepaste code die is gedefinieerd binnen de organisatie van een belanghebbende, code uit pakketten die bij die organisatie zijn geïnstalleerd, en code die is opgenomen in Salesforce Platform-services, allemaal een transactie kunnen instantiëren. Het platform maakt wel onderscheid tussen verschillende soorten Apex code en berekent beheerlimieten op basis van die verschillen.
Zie de Apex Developer’s Guide voor meer informatie over Apex transactielimieten.
Wanneer een transactie databasemanipulatie omvat, schrijft een ingebouwde uitvoeringsvolgorde voor hoe verschillende onderdelen van de configuratie en code van uw organisatie zullen werken. Een sleutel tot inzicht in de manier waarop u de volgorde van uitvoering correct gebruikt in uw Salesforce-toepassingen, is inzicht in de robuuste gegevensintegriteit die deze werking biedt voor uw Salesforce-toepassingen.
Het platform maakt contextvariabelen zichtbaar voor de status van databasebewerkingen in de vorm van triggercontextvariabelen. Het is belangrijk om te begrijpen dat deze triggercontextvariabelen run-time statussen beschrijven voor alle databasetransacties in Salesforce-organisatie, ongeacht of er aangepaste Apex Triggers zijn gedefinieerd binnen die organisatie. Ze zijn beschikbaar voor declaratieve tools zoals Salesforce Flow.
In Salesforce worden gegevens pas vastgelegd (noch worden gegevenstransacties voltooid) nadat de definitieve werking na de trigger, zoals beschreven in de volgorde van uitvoering, met succes is voltooid. Dit betekent dat fatale fouten of diskwalificerende werkingen tijdens een gegevenstransactie die zich voordoen in voor of na contexten, ertoe leiden dat het platform alle gegevensbewerkingen binnen de transactie terugdraait. Aangevraagde wijzigingen aan recordgegevens worden niet doorgevoerd in de database en er wordt geen post-commit logica uitgevoerd. (Apex maakt wel databasemethoden zichtbaar om meer fijnmazige controle van savepoints en terugdraaiwerking mogelijk te maken.)
Een belangrijk anti-patroon dat u in uw Salesforce-architectuur moet vermijden, is proberen de ingebouwde uitvoeringsvolgorde van het platform te verkorten of te vervangen.
Zie Binnen en buiten voor een diepere blik op de logica achter deze ingebouwde werking van gegevensintegriteit: Transacties op de Salesforce Engineering-blog.
Bij het kiezen van de manier waarop u aanpast en uitbreidt binnen een Salesforce-organisatie, is het belangrijk dat u begrijpt wat als gegevens wordt beschouwd en wat als metagegevens wordt beschouwd vanuit het oogpunt van het Salesforce Platform. Voor een diepgaande duik in de onderliggende architectuur achter dit onderscheid tussen gegevens en metagegevens, in het basisdocument Platform Multitenant Architecture.
Dit onderscheid heeft invloed op vele aspecten van de ontwikkelingslevenscyclus voor uw toepassing, zoals: of een artefact al dan niet wordt gekopieerd naar sandboxontwikkelomgevingen, hoe het kan worden gemigreerd naar andere omgevingen, of het al dan niet onderdeel kan zijn van een pakket.
De onderstaande tabel biedt een snelle vergelijking van de prestaties van gegevens ten opzichte van metagegevens, aangezien deze betrekking hebben op belangrijke onderdelen van de levenscyclus van de toepassing:
| Werking | Data | Metadata |
|---|---|---|
| Van productie naar sandboxomgevingen gekopieerd | Nee* | Ja |
| Migreren op API voor metagegevens | Nee | Ja** |
| Migreren op gegevenslading | Ja | Nee |
| Kan worden opgenomen in pakketten | Nee | Ja** |
| Telt mee voor gegevensopslaglimieten | Ja | Nee |
| *Sandboxen met volledige kopie en gedeeltelijke kopie maken gegevensreplicatie vanuit productie mogelijk. **Sommige typen metagegevens zijn niet beschikbaar voor gebruik met de API voor metagegevens en/of pakketten. U vindt uitzonderingen in het rapport Metagegevensdekking. |
||
Soms is dit onderscheid vrij duidelijk. Afzonderlijke records in een Salesforce-organisatie zijn bijvoorbeeld gegevens. De verschillende sObjects in een organisatie zijn metagegevens.
Onderscheid kan complexer zijn als het gaat om voorzieningen voor organisatieconfiguratie. Een belangrijk voorbeeld is Aangepaste instellingen versus Aangepaste metagegevenstypen. Met beide voorzieningen kunt u informatie in een organisatie dusdanig configureren dat deze gemakkelijk beschikbaar is tijdens run-time en kan worden gemanipuleerd en beheerd op manieren die lijken op databaserecords. Beide functies zijn bedoeld om los gekoppelde, zeer flexibele ontwerppatronen in code en automatisering mogelijk te maken. Aangepaste instellingen worden echter in een organisatie opgeslagen als gegevens en Typen aangepaste metagegevens worden opgeslagen als metagegevens.
U kunt bepalen of iets metagegevens is door te kijken of het wordt weergegeven in het rapport Metagegevensdekking. Dit rapport bevat ook informatie over de belangrijkste ontwikkelings- en implementatiewerkingen voor een bepaald type metagegevens.
Er zijn veel Salesforce Platform-API's. Salesforce Platform-API's ondersteunen verschillende gegevensindelingen en protocollen, verschillende bewerkingstypen en tijdstippen. Sommige API's staan interactie met de gegevens in een Salesforce-organisatie toe, terwijl andere interacties met de metagegevens in een bepaalde organisatie ondersteunen. Sommige API's zijn specifiek ontwikkeld om grote transactievolumes af te handelen, andere niet. Salesforce werkt bij elke release het versienummer voor alle Salesforce Platform-API's bij.
Een belangrijk onderdeel van een goede toepassingsarchitectuur is ervoor te zorgen dat toepassingsontwikkelaars de juiste API gebruiken (en API-versie) voor een bepaalde gebruikscase. U moet rekening houden met de ingebouwde API-limieten voor uw Salesforce-organisaties, waarvan vele worden bepaald door edition en activering van voorzieningen. De Salesforce Platform-API's ondersteunen achterwaarts compatibel gebruik, wat betekent dat implementaties met een bepaalde versie stabiel en consistent moeten presteren, zelfs wanneer nieuwe API-versies worden uitgebracht. Als u nieuwe of gewijzigde functionaliteit wilt opnemen vanuit een nieuwe API-versie, moet u uw app mogelijk een andere factor geven voordat u een upgrade uitvoert van verwijzingen naar de nieuwe API-versie.
De vele verschillende Salesforce Platform-API's, in combinatie met de snelheid van Salesforce API-versies, voegen een aanzienlijke complexiteit toe aan de levenscyclus van alle toepassingen die Salesforce-API's gebruiken. U moet regelmatige evaluaties plannen van de Salesforce Platform API-verwijzingen in uw toepassingen en geplande API-onderhoudscycli prioriteren om toepassingen voorspelbaar en goed werkend te houden.