A Salesforce Customer 360 Platform fornece uma poderosa arquitetura baseada em metadados para cada instância individual do locatário do Salesforce (aka “org”). Este documento de fundamentos da arquitetura apresenta uma visão geral das áreas em que a arquitetura subjacente da Salesforce Platform cria uma consideração crucial para as arquiteturas de soluções criadas na plataforma.

Há três áreas essenciais para entender ao projetar arquiteturas no Salesforce Platform:

• Operações
• Metadata Versus Data
• APIs da plataforma

Na Salesforce Platform, uma transação pode ser instanciada por execução de código e/ou uma operação de banco de dados. Uma competência fundamental para arquitetura no Salesforce é entender como a plataforma define e controla transações para locatários. Para manter os recursos para todos os locatários, o Salesforce impõe limites a cada locatário, calculados por transação e por organização.

No nível transacional, o Salesforce define limites de governador e execução para garantir que instâncias individuais de execução de código e transações de banco de dados não monopolizem recursos computacionais compartilhados. No nível da organização, o Salesforce define limites com base na edição e no tipo de recurso. Os limites para toda a organização também incluem um cálculo progressivo do uso de API em todas as transações na organização, que estão sujeitos a limites de API.

Vamos analisar em mais detalhes duas partes importantes das transações no Salesforce Platform: contexto de execução e manipulação de banco de dados.

O Salesforce calcula os limites transacionais com base em um conceito de contexto de execução. É importante entender que, para aplicativos Salesforce, isso não é exclusivo de execuções de código personalizado em uma única organização do Salesforce. O contexto da execução é baseado no mecanismo de tempo de execução da plataforma e em todo o código disponível para o mecanismo de tempo de execução para um determinado locatário. Isso significa que o código personalizado definido em uma organização do locatário, o código de pacotes instalados com essa organização, bem como o código contido em serviços da Salesforce Platform, podem instanciar uma transação. A plataforma faz a distinção entre diferentes tipos de Apex code e calcula os limites do regulador com base nessas distinções.

Consulte o guia do desenvolvedor do Apex para obter mais informações sobre os limites de transações do Apex.

Quando uma transação envolve manipulação de banco de dados, uma ordem de execução integrada prescreve como diferentes partes da configuração e do código da sua organização se comportarão. Uma chave para entender como usar corretamente a ordem de execução em seus aplicativos Salesforce é entender a integridade de dados robusta que esse comportamento fornece para seus aplicativos Salesforce.

A plataforma expõe variáveis de contexto para o estado das operações de banco de dados na forma de variáveis de contexto de acionador. É importante entender que essas variáveis de contexto do acionador descrevem os estados de tempo de execução para todas as transações de banco de dados na organização do Salesforce, independentemente de Acionadores do Apex personalizados terem sido definidos ou não nessa organização. Eles estão disponíveis para ferramentas declarativas, como o Salesforce Flow.

No Salesforce, os dados não são confirmados (nem as transações de dados são finalizadas) até que os comportamentos de acionador final depois descritos na ordem de execução tenham sido concluídos com êxito. Isso significa que qualquer erro fatal ou comportamento desqualificador durante uma transação de dados que ocorra em contextos antes ou depois de contextos fará com que a plataforma reverta todas as operações de dados dentro da transação. Alterações solicitadas a dados de registro não são confirmadas no banco de dados e nenhuma lógica pós-confirmação é executada. (O Apex expõe métodos de banco de dados para permitir um controle mais granular de pontos de salvamento e comportamento de reversão.)

Um antipadrão importante a evitar na sua arquitetura do Salesforce está tentando reduzir ou substituir o comportamento de execução integrado da plataforma.

Para ver mais detalhadamente a lógica por trás desses comportamentos integrados de integridade de dados, consulte Inside and Out: Transações no blog de Engenharia do Salesforce.

Ao escolher como personalizar e estender em uma organização do Salesforce, é importante entender o que será considerado como dados e o que será considerado como metadados do ponto de vista da Salesforce Platform. Para aprofundar-se na arquitetura subjacente por trás desta distinção de dados/metadados, consulte o documento Fundamentos da Arquitetura Multilocatária da Plataforma.

Essa distinção afetará muitos aspectos do ciclo de vida do seu aplicativo, como: se um artefato será ou não copiado para os ambientes de desenvolvimento de sandbox, como ele pode ser migrado para outros ambientes, se ele pode ou não fazer parte de um pacote.

A tabela abaixo oferece uma rápida comparação do desempenho de dados vs. metadados conforme relacionado às principais partes do ciclo de vida do aplicativo:

Às vezes, essa distinção é bastante óbvia. Por exemplo, registros individuais em uma organização do Salesforce são dados. Os vários sObjects em uma organização são metadados.

As distinções podem ser mais complexas quando se trata de recursos de configuração da organização. Um exemplo importante é Configurações personalizadas vs. Tipo de metadados personalizados. Ambos os recursos permitem que você configure informações em uma organização para que elas fiquem facilmente disponíveis no tempo de execução e possam ser manipuladas e gerenciadas de maneiras semelhantes a registros de banco de dados. Ambos os recursos são destinados a permitir padrões de design altamente flexíveis e soltos em código e automação. No entanto, as Configurações personalizadas são armazenadas em uma organização como dados e os Tipos de metadados personalizados são armazenados como metadados.

Você pode determinar se algo é metadados vendo se ele aparece no Relatório de cobertura de metadados. Esse relatório também informará sobre os principais comportamentos de desenvolvimento e implantação para um determinado tipo de metadados.

Existem muitas APIs da Salesforce Platform. As APIs da Salesforce Platform oferecem suporte a diferentes formatos e protocolos de dados, vários tipos de operação e horários. Algumas APIs permitem que você interaja com os dados em uma organização do Salesforce, enquanto outras oferecem suporte a interações com os metadados em uma determinada organização. Algumas APIs são criadas especificamente para lidar com grandes volumes de transações, outras não. O Salesforce atualiza o número de versão para todas as APIs da Salesforce Platform a cada versão.

Uma parte crucial da arquitetura de aplicativos de som é garantir que os desenvolvedores de aplicativos utilizem a API correta (e a versão da API) para um determinado caso de uso. Você precisará considerar os limites de API integrados para suas organizações do Salesforce, muitos dos quais são determinados pela edição e ativação de recursos. As APIs da Salesforce Platform oferecem suporte ao uso compatível com versões anteriores, o que significa que as implementações com uma versão específica devem ter um desempenho estável e consistente, mesmo que novas versões da API sejam lançadas. Se você quiser incorporar funcionalidades novas ou alteradas de uma nova versão da API, talvez seja necessário refatorar seu aplicativo antes de atualizar referências para a nova versão da API.

As várias APIs diferentes da Salesforce Platform, junto com a velocidade das versões da API do Salesforce, adicionam uma complexidade significativa ao ciclo de vida de qualquer aplicativo que use APIs do Salesforce. Você precisará planejar avaliações regulares das referências à API da Salesforce Platform em seus aplicativos e priorizar os ciclos de manutenção de API planejados para manter os aplicativos em execução de maneira previsível e adequada.