Visão geral de padrões de integração

Geralmente, ao implementar o Salesforce, você precisa integrá-lo a outros aplicativos. Embora cada cenário de integração seja exclusivo, há requisitos e problemas comuns que os desenvolvedores e os arquitetos devem resolver.

Este documento descreve estratégias (na forma de padrões) para esses cenários de integração comuns. Cada padrão descreve o design e a abordagem para um cenário específico, em vez de detalhar uma implementação específica. Neste documento, você encontrará:

• Vários padrões que tratam dos principais cenários de integração de “arquiteto”
• Uma matriz de seleção para ajudar a determinar qual padrão é mais adequado ao seu cenário
• Dicas e práticas recomendadas de integração

Objetivo e alcance

Este documento é para designers e arquitetos que precisam integrar a Salesforce Platform a outros aplicativos em suas empresas. Destilamos esse conteúdo de muitas implementações bem-sucedidas.

Para se familiarizar com as funcionalidades e opções de integração disponíveis para adoção em grande escala de aplicativos baseados no Salesforce, leia o Resumo do padrão e o Guia de seleção de padrão. Arquitetos e desenvolvedores devem aplicar esses detalhes de padrão e práticas recomendadas durante a fase de design e implementação de um projeto de integração do Salesforce.

Se implementados adequadamente, esses padrões permitem que você entre na produção o mais rápido possível e tenha o conjunto de aplicativos mais estável, escalonável e livre de manutenção possível. Os próprios arquitetos de consultoria do Salesforce usam esses padrões como pontos de referência durante revisões de arquitetura e os mantêm e melhoram ativamente.

Como acontece com todos os padrões, esse conteúdo abrange a maioria dos cenários de integração, mas não todos. Embora o Salesforce permita a integração da interface do usuário (UI), mascaramentos, por exemplo, essa integração está fora do escopo desse documento.

Modelo de padrão

Cada padrão de integração segue uma estrutura consistente. Essa estrutura facilita a comparação de padrões e a localização de informações relevantes.

Nome

O identificador de padrão que também indica o tipo de integração contido no padrão.

Contexto

O cenário geral de integração que o padrão aborda. O contexto fornece informações sobre o que os usuários estão tentando realizar e como o aplicativo se comportará para dar suporte aos requisitos.

Problema

O cenário ou problema (expresso como uma pergunta) para o qual o padrão foi projetado. Ao revisar os padrões, leia esta seção para entender rapidamente se o padrão é adequado para seu cenário de integração.

Forças

As restrições e circunstâncias que tornam o cenário declarado difícil de resolver.

Solução

A maneira recomendada de resolver o cenário de integração.

Esboço

Um diagrama de sequência UML que mostra como a solução lida com o cenário.

Resultados

Explica os detalhes de como aplicar a solução ao seu cenário de integração e como ela resolve as forças associadas a esse cenário. Esta seção também contém novos desafios que podem surgir como resultado da aplicação do padrão.

Barra lateral

Seções adicionais relacionadas ao padrão que contêm os principais problemas técnicos, variações do padrão, preocupações específicas do padrão e assim por diante.

Exemplo

Um cenário de ponta a ponta que descreve como o padrão de design é usado em um cenário do Salesforce do mundo real. O exemplo explica as metas de integração e como implementar o padrão para atingir essas metas.

Resumo do padrão

A tabela a seguir lista os padrões de integração contidos neste documento.

Lista de padrões

Abordagem padrão

Os padrões de integração neste documento são classificados em três categorias:

• Integração de dados: Esses padrões tratam da exigência de sincronizar dados que residem em dois ou mais sistemas para que ambos os sistemas sempre contenham dados oportunos e significativos. A integração de dados costuma ser o tipo mais simples de integração a ser implementado, mas requer técnicas adequadas de gerenciamento de informações para tornar a solução sustentável e econômica. Essas técnicas geralmente incluem aspectos de gerenciamento de dados mestre (MDM), governança de dados, domínio, desduplicação, design de fluxo de dados e outros.
• Integração de processos: Os padrões nessa categoria lidam com a necessidade de um processo de negócios aproveitar dois ou mais aplicativos para concluir sua tarefa. Quando você implementa uma solução para esse tipo de integração, o aplicativo acionador precisa chamar outros aplicativos nos limites do processo. Geralmente, esses padrões também incluem orquestração (em que um aplicativo é o “controlador central”) e coreografia (em que os aplicativos são de vários participantes e não há um “controlador central”). Essas integrações geralmente exigem requisitos complexos de design, teste e tratamento de exceções. Além disso, esses aplicativos compostos costumam ser mais exigentes nos sistemas subjacentes, pois geralmente dão suporte a transações de execução longa e a capacidade de gerar ou relatar o estado do processo.
• Integração virtual: Os padrões nessa categoria tratam da necessidade de um usuário visualizar, pesquisar e modificar dados armazenados em um sistema externo. Quando você implementa uma solução para esse tipo de integração, o aplicativo acionador precisa chamar outros aplicativos e interagir com seus dados em tempo real. Esse tipo de integração elimina a necessidade de replicação de dados entre sistemas e significa que os usuários sempre interagem com os dados mais atuais.

Escolher a melhor estratégia de integração para seu sistema não é trivial. Há muitos aspectos a serem considerados e muitas ferramentas que podem ser usadas, sendo que algumas ferramentas são mais adequadas do que outras para determinadas tarefas. Cada padrão aborda áreas críticas específicas, incluindo os recursos de cada um dos sistemas, o volume de dados, o tratamento de falhas e a transacionalidade.

Guia de seleção de padrão

As tabelas de matriz de seleção listam os padrões e seus principais aspectos para ajudá-lo a determinar qual padrão atende melhor aos seus requisitos de integração. Os padrões são categorizados usando estas dimensões.

Integrar o Salesforce com outro sistema

Esta tabela lista os padrões e seus principais aspectos para ajudá-lo a determinar qual padrão atende melhor aos seus requisitos quando sua integração é do Salesforce para outro sistema.

Integrando outro sistema ao Salesforce

Esta tabela lista os padrões e seus principais aspectos para ajudá-lo a determinar o padrão mais adequado aos seus requisitos quando sua integração for de outro sistema para o Salesforce.

Termos e definições do Middleware

Esta tabela lista alguns termos-chave relacionados ao middleware e suas definições com relação a esses padrões.

Além dessas ferramentas de integração, a MuleSoft e a Informatica fornecem os pilares fundamentais para uma estratégia de integração moderna e de alto desempenho. Embora ambos residam no mesmo ecossistema, eles resolvem desafios arquitetônicos distintos. As principais empresas implementam essas plataformas em conjunto para criar uma estrutura abrangente “Melhor juntos” que atenda a todo o espectro de dados e necessidades de aplicativos.

A MuleSoft é a plataforma de integração líder da Salesforce. Permite que as organizações conectem aplicativos, dados e dispositivos em ambientes locais e de nuvem. O MuleSoft fornece a TI as ferramentas para desbloquear dados entre sistemas, desenvolver estruturas de integração e automação escalonáveis e criar experiências diferenciadas e conectadas rapidamente. Ele também pode conectar uma organização principal a uma instância do Anypoint em um catálogo de API para disponibilizar APIs do MuleSoft para invocação no Apex, no Fluxo e no Agentforce como ações. O Anypoint Exchange tem vários conectores do Salesforce predefinidos.

A Informatica é uma plataforma líder de gerenciamento e integração de dados corporativos. Ela ajuda as organizações a coletar, gerenciar, integrar e analisar dados de várias fontes. Ele usa processos ETL (extrair, transformar, carregar) para fornecer os dados conectados e confiáveis necessários para capacitar agentes de IA autônomos e análise moderna.

Contexto

Você usa o Salesforce para rastrear leads, gerenciar seu pipeline, criar oportunidades e capturar detalhes do pedido que convertem leads em clientes. Porém, o sistema do Salesforce não contém nem processa pedidos. Depois que os detalhes do pedido são capturados no Salesforce, o pedido é criado no sistema remoto, que gerencia o pedido até a conclusão.

Quando você implementa esse padrão, o Salesforce chama o sistema remoto para criar o pedido e espera a conclusão bem-sucedida. Se bem-sucedido, o sistema remoto responderá de modo síncrono com o status do pedido e o número do pedido. Como parte da mesma transação, o Salesforce atualiza o número e o status do pedido internamente. O número do pedido é usado como uma chave estrangeira para atualizações subsequentes ao sistema remoto.

Problema

Quando ocorre um evento no Salesforce, como você inicia um processo em um sistema remoto, passa as informações necessárias para esse processo, recebe uma resposta do sistema remoto e então usa esses dados de resposta para fazer atualizações no Salesforce?

Forças

Considere as seguintes forças ao aplicar soluções com base nesse padrão.

• A chamada ao sistema remoto exige que o Salesforce espere uma resposta antes de continuar o processamento? A chamada para o sistema remoto é uma solicitação-resposta síncrona ou uma solicitação assíncrona?
• Se a chamada para o sistema remoto for síncrona, o Salesforce precisará processar a resposta como parte da mesma transação que a chamada inicial?
• O tamanho da mensagem é pequeno ou grande?
• A integração é baseada na ocorrência de um evento específico, como um clique em um botão na interface do usuário do Salesforce, ou em eventos baseados em DML?
• O ponto de extremidade remoto é capaz de responder à solicitação com baixa latência? Quantos usuários provavelmente executarão essa transação durante um período de pico?

Solução

Esta tabela contém soluções para esse problema de integração.

Esboço

Este diagrama ilustra uma invocação de processo remoto síncrono usando chamadas do Apex.

A Salesforce está ligando para um sistema remoto

Neste cenário:

• Uma ação é iniciada na página do Lightning (por exemplo, um clique de botão).
• O navegador (por meio de um controlador do lado do cliente no caso de um componente do Lightning) executa um POST HTTP que, por sua vez, executa uma ação no controlador Apex correspondente.
• O controlador chama a chamada real para o serviço remoto da Web.
• A resposta do sistema remoto é devolvida ao controlador do Apex. O controlador processa a resposta, atualiza os dados no Salesforce conforme necessário e renderiza novamente a página.

Nos casos em que o estado subsequente deve ser rastreado, o sistema remoto retorna um identificador exclusivo armazenado no registro do Salesforce.

Resultados

A aplicação das soluções relacionadas a esse padrão permite chamadas de processo remoto iniciadas por evento em que o Salesforce lida com o processamento.

Mecanismos de chamada

O mecanismo de chamada depende da solução escolhida para implementar esse padrão.

Manuseio e recuperação de erros

É importante incluir uma estratégia de tratamento e recuperação de erros como parte da solução geral.

• Manuseio de erro: Quando ocorre um erro (exceções ou códigos de erro são retornados ao chamador), o chamador gerencia o tratamento de erros. Por exemplo, uma mensagem de erro exibida na página do usuário final ou registrada em uma tabela que requer mais ação.

• Recuperação: As alterações não são confirmadas ao Salesforce até que o chamador receba uma resposta bem-sucedida. Por exemplo, o status do pedido não é atualizado no banco de dados até que uma resposta que indica sucesso seja recebida. Se necessário, o chamador pode tentar a operação novamente.

Considerações sobre design idempotente

Os recursos idempotentes garantem que as invocações repetidas sejam seguras. Se idempotency não for implementado, as invocações repetidas da mesma mensagem poderão ter resultados diferentes, possivelmente resultando em problemas de integridade dos dados. Possíveis problemas incluem a criação de registros duplicados ou o processamento duplicado de transações.

É importante garantir que o procedimento remoto que está sendo chamado seja idempotente. Se a chamada for feita pela interface do usuário, gerencie a idempotência na camada de integração, especialmente se não houver garantia de que o Salesforce chamará a chamada apenas uma vez.

O método mais típico de criar um destinatário idempotente é rastrear duplicados com base em identificadores de mensagem exclusivos enviados pelo consumidor. O serviço da Web do Apex ou as chamadas REST devem ser personalizadas para enviar um ID de mensagem exclusivo.

Além disso, operações que criam registros no sistema remoto devem verificar itens duplicados antes de inserir. Verifique passando um ID de registro exclusivo do Salesforce. Se o registro existir no sistema remoto, atualize o registro. Na maioria dos sistemas, essa operação é chamada de operação de inserção e atualização.

Considerações de segurança

Qualquer chamada a um sistema remoto deve manter a confidencialidade, a integridade e a disponibilidade da solicitação. As seguintes considerações de segurança são específicas para usar chamadas SOAP e HTTP do Apex nesse padrão.

• O SSL unidirecional é habilitado por padrão, mas o SSL bidirecional tem suporte com certificados autoassinados e assinados por CA para manter a autenticidade do cliente e do servidor.
• Para simplificar seu Apex code e simplificar a configuração de chamadas autenticadas, especifique uma credencial nomeada no ponto final de chamada.
• Considere o uso do OAuth 2.0 como o mecanismo de autenticação para integração a sistemas externos.
• Quando necessário, considere usar hashs unidirecionais ou assinaturas digitais usando os métodos de classe do Apex Crypto para garantir a integridade da solicitação.
• O sistema remoto deve ser protegido implementando os mecanismos de firewall adequados. Consulte Considerações de segurança.
• No momento, o Salesforce não oferece suporte à Segurança de WS. Embora não gere nativamente esses cabeçalhos complexos do WS-Security ou os imponha automaticamente a partir de um WSDL recebido, você pode construí-los e implementá-los manualmente criando classes do Apex personalizadas para lidar com os cabeçalhos SOAP e tokens de segurança para solicitações recebidas.

Barra lateral

Nenhum.

Tempo

A pontualidade é de importância significativa nesse padrão. Geralmente:

• A solicitação geralmente é invocada na interface do usuário, portanto, o processo não deve manter o usuário esperando.
• O Salesforce tem um tempo limite configurável de até 120 segundos para chamadas do Apex.
• A conclusão do processo remoto é executada de modo oportuno para ser concluída dentro do limite de tempo limite do Salesforce e dentro das expectativas do usuário.
• Chamadas externas estão sujeitas aos limites do regulador de transações síncronas do Apex, portanto, certifique-se de reduzir o risco de instanciar mais de 50 transações que sejam executadas por mais de cinco segundos cada. Além de garantir o desempenho do ponto de extremidade externo, as opções para mitigar o risco de um tempo limite incluem:
  • Definir o tempo limite da chamada externa para cinco segundos.
  • Usar uma continuação em componentes do Lightning para lidar com transações de execução longa

Volumes de dados

Esse padrão é usado principalmente para atividades em tempo real de pequeno volume, devido aos pequenos valores de tempo limite e tamanho máximo da solicitação ou resposta para a solução de chamada do Apex. Não use esse padrão em atividades de processamento em lote em que a carga de dados está contida na mensagem.

Capacidade de ponto de extremidade e suporte a padrões

A funcionalidade e o suporte padrão para o ponto de extremidade dependem da solução escolhida.

Gestão do Estado

Ao integrar sistemas, as chaves são importantes para o rastreamento de estado contínuo. Há duas opções.

• O Salesforce armazena a chave de substituição primária ou exclusiva do sistema remoto para o registro remoto.
• O sistema remoto armazena o ID de registro exclusivo do Salesforce ou alguma outra chave substituto exclusiva.

Há considerações específicas para lidar com chaves de integração, dependendo do sistema que contém o registro mestre, conforme mostrado na tabela a seguir.

Cenários de integração complexos

Em determinados casos, a solução prescrita por esse padrão pode exigir a implementação de vários cenários de integração complexos. Isso é melhor atendido usando middleware ou fazendo a chamada do Salesforce para um serviço composto. Esses cenários incluem:

• Orquestração de processos de negócios e regras envolvendo lógica de fluxo complexa
• Agregação de chamadas e seus resultados entre chamadas para vários sistemas
• Transformação de mensagens de entrada e de saída
• Manter a integridade transacional em chamadas para vários sistemas

Limites do governador

Para obter informações sobre limites do Apex, consulte Controladores e limites de execução no Guia do desenvolvedor do Apex.

Capacidades do Middleware

A tabela a seguir destaca as propriedades desejáveis de um sistema de middleware que participa desse padrão.

Exemplo

Uma empresa de serviços públicos usa o Salesforce e tem um sistema separado que contém informações de faturamento do cliente. Como parte do processo de pedido, novas contas de faturamento devem ser criadas no sistema de faturamento. O Salesforce deve refletir o número da conta de faturamento no processo de ativação do pedido. A empresa tem uma API REST existente que permite a criação de uma conta de faturamento e retorna o número da conta de faturamento como uma resposta.

Esse requisito pode ser cumprido com a seguinte abordagem.

• O Salesforce consome a API HTTP da conta de cobrança como um serviço externo ou Chamada HTTP do fluxo. Devemos usar uma classe proxy do Apex para consumo de serviço SOAP apenas se o sistema de cobrança fornecer apenas serviços baseados em SOAP e nenhuma API HTTP.
• As informações do cliente são passadas para o objeto de API HTTP externo.
• A chamada de Fluxo HTTP ou Serviço externo retorna a resposta da API HTTP que pode ser armazenada em objetos do Salesforce.
  Este exemplo demonstra que:
• O estado do cliente é rastreado com um número de conta armazenado no objeto de conta do Salesforce.
• O chamador subsequentemente processa a mensagem de resposta.

Contexto

Você usa o Salesforce para rastrear leads, gerenciar seu pipeline, criar oportunidades e capturar detalhes do pedido que convertem leads em clientes. No entanto, como parte dos processos de gerenciamento de pedidos, uma conta de faturamento precisa ser criada no sistema de faturamento para o pedido.

Quando você implementa esse padrão, o Salesforce chama o sistema remoto para criar a conta de faturamento, mas não espera a conclusão bem-sucedida da chamada. O sistema remoto também pode atualizar o Salesforce com a nova conta de faturamento criada em uma transação separada.

Problema

Quando ocorre um evento no Salesforce, como iniciar um processo em um sistema remoto e passar as informações necessárias para esse processo sem esperar uma resposta do sistema remoto?

Forças

Considere as seguintes forças ao aplicar soluções com base nesse padrão.

• A chamada ao sistema remoto exige que o Salesforce espere uma resposta antes de continuar o processamento? A chamada para o sistema remoto é síncrona ou assíncrona?
• Se a chamada para o sistema remoto for síncrona, a resposta precisará ser processada pelo Salesforce como parte da mesma transação que a chamada?
• O tamanho da mensagem é pequeno?
• A integração é baseada na ocorrência de um evento específico, como um clique em um botão na interface do usuário do Salesforce, ou em eventos baseados em DML?
• A entrega garantida de mensagens do Salesforce para o sistema remoto é um requisito?
• O sistema remoto pode participar de uma integração de contrato em primeiro lugar em que o Salesforce especifica o contrato? Em algumas variantes de solução (por exemplo, mensagens de saída), o Salesforce especifica um contrato que o ponto de extremidade do sistema remoto implementa.
• O ponto de extremidade ou o barramento de serviço Enterprise (ESB) oferecem suporte à pesquisa longa?
• Os métodos de configuração declarativa são preferíveis ao desenvolvimento personalizado do Apex? Neste caso, soluções como eventos de plataforma são preferidas às chamadas do Apex.

Solução

A tabela a seguir contém soluções para esse problema de integração.

Esboço

O diagrama a seguir ilustra uma chamada do Salesforce para um sistema remoto em que a criação ou atualização de operações em um registro aciona a chamada.

Baixar diagrama

Neste cenário:

• Um sistema remoto assina o evento de plataforma.
• Uma atualização ou inserção ocorre em um determinado conjunto de registros no Salesforce.
• Um Fluxo do Salesforce é acionado quando um conjunto de condições é atendido.
• Esse fluxo cria um evento de plataforma.
• O ouvinte remoto recebe a mensagem do evento e a coloca em uma fila local.
• O aplicativo de enfileiramento encaminha a mensagem para o aplicativo remoto para processamento.

No caso de o sistema remoto precisar realizar operações em relação ao Salesforce, você pode implementar uma operação de retorno opcional.

Resultados

A aplicação das soluções relacionadas a esse padrão permite:

• Interface do usuário – invocações de processo remoto iniciadas em que o resultado da transação pode ser exibido ao usuário final
• Chamadas de processo remoto iniciadas por evento DML em que o resultado da transação pode ser processado pelo processo de chamada

Mecanismos de chamada

O mecanismo de chamada depende da solução escolhida para implementar esse padrão.

Manuseio e recuperação de erros

Uma estratégia de tratamento e recuperação de erros deve ser considerada como parte da solução geral. O melhor método depende da solução escolhida.

Considerações sobre design idempotente

Os eventos de plataforma são publicados no barramento apenas uma vez. Não há nova tentativa no lado do Salesforce. Cabe ao ESB solicitar que os eventos sejam reproduzidos. Em uma reprodução, o ID de reprodução do evento de plataforma permanece o mesmo e o ESB pode tentar mensagens duplicadas com base no ID de reprodução.

As considerações de design idempotente no padrão Invocação de processo remoto – Solicitação e resposta também se aplicam a esse padrão.

Considerações de segurança

Qualquer chamada a um sistema remoto deve manter a confidencialidade, a integridade e a disponibilidade da solicitação. Diferentes considerações de segurança se aplicam, dependendo da solução escolhida.

Consulte Considerações de segurança.

Barra lateral

Nenhum.

Tempo

A pontualidade é menos um fator com o padrão de incêndio e esquecimento. O controle é devolvido ao cliente imediatamente ou após uma confirmação positiva de uma transferência bem-sucedida para o sistema remoto. Para eventos de plataforma, o Salesforce envia os eventos ao barramento de eventos e não espera uma confirmação ou confirmação do assinante. Se o assinante não selecionar a mensagem, ele poderá solicitar a reprodução do evento usando o ID de resposta do evento. Mensagens de evento de alto volume são armazenadas por 72 horas (três dias). Para recuperar mensagens de evento anteriores, use as APIs Pub/Sub para assinar um canal.

Volumes de dados

As considerações sobre o volume de dados dependem da solução escolhida. Para os limites de cada solução, consulte a Referência rápida de limites do Salesforce.

Capacidade de ponto de extremidade e suporte a padrões

A funcionalidade e o suporte padrão para o ponto de extremidade dependem da solução escolhida.

Gestão do Estado

Ao integrar sistemas, identificadores de registro exclusivos são importantes para rastreamento de estado contínuo. Por exemplo, se um registro for criado no sistema remoto, você terá duas opções.

• O Salesforce armazena a chave de substituição primária ou exclusiva do sistema remoto para o registro remoto.
• O sistema remoto armazena o ID de registro exclusivo do Salesforce ou alguma outra chave substituto exclusiva.

A tabela a seguir lista as considerações para gerenciamento de estado nesse padrão.

Cenários de integração complexos

Cada solução nesse padrão tem considerações diferentes para cenários de integração complexos, como transformação e orquestração de processo.

Limites do governador

Devido à natureza multilocatário da Salesforce Platform, há limites para chamadas de saída. Os limites dependem do tipo de chamada de saída e do momento da chamada.

Para ver os limites e as alocações que se aplicam a eventos de plataforma, consulte o Guia do desenvolvedor de eventos de plataforma.

Mensagens confiáveis

Mensagens confiáveis tentam resolver o problema de garantir a entrega de uma mensagem a um sistema remoto em que os componentes individuais são não confiáveis. O método de garantir o recebimento de uma mensagem pelo sistema remoto depende da solução escolhida.

No caso da Captura de dados de alteração do Salesforce, os tipos de eventos de alteração são fornecidos para lidar com situações especiais, como capturar alterações não capturadas nos servidores de aplicativos do Salesforce ou lidar com grandes cargas de alterações.

Em alguns casos, o Salesforce envia eventos de Lacuna em vez de eventos de alteração para informar os assinantes sobre erros ou se não for possível gerar eventos de alteração. Um evento de lacuna contém informações sobre a alteração no cabeçalho, como o tipo de alteração e o ID do registro. Ele não inclui detalhes sobre a alteração, como campos de registro. Para capturar alterações com mais eficiência, eventos de sobrecarga são gerados para transações únicas que excedem um limite. Para mais informações, consulte aqui.

Capacidades do Middleware

A tabela a seguir destaca as propriedades desejáveis de um sistema de middleware que participa desse padrão.

Variante de solução: Comportamento e transações de publicação de eventos de plataforma

Quando as mensagens de evento de plataforma são publicadas imediatamente, a publicação do evento não respeita os limites da transação do processo de publicação. As mensagens de evento podem ser publicadas antes da conclusão da transação ou mesmo se uma transação falhar. Esse comportamento pode levar a problemas quando um assinante espera encontrar dados que a transação de publicação confirma. Os dados podem não estar presentes quando o assinante recebe a mensagem do evento. Para resolver esse problema, defina o comportamento de publicação de evento de plataforma como Publicar após confirmação na definição de evento. Os comportamentos de publicação que você pode definir em uma definição de evento de plataforma são:

• Publique após a confirmação para que a mensagem do evento seja publicada apenas depois que uma transação for confirmada com sucesso. Selecione essa opção se os assinantes dependem de dados que a transação de publicação confirma. Por exemplo, um processo publica uma mensagem de evento e cria um registro de tarefa. Um segundo processo que é assinado para o evento é acionado e espera localizar o registro da tarefa. Outro motivo para escolher esse comportamento é quando você não deseja que a mensagem do evento seja publicada se a transação falhar.
• Publicar imediatamente para que a mensagem do evento seja publicada quando a chamada de publicação for executada. Selecione essa opção se quiser que a mensagem do evento seja publicada independentemente do sucesso da transação. Também escolha essa opção se o editor e os assinantes forem independentes e os assinantes não dependerem de dados confirmados pelo editor. Por exemplo, o comportamento de publicação imediata é adequado para um evento usado para fins de registro. Com essa opção, um assinante pode receber a mensagem do evento antes que os dados sejam confirmados pela transação do editor.

Exemplo

Uma empresa de telecomunicações quer usar o Salesforce como um front-end para criar contas usando o processo de lead para oportunidade. Um pedido é criado no Salesforce quando a oportunidade é fechada e ganha, mas o sistema ERP de back-end é o mestre de dados. O pedido deve ser salvo no registro de oportunidade do Salesforce e o status da oportunidade mudou para indicar que o pedido foi criado.

As restrições a seguir se aplicam.

• Somente desenvolvimento declarativo pode ser implementado.
• Você não precisa de notificação imediata do número do pedido depois que a oportunidade é convertida em um pedido.
• A organização tem a capacidade de dar suporte a gRPC e HTTP2 para que as APIs do Salesforce Pub/Sub possam ser usadas para assinar eventos de plataforma.

Esse exemplo é melhor implementado usando eventos de plataforma do Salesforce, mas exige que o ESB assine o evento de plataforma.

No lado do Salesforce:

• Crie um fluxo para iniciar o evento de plataforma (por exemplo, quando o status da oportunidade mudar para Fechar e ganho).
• Crie um novo evento de plataforma que publique os detalhes da oportunidade.

No lado do sistema remoto:

• As ferramentas de integração (por exemplo, ESB) assinam o evento da plataforma Salesforce usando a API Pub/Sub.
• O ESB recebe uma ou mais notificações indicando que a oportunidade deve ser convertida em um pedido.
• O ESB encaminha a mensagem para o sistema ERP de back-end para que o pedido possa ser criado.
• Depois que o pedido é criado no sistema ERP, um encadeamento separado chama de volta o Salesforce usando o OAuth 2.0 com um aplicativo conectado. O retorno atualiza a oportunidade com o número e o status do pedido. Você pode fazer esse retorno usando soluções de padrão documentadas, como eventos da plataforma Salesforce, API SOAP do Salesforce, API REST ou um serviço da Web do Apex.

Este exemplo demonstra o seguinte.

• Implementação de um processo remoto invocado de modo assíncrono
• Entrega garantida de ponta a ponta
• Retorno subsequente para o Salesforce para atualizar o estado do registro

Contexto

Você está movendo sua implementação do CRM para o Salesforce e quer:

• Extraia e transforme contas, contatos e oportunidades do sistema CRM atual e carregue os dados no Salesforce (importação inicial de dados).
• Extraia, transforme e carregue dados de faturamento do cliente no Salesforce de um sistema remoto semanalmente (em andamento).
• Extraia informações da atividade do cliente do Salesforce e importe-as para um armazém de dados no local semanalmente (em andamento).

Problema

Como você importa dados para o Salesforce e exporta dados do Salesforce, considerando que essas importações e exportações podem interferir nas operações do usuário final durante o horário comercial e envolver grandes quantidades de dados?

Forças

Há várias forças a serem consideradas ao aplicar soluções com base neste padrão:

• Os dados devem ser armazenados no Salesforce? Caso contrário, há outras opções de integração que um arquiteto pode e deve considerar (mashups, por exemplo).
• Se os dados precisarem ser armazenados no Salesforce, os dados deverão ser atualizados em resposta a um evento no sistema remoto?
• Os dados devem ser atualizados agendadamente?
• Os dados oferecem suporte a processos comerciais principais?
• Há requisitos de análise (relatórios) que são afetados pela disponibilidade desses dados no Salesforce?

Solução

A tabela a seguir contém várias soluções para esse problema de integração.

Esboço

O diagrama a seguir ilustra a sequência de eventos nesse padrão, em que o Salesforce é o mestre de dados.

O diagrama a seguir ilustra a sincronização subsequente de eventos quase em tempo real, em que o Salesforce é o mestre de dados.

Resultados

Você pode integrar dados adquiridos externamente ao Salesforce nos seguintes cenários:

• O sistema externo é o mestre de dados: O Salesforce é um consumidor de dados fornecidos por um único sistema de origem ou vários sistemas. Nesse cenário, é comum ter um armazém de dados ou um data mart que agrega os dados antes de os dados serem importados para o Salesforce.
• O Salesforce é o mestre de dados: O Salesforce é o sistema de registro para determinadas entidades e os aplicativos cliente de Captura de dados de alteração do Salesforce podem ser informados sobre alterações nos dados do Salesforce.

Em um cenário típico de integração do Salesforce, a equipe de implementação realiza uma das seguintes ações:

• Implemente a captura de dados de alteração no conjunto de dados de origem.
• Implemente um conjunto de estruturas de banco de dados de suporte, conhecidas como tabelas de controle, em um banco de dados no local intermediário.

A ferramenta ETL cria programas que:

• Leia uma tabela de controle para determinar o horário de última execução do trabalho e extrair quaisquer outros valores de controle necessários.
• Use os valores de controle acima como filtros e consulte o conjunto de dados de origem.
• Aplique regras de processamento predefinidas, incluindo validação, aprimoramento e assim por diante.
• Use os conectores/funcionalidades de transformação disponíveis da ferramenta ETL para criar o conjunto de dados de destino.
• Escreva o conjunto de dados em objetos do Salesforce.
• Se o processamento for bem-sucedido, atualize os valores de controle na tabela de controle.
• Se o processamento falhar, atualize as tabelas de controle com valores que permitem um novo início e uma saída.

Nota: Recomendamos que você crie as tabelas de controle e as estruturas de dados associadas em um ambiente ao qual a ferramenta ETL tem acesso mesmo que o acesso ao Salesforce não esteja disponível. Isso fornece níveis adequados de resiliência. O Salesforce deve ser tratado como um discurso nesse processo e a infraestrutura ETL é o centro.

Para que uma ferramenta ETL aproveite ao máximo os recursos de sincronização de dados, considere o seguinte:

• Encadeie e sequencie os trabalhos de ETL para proporcionar um processo coeso.
• Use chaves primárias de ambos os sistemas para corresponder os dados recebidos.
• Use métodos de API específicos para extrair apenas dados atualizados.
• Se estiver importando registros filho em um relacionamento entre mestre e detalhes ou de pesquisa, agrupe os dados importados usando sua chave pai na origem para evitar o bloqueio. Por exemplo, se você estiver importando dados de contato, agrupe os dados de contato pela chave da conta pai para que o número máximo de contatos para uma única conta possa ser carregado em uma chamada de API. A falha em agrupar os dados importados geralmente resulta em que o primeiro registro de contato está sendo carregado e os registros de contato subsequentes para essa conta falham no contexto da chamada de API.
• Qualquer processamento pós-importação, como acionadores, deve processar dados apenas de modo seletivo.
• Se o seu cenário envolver grandes volumes de dados, siga as práticas recomendadas deste módulo do Trailhead Práticas recomendadas para implantações com grandes volumes de dados

Manuseio e recuperação de erros

Uma estratégia de tratamento e recuperação de erros deve ser considerada como parte da solução geral. O melhor método depende da solução escolhida.

Considerações de segurança

Qualquer chamada a um sistema remoto deve manter a confidencialidade, a integridade e a disponibilidade da solicitação. Diferentes considerações de segurança se aplicam, dependendo da solução escolhida.

• O acesso de API autenticado à API do Salesforce requer uma licença da Plataforma do Lightning com pelo menos permissões de usuário somente de API.
• Recomendamos que a criptografia padrão seja usada para manter o acesso por senha seguro.
• Use o protocolo HTTPS ao fazer chamadas às APIs do Salesforce. Você também pode proxyar o tráfego para as APIs do Salesforce por meio de uma solução de segurança local, se necessário.

Consulte Considerações de segurança.

Barra lateral

Nenhum.

Tempo

A pontualidade não é de importância significativa nesse padrão. No entanto, é preciso ter cuidado para projetar as interfaces de modo que todos os processos em lote sejam concluídos em uma janela em lote designada.

Como acontece com todas as operações orientadas a lotes, recomendamos que você tenha cuidado para isolar os sistemas de origem e destino durante as janelas de processamento em lote. Carregar lotes durante o horário comercial pode resultar em alguma contenção, resultando na falha da atualização de um usuário ou, mais significativamente, na falha de uma carga de lote (ou carga de lote parcial).

Para organizações que têm operações globais, talvez não seja viável executar todos os processos em lote ao mesmo tempo, pois o sistema pode estar em uso continuamente. As técnicas de segmentação de dados que usam tipos de registro e outros critérios de filtragem podem ser usadas para evitar a contenção de dados nesses casos.

Gestão do Estado

Você pode implementar o gerenciamento de estado usando chaves substitutas entre os dois sistemas. Se você precisar de algum tipo de gerenciamento de transações entre entidades do Salesforce, recomendamos usar o padrão de Chamada remota usando o Apex.

O bloqueio de registro otimizado padrão ocorre na plataforma e quaisquer atualizações feitas usando a API exigem que o usuário, que está editando o registro, atualize o registro e inicie a transação. No contexto da API do Salesforce, o bloqueio otimizado se refere a um processo em que:

• O Salesforce não mantém o estado de um registro sendo editado por um usuário específico.
• Ao ler, ele registra a hora em que os dados foram extraídos.
• Se o usuário atualizar o registro e salvá-lo, o Salesforce verificará se outro usuário atualizou o registro no meio do tempo.
• Se o registro tiver sido atualizado, o sistema notificará o usuário de que uma atualização foi feita e o usuário deverá recuperar a versão mais recente do registro antes de prosseguir com as atualizações.

Capacidades do Middleware

As tecnologias externas mais eficazes usadas para implementar esse padrão são ferramentas ETL tradicionais, como Informatica ou MuleSoft. É importante que as ferramentas de middleware escolhidas ofereçam suporte à API em massa do Salesforce.

O middleware deve ser capaz de armazenar o último carimbo de data e hora processado com sucesso, seja internamente ou externamente, para marcação d’água. Esse último carimbo de data e hora processado com sucesso deve ser usado para consumir as alterações desde a última execução bem-sucedida.

A tabela a seguir destaca as propriedades desejáveis de um sistema de middleware que participa desse padrão.

Exemplo

Uma empresa de serviços públicos usa um processo em lote baseado em mainframe que atribui clientes potenciais a representantes e equipes de vendas individuais. Essas informações precisam ser importadas para o Salesforce diariamente.

O cliente decidiu implementar a captura de dados de alteração nas tabelas de origem usando uma ferramenta ETL comercialmente disponível. A solução funciona da seguinte maneira:

• Um agendador semelhante a cron executa um trabalho em lote que atribui clientes potenciais a usuários e equipes.
• Depois que o trabalho em lote é executado e os dados são atualizados, a ferramenta ETL reconhece essas alterações usando a captura de dados de alteração. A ferramenta ETL compara as alterações do armazenamento de dados.
• O conector ETL usa a API REST do Salesforce para carregar as alterações no Salesforce.

Contexto

Você usa o Salesforce para rastrear leads, gerenciar seu pipeline, criar oportunidades e capturar detalhes do pedido que convertem leads em clientes. O sistema do Salesforce cria os pedidos internamente e então envia esses dados para o sistema de faturamento externo para provisionamento e ativação. Os Pedidos de faturamento são gerenciados por um sistema externo (remote). Esse sistema remoto precisa atualizar o status do pedido no Salesforce quando o pedido ou a entidade de cobrança no status do sistema de cobrança mudar.

Problema

Como um sistema remoto se conecta e autentica com o Salesforce para notificar o Salesforce sobre eventos externos, criar registros e atualizar registros existentes?

Forças

Há várias forças a serem consideradas ao aplicar soluções com base neste padrão:

• O propósito da chamada remota ao Salesforce é notificar o Salesforce de um evento que ocorreu externamente usando uma arquitetura conduzida por evento? Ou o objetivo é realizar operações CRUD em registros específicos? Se você usar uma arquitetura acionada por evento, o produtor de evento (o processo remoto) será desacoplado do consumidor de evento do Salesforce.
• A chamada para o Salesforce exige que o processo remoto aguarde uma resposta antes de continuar o processamento? Chamadas remotas ao Salesforce sempre são solicitação-resposta síncrona, embora o processo remoto possa descartar a resposta se não for necessário para simular uma chamada assíncrona.
• Cada transação opera em um único objeto do Salesforce ou em vários objetos relacionados?
• Qual é o formato da mensagem (por exemplo, SOAP ou REST, ou ambos por HTTP)?
• O tamanho da mensagem é relativamente pequeno ou grande?
• Se o sistema remoto for compatível com SOAP, o sistema remoto poderá participar de uma abordagem de contrato em primeiro lugar, em que o Salesforce determina o contrato? Isso é necessário quando nossa API SOAP é usada, para a qual um WSDL predefinido é fornecido.
• O processamento da transação é obrigatório?
• Até que ponto você é tolerante à personalização no Salesforce?

Solução

Esta tabela contém várias soluções para esse problema de integração.

Esboço

Os diagramas a seguir ilustram a sequência de eventos quando você implementa esse padrão usando a API REST para notificações de eventos externos ou a API SOAP para consultar um objeto do Salesforce. A sequência de eventos é a mesma ao usar a API REST.

Consulta do sistema remoto do Salesforce via API REST

Sistema remoto notifica o Salesforce com eventos por meio da API REST

Resultados

Em uma arquitetura acionada por evento, o sistema remoto chama o Salesforce usando a API SOAP, a API REST ou a API em massa 2.0 para publicar um evento no barramento de evento do Salesforce. Publicar um evento notifica todos os assinantes. Os assinantes de evento podem estar na Salesforce Platform, como Fluxos ou Componentes do Lightning, acionadores do Apex. Os assinantes de evento também podem ser externos à Salesforce Platform, como assinantes da API Pub/Sub.

Ao trabalhar diretamente com objetos do Salesforce, as soluções relacionadas a esse padrão permitem:

• O sistema remoto chama as APIs do Salesforce para consultar o banco de dados e executar operações de objeto único (criar, atualizar, excluir e assim por diante).
• O sistema remoto para chamar os recursos compostos da API REST do Salesforce para realizar uma série de operações de objeto.
• Sistema remoto para chamar APIs (serviços) do Salesforce personalizadas que podem dar suporte a operações transacionais de vários objetos e lógica de processamento pré/pós personalizada.

Mecanismos de chamada

O mecanismo de chamada depende da solução escolhida para implementar esse padrão.

Manuseio e recuperação de erros

Uma estratégia de tratamento e recuperação de erros deve ser considerada como parte da solução geral.

• Tratamento de erros – Todos os métodos de chamada remota, APIs padrão ou personalizadas, exigem que o sistema remoto lide com quaisquer erros subsequentes, como tempos limite e o gerenciamento de novas tentativas. O middleware pode ser usado para fornecer a lógica para tratamento e recuperação de erros.
• Recuperação – crie um mecanismo de nova tentativa personalizado se os requisitos de qualidade do serviço o exigirem. Nesse caso, é importante garantir características de design idempotentes. O evento de plataforma permite que os assinantes usem o ID de reprodução para buscar mensagens dentro de um determinado período após a publicação dessas mensagens.

Considerações sobre design idempotente

Os recursos idempotentes garantem que as invocações repetidas sejam seguras e não terão um efeito negativo. Se idempotency não for implementado, as invocações repetidas da mesma mensagem poderão ter resultados diferentes, possivelmente resultando em problemas de integridade de dados, por exemplo, criação de registros duplicados, processamento duplicado de transações e assim por diante.

O sistema remoto deve gerenciar várias chamadas (duplicadas), no caso de erros ou tempos limite, para evitar inserções duplicadas e atualizações redundantes (especialmente se acionadores downstream e regras de fluxo de trabalho forem disparados). Embora seja possível gerenciar algumas dessas situações no Salesforce (especialmente no caso de serviços SOAP e REST personalizados), recomendamos que o sistema remoto (ou middleware) gerencie o tratamento de erros e o design idempotente.

Considerações de segurança

Diferentes considerações de segurança se aplicam, dependendo da solução de padrão escolhida. Em todos os casos, a plataforma usa os direitos de acesso do usuário conectado (por exemplo, configurações de perfil, regras de compartilhamento, conjuntos de permissões etc.). Além disso, as restrições de IP de perfil podem ser usadas para restringir o acesso à API para um intervalo de endereços IP específico.

Consulte Considerações de segurança.

Barra lateral

Nenhum.

Tempo

A API SOAP e a API de serviço da Web do Apex são síncronas. Os seguintes tempos limite se aplicam:

• Tempo limite da sessão – a sessão expira se não houver nenhuma atividade com base na configuração de tempo limite da sessão da organização do Salesforce.
• Tempo limite de consulta – cada consulta SOQL tem um limite de tempo limite individual de 120 segundos.

Volumes de dados

As considerações sobre o volume de dados dependem da solução e do tipo de comunicação escolhidos.

Capacidade de ponto de extremidade e suporte a padrões

A funcionalidade e o suporte padrão para o ponto de extremidade dependem da solução escolhida.

Gestão do Estado

Ao integrar sistemas, as chaves são importantes para rastreamento de estado contínuo, por exemplo, se um registro for criado no sistema remoto, para dar suporte a atualizações contínuas desse registro. Há duas opções:

• O Salesforce armazena a chave de substituição primária ou exclusiva do sistema remoto para o registro remoto.
• O sistema remoto armazena o ID de registro exclusivo do Salesforce ou alguma outra chave substituto exclusiva. Há considerações específicas para lidar com chaves de integração nesse padrão síncrono.

Cenários de integração complexos

Cada solução nesse padrão tem diferentes considerações ao lidar com cenários de integração complexos, como transformação e orquestração de processo.

Limites do governador

Devido à natureza multilocatário da Salesforce Platform, há limites ao usar as APIs.

Mensagens confiáveis

Mensagens confiáveis tentam resolver o problema de garantir a entrega de uma mensagem a um sistema remoto em que os componentes individuais podem não ser confiáveis. A API SOAP do Salesforce e a API REST são síncronas e não oferecem suporte explícito para nenhum protocolo de mensagens confiável por si só (por exemplo, WS-ReliableMessaging).

Recomendamos que o sistema remoto implemente um sistema de mensagens confiável para garantir que cenários de erro e tempo limite sejam gerenciados com sucesso. A publicação de eventos de plataforma de sistemas externos depende das APIs do Salesforce, portanto, as mesmas considerações se aplicam à API SOAP e à API REST.

Capacidades do Middleware

Esta tabela destaca as propriedades desejáveis de um sistema de middleware que participa deste padrão:

Exemplo

Uma empresa de serviços e suprimentos de impressão usa o Salesforce como um front-end para criar e gerenciar suprimentos e pedidos de impressora. Os registros de ativos do Salesforce que representam impressoras são atualizados periodicamente com estatísticas de uso de impressão (status de tinta, nível de papel) do Sistema de gerenciamento de impressora (PMS) no local, que monitora regularmente as impressoras em sites de clientes. Ao atingir um valor de limite definido (por exemplo, baixo status de tinta ou baixo/nível de papel vazio inferior a 30%), vários aplicativos/processos (variável) interessados no evento são notificados, alertas por email ou Chatter são enviados e um registro de Pedido é criado. O PMS armazena o ID do Salesforce (o Salesforce é o mestre do registro do ativo).

As seguintes restrições se aplicam:

• O PMS pode participar de uma integração de contrato em primeiro lugar, em que o Salesforce fornece o contrato e o PMS atua como um cliente (consumidor) do serviço do Salesforce (definido por meio do WSDL Enterprise ou Partner).
• Não deve haver desenvolvimento personalizado no Salesforce.

Este exemplo é melhor implementado usando a API SOAP do Salesforce ou a API REST para publicar eventos e automação declarativa (Fluxo) no Salesforce. O principal motivo para usar eventos de plataforma é o número variável e não limitado de assinantes; no entanto, para atualizações simples em uma lista finita de registros, como pedidos, use a API SOAP ou REST para atualizar os registros.

No Salesforce:

• Defina um evento de plataforma no Salesforce para conter os dados de notificação provenientes do PMS.
• Crie um fluxo acionado pela notificação de evento de impressora. O processo atualiza o ativo de impressora e cria um pedido (usando um Fluxo iniciado automaticamente).
• Baixe o WSDL Enterprise ou Partner e forneça-o ao sistema remoto.

No sistema remoto:

• Crie um fragmento de código de cliente usando o WSDL Enterprise ou Partner.
• Autenticar no Salesforce (por meio do servidor da Web do OAuth ou do fluxo de token do portador) usando as credenciais do usuário de integração.
• No evento de status da impressora, o PMS chama a API para criar o evento de plataforma de status da impressora (com estatísticas de uso da impressora). O barramento de evento do Salesforce notifica o assinante do Fluxo e todos os outros assinantes.

Quando você usa eventos de plataforma, o barramento de eventos permite que você repita eventos por 72 horas para eventos de plataforma de alto volume. Publicar esses eventos usando uma solução de middleware pode ajudar a incorporar o tratamento de erros no lado da publicação. No entanto, você poderá implementar o tratamento de erros no lado da assinatura se precisar de mais confiabilidade.

Este exemplo demonstra o seguinte:

• Implementação de um cliente de API síncrona do Salesforce (consumidor).
• Um retorno para o Salesforce para publicar um evento de plataforma (alinhado aos padrões de evento de plataforma de resposta/solicitação cobertos anteriormente).

Contexto

Você usa o Salesforce para gerenciar casos do cliente. Um representante de atendimento ao cliente está no telefone com um cliente trabalhando em um caso. O cliente faz um pagamento e o representante de atendimento ao cliente precisa ver uma atualização em tempo real no aplicativo Salesforce do aplicativo de processamento de pagamento, indicando que o cliente pagou com sucesso o valor pendente do pedido.

Problema

Quando ocorre um evento no Salesforce, como o usuário pode ser notificado na interface de usuário do Salesforce sem precisar atualizar a tela e, possivelmente, perder o trabalho?

Forças

Há várias forças a serem consideradas ao aplicar soluções com base neste padrão:

• Os dados que estão sendo executados precisam ser armazenados no Salesforce?
• É possível criar uma camada da interface do usuário personalizada para visualizar esses dados?
• O usuário terá acesso para invocar a interface de usuário personalizada?

Solução

A solução recomendada para esse problema de integração é usar eventos de plataforma que garantem eventos quase em tempo real no Salesforce. Os Eventos de plataforma fornecem uma carga útil estruturada e flexível independente de qualquer objeto do Salesforce. Eles também garantem tópicos duráveis com uma janela de repetição de 72 horas. Essa janela garante que os eventos estejam disponíveis mesmo que um consumidor offline fique disponível mais tarde. Essa solução é composta pelos seguintes componentes:

• Acionador ou fluxos do Apex com uma lógica para publicar um evento de plataforma em um tópico
• Um tópico que permite publicar um evento a partir do Acionador do Apex ou do Fluxo
• API Pub/Sub (com base em gRPC e HTTP/2) para consumo eficiente de eventos de plataforma
• Um componente do Lightning
• Uma biblioteca JavaScript incluída como um recurso estático

Esboço

O diagrama a seguir ilustra como a API Pub/Sub pode ser implementada para transmitir notificações para a interface do usuário do Salesforce. Essas notificações são acionadas por alterações de registro no Salesforce.

Atualização de interface do usuário no Salesforce acionada por uma alteração de dados

Resultados

Benefícios

A aplicação da solução relacionada a esse padrão tem os seguintes benefícios:

• Elimina a necessidade de escrever mecanismos de pesquisa personalizados
• Elimina a necessidade de um loop de feedback iniciado pelo usuário

Requisitos não suportados

A solução tem as seguintes limitações:

• Não há garantia de entrega de notificações.
• A ordem das notificações não é garantida.
• As notificações não são geradas de alterações de registro feitas pela API em massa.

Considerações de segurança

A segurança em nível da organização padrão do Salesforce é respeitada. Recomenda-se usar o protocolo HTTPS para se conectar à API de streaming. Consulte Considerações de segurança

Barra lateral

A solução ideal envolve a criação de uma interface de usuário personalizada no Salesforce. É imperativo que você considere um contêiner de interface de usuário adequado que possa ser usado para renderizar a interface de usuário personalizada. Para obter mais detalhes, consulte Guia do desenvolvedor da API Pub/Sub.

Exemplo

Uma empresa de telecomunicações usa o Salesforce para gerenciar casos de clientes. Os gerentes de atendimento ao cliente querem ser notificados quando um caso é fechado com sucesso por um de seus representantes de atendimento ao cliente.

Ao implementar a solução prescrita por esse padrão, o cliente deve:

• Crie um Acionador do Apex que envie um evento de plataforma quando um caso for salvo com um Status de “Fechado” e Resolução de “Sucedido”.
• Crie uma interface de usuário personalizada disponível para gerentes de atendimento ao cliente. Essa interface do usuário assina a API Pub/Sub para consumir eventos de plataforma.
• Implemente a lógica na interface de usuário personalizada que mostra alertas gerados pelos representantes de atendimento ao cliente do gerente.

Contexto

Você usa o Salesforce para rastrear leads, gerenciar seu pipeline, criar oportunidades e capturar detalhes do pedido que convertem leads em clientes. No entanto, o Salesforce não é o sistema que contém ou processa pedidos. Os pedidos são gerenciados por um sistema externo (remote). Porém, os representantes de vendas querem visualizar e atualizar informações do pedido em tempo real no Salesforce sem precisar aprender nem usar o sistema externo.

Problema

No Salesforce, como você visualiza, pesquisa e modifica dados armazenados fora do Salesforce sem mover os dados do sistema externo para o Salesforce?

Forças

Há várias forças a serem consideradas ao aplicar soluções com base neste padrão:

• Deseja criar uma integração de saída declarativa/apontar e clicar ou mashup de interface do usuário no Salesforce?
• Você tem uma grande quantidade de dados que não deseja copiar para sua organização do Salesforce?
• Você precisa acessar pequenas quantidades de dados do sistema remoto a qualquer momento?
• Você precisa de acesso em tempo real aos dados mais recentes?
• Você armazena seus dados na nuvem ou em um sistema de back-office, mas deseja exibir ou processar esses dados em sua organização do Salesforce?
• Você tem preocupações sobre a residência de dados para armazenar determinados tipos de dados no Salesforce?

Solução

A tabela a seguir contém várias soluções para esse problema de integração.

Esboço

O diagrama a seguir ilustra como você pode usar o Salesforce Connect para extrair dados de um sistema externo usando um adaptador OData.

Neste cenário:

• O navegador realiza uma chamada AJAX que, por sua vez, executa uma ação no adaptador de objeto externo correspondente.
• O adaptador traduz a ação em uma solicitação OData e faz uma solicitação GET HTTP para o sistema remoto por meio das camadas de Integração e Serviços.
• O sistema remoto retorna uma resposta JSON ao Salesforce por meio das camadas de Integração e Serviços.
• A resposta é traduzida do OData para um objeto externo e apresentada de volta ao navegador.

Resultados

A aplicação das soluções relacionadas a esse padrão permite invocações iniciadas pela interface do usuário em que o resultado da transação pode ser exibido ao usuário final.

Mecanismos de chamada

O mecanismo de chamada depende da solução escolhida para implementar esse padrão.

Tratamento de erros

É importante incluir o tratamento de erros como parte da solução geral. Quando ocorre um erro (exceções ou códigos de erro são retornados ao chamador), o chamador gerencia o tratamento do erro. O Salesforce Connect Validator é uma ferramenta gratuita para executar algumas consultas comuns e tipos de erro de aviso e causas de falha.

Benefícios

Alguns dos benefícios de usar uma solução do Salesforce Connect são:

• Essa solução não consome o armazenamento de dados no Salesforce.
• Os usuários não precisam se preocupar com a sincronização regular de dados entre o sistema externo e o Salesforce.
• Uma configuração declarativa que pode ser alcançada rapidamente com OData, ou um adaptador entre organizações, ou usando um código mínimo com um adaptador Apex personalizado.
• Os usuários podem acessar dados externos com a mesma funcionalidade que objetos personalizados na forma de objetos externos.
• Capacidade de fazer uma pesquisa federada no sistema externo conectado usando a pesquisa global.
• Capacidade de executar relatórios que acessam dados externos de fontes na nuvem e no local. Consulte as considerações sobre relatórios abaixo.

Considerações sobre o Salesforce Connect

A solução Salesforce Connect tem as seguintes considerações:

• Objetos externos se comportam como objetos personalizados, mas alguns recursos não estão disponíveis para objetos externos. Para obter mais informações, consulte Considerações sobre a compatibilidade do Salesforce para Salesforce Connect.
• Objetos externos podem afetar o desempenho do relatório. Para obter mais informações, consulte Considerações sobre relatórios para Salesforce Connect.
• Consulte Considerações adicionais sobre o uso de adaptadores do Salesforce Connect em Considerações sobre o Salesforce Connect – Todos os adaptadores.
• Se estiver considerando usar um adaptador entre organizações, consulte Considerações sobre o Salesforce Connect – adaptador entre organizações.
• Se estiver considerando usar um adaptador OData, consulte Considerações sobre o Salesforce Connect – adaptadores OData 2.0 e 4.0.
• Se estiver considerando usar um adaptador do Apex personalizado, consulte Considerações sobre o Salesforce Connect – adaptador personalizado.

Considerações de segurança

As soluções para esse padrão devem cumprir a segurança em nível da organização padrão do Salesforce. Recomenda-se usar o protocolo HTTPS para se conectar a qualquer sistema remoto. Para obter mais detalhes, consulte Considerações de segurança

Se você estiver usando um conector OData, entenda os comportamentos especiais, limitações e recomendações para a Falsificação de solicitação entre sites (CSRF) em fontes de dados externas OData. Para obter mais informações, consulte Considerações sobre CSRF para Salesforce Connect — Adaptadores OData 2.0 e 4.0.

Barra lateral

Nenhum.

Tempo

A pontualidade é de importância significativa nesse padrão. Lembre-se dos seguintes pontos:

• A solicitação geralmente é invocada na interface do usuário, portanto, o processo não deve manter o usuário esperando.
• Dependendo da disponibilidade e da conexão com o sistema externo, pode levar muito tempo para recuperar dados externos. O Salesforce tem um valor de tempo limite máximo de 120 segundos configurável para aguardar uma resposta do sistema externo.
• A conclusão do processo remoto deve ser executada em tempo hábil e concluída dentro do limite de tempo limite do Salesforce e dentro das expectativas do usuário.

Volumes de dados

Esse padrão é usado principalmente para atividades em tempo real de pequeno volume, devido aos pequenos valores de tempo limite e tamanho máximo da solicitação ou resposta para a solução de chamada do Apex. Não use esse padrão em atividades de processamento em lote em que a carga de dados está contida na mensagem.

Capacidade de ponto de extremidade e suporte a padrões

A funcionalidade e o suporte padrão para o ponto de extremidade dependem da solução escolhida.

Gestão do Estado

Ao integrar sistemas, as chaves são importantes para o rastreamento de estado contínuo. Por exemplo, se um registro for criado no sistema remoto, geralmente o registro precisará de algum tipo de chave de identificação para dar suporte a atualizações em andamento. Há duas opções para armazenar chaves.

• O Salesforce armazena a chave substituto primária ou exclusiva para o registro remoto.
• O sistema remoto armazena o ID de registro exclusivo do Salesforce ou alguma outra chave substituto exclusiva. Há considerações específicas para lidar com chaves de integração nesse padrão síncrono.

Integrações complexas

Em determinados casos, a solução prescrita por esse padrão pode exigir a implementação de um cenário de integração complexo. Esses cenários costumam ser resolvidos usando middleware.

• Agregação de chamadas e seus resultados entre chamadas para vários sistemas
• Transformação de mensagens de entrada e de saída
• Manter a integridade transacional em chamadas para vários sistemas
• Outras atividades de orquestração de processo entre o Salesforce e o sistema externo

Limites regulatórios

Diferentes limites se aplicam a diferentes adaptadores. Para obter mais detalhes, consulte Limites gerais do Salesforce Connect.

Capacidades do Middleware

A tabela a seguir destaca as propriedades desejáveis de um sistema de middleware que participa desse padrão.

Relacionamentos de objetos externos

Os objetos externos oferecem suporte a relacionamentos de pesquisa padrão, que usam o ID de registro do Salesforce de 18 caracteres para associar registros relacionados. No entanto, os dados armazenados fora da sua organização do Salesforce geralmente não contêm esses IDs de registro. Portanto, há dois tipos especiais de relacionamentos de pesquisa disponíveis para objetos externos: pesquisas externas e pesquisas indiretas.

Esta tabela resume os tipos de relacionamentos que estão disponíveis para objetos externos.

Considerações sobre alto volume de dados para Salesforce Connect: Adaptadores Odata 2.0 e 4.0

Se sua organização atingir os limites de taxa ao acessar objetos externos, considere selecionar a opção Alto volume de dados nas origens de dados externas associadas. Fazer isso ignora a maioria dos limites de taxa, mas alguns comportamentos e limitações especiais se aplicam. Para obter mais informações, consulte Considerações sobre alto volume de dados para o Salesforce Connect.

Paginação acionada por cliente e por servidor para Salesforce Connect: Adaptadores Odata 2.0 e 4.0

É comum que as consultas do Salesforce Connect de dados externos tenham um grande conjunto de resultados dividido em lotes ou páginas menores. Você decide se o comportamento de paginação será controlado pelo sistema externo (acionado pelo servidor) ou pelo adaptador OData 2.0 ou 4.0 para Salesforce Connect (acionado pelo cliente). O campo Paginação acionada pelo servidor na origem de dados externa especifica se deseja usar a paginação acionada pelo cliente ou pelo servidor. Se você habilitar a paginação acionada pelo servidor em uma origem de dados externa, o Salesforce ignorará os tamanhos de página solicitados, incluindo o tamanho de lote queryMore() padrão de 500 linhas. As páginas retornadas pelo sistema externo determinam os lotes, mas cada página não pode exceder 2.000 linhas. No entanto, os limites dos adaptadores OData para Salesforce Connect ainda se aplicam.

Exemplo

Uma empresa de manufatura usa o Salesforce para gerenciar casos do cliente. Os agentes de atendimento ao cliente querem acessar as informações do pedido em tempo real do sistema ERP no back-office para obter uma visão completa do cliente sem precisar aprender e executar manualmente relatórios no ERP.

Para implementar a solução prescrita por esse padrão, você deve:

• Configure sua origem de dados externa com um ponto de extremidade OData. Seu aplicativo remoto pode incluir suporte nativo para OData. Para outras aplicações, os principais fornecedores de integração, como Dell Boomi, Informatica, Jitterbit, MuleSoft e Progress Software, colaboraram com a Salesforce no Salesforce Connect para criar adaptadores.
• Aponte o Salesforce Connect no ponto de extremidade OData diretamente ou por meio de uma solução de middleware.
• Sincronize suas tabelas de banco de dados externos com objetos externos no Salesforce. Quando um usuário acessa uma página com dados desses objetos externos, o Salesforce Connect faz chamadas em tempo real para seus aplicativos de back-end.

Documentação do desenvolvedor

• Ajuda do Salesforce: Conceder aos usuários de integração acesso apenas à API
• Visão geral da API Pub/Sub
• Guia do desenvolvedor da API SOAP
• Guia do desenvolvedor da API REST
• Guia do desenvolvedor da API de streaming
• Guia do desenvolvedor da API em massa 2.0 e da API em massa
• Guia do desenvolvedor do Apex
• Referência de SOQL e SOSL
• Limites e alocações de desenvolvedores do Salesforce Referência rápida
• Guia do desenvolvedor de eventos de plataforma
• Salesforce Connect (Ajuda e treinamento)
• Guia do desenvolvedor do Apex: Salesforce Connect
• Entendendo o Salesforce Connect
• Duração da mensagem de eventos da plataforma
• Guia do desenvolvedor de credenciais nomeadas
• Guia do desenvolvedor do Apex: Usando credenciais nomeadas
• Credências nomeadas (ajuda e treinamento)
• Entenda as credenciais nomeadas
• Conexão privada (ajuda e treinamento)
• Entendendo a conexão privada

Trailhead

• Grande volume de dados
• Bases de eventos da plataforma
• Princípios básicos da captura de dados de alteração
• Início rápido: Salesforce Connect

O Salesforce está se movendo para arquiteturas mais rápidas e orientadas por evento. Agora é necessário migrar para longe das ferramentas de integração legadas para manter a segurança e a escalabilidade. Muitas ferramentas mais antigas usam protocolos desatualizados, como SOAP ou pesquisa longa (CometD), que não podem acompanhar a entrega eficiente baseada em gRPC da API Pub/Sub ou o poder de automação do Flow Builder. Para se preparar, comece auditando suas integrações existentes para encontrar dependências embutidas em código. Isso é especialmente importante, pois o Salesforce começa a descontinuar recursos como Salesforce-to-Salesforce (descontinuado totalmente na versão Spring ‘27) e a descontinuar os métodos de autenticação legados. Ao planejar sua migração, use uma abordagem “Fluxo em primeiro lugar” para lógica de negócios interna e uma abordagem “Pub/Sub-first” para fluxos de dados externos. Isso lhe dará uma arquitetura flexível e desacoplada pronta para atender às demandas de dados da plataforma habilitada por IA de hoje.

A chamada de login() na API SOAP do Salesforce está sendo descontinuada. Ele já está indisponível na API v65.0 e superiores. Novas organizações do Salesforce terão o login() desabilitado por padrão e as organizações existentes precisarão da nova permissão “Usar qualquer autenticação de API” para continuar a usá-lo. O prazo fixo é a versão Summer ‘27, quando a Salesforce descontinuará totalmente o login() em todas as versões da API (31.0 a 64.0).

Para ser membros efetivos do portfólio corporativo, todos os aplicativos devem ser criados e integrados a mecanismos de segurança relevantes. Estratégias de TI modernas usam uma combinação de serviços locais e baseados em nuvem.

Embora a integração de serviços de nuvem para nuvem geralmente se concentre em serviços da Web e autorização associada, a conexão de serviços locais e de nuvem geralmente introduz maior complexidade. Esta seção descreve ferramentas de segurança, técnicas e considerações específicas do Salesforce.

Servidor proxy reverso

Um proxy reverso é um servidor que fica em frente a servidores da Web e encaminha solicitações de clientes (por exemplo, navegador da Web) a esses servidores da Web. Os proxies reversos geralmente são implementados para ajudar a aumentar a segurança, o desempenho e a confiabilidade.

É um tipo de servidor proxy que recupera recursos em nome de um cliente de um ou mais servidores. Esses recursos então são devolvidos ao cliente como se tivessem se originado do próprio servidor proxy. Diferentemente de um proxy encaminhado, que é um intermediário para seus clientes associados entrarem em contato com qualquer servidor, um proxy reverso é um intermediário para seus servidores associados serem contatados por qualquer cliente.

Em implementações do Salesforce, esse serviço costuma ser fornecido por meio de um produto de gateway externo. Por exemplo, opções de código aberto, como Apache HTTP, lightttpd e nginx, podem ser usadas. Produtos comerciais incluem IBM WebSeal e Computer Associates SiteMinder. Esses produtos podem ser facilmente configurados para proxy e gerenciar todas as solicitações do Salesforce de saída em nome do solicitante interno.

Criptografia

Algumas empresas exigem que as transações ou campos de dados selecionados sejam criptografados entre uma combinação de aplicativos locais e baseados em nuvem. Se sua organização precisar cumprir requisitos de conformidade adicionais, você poderá implementar alternativas, incluindo:

• Serviços de gateway de criptografia comercial local, incluindo os próprios do Salesforce, o CipherCloud, o IBM DataPower e os Associados de computador. Para cada solução, o mecanismo ou o gateway de criptografia são invocados no limite da transação ao enviar e receber uma carga útil criptografada ou ao criptografar ou descriptografar campos de dados específicos antes da execução da solicitação HTTP(S).
• Opções baseadas em nuvem, como o Salesforce Shield Platform Encryption. A Shield Platform Encryption dá aos seus dados uma nova camada de segurança, preservando a funcionalidade crítica da plataforma. Os dados selecionados são criptografados em repouso usando um sistema avançado de derivação de chave. Você pode proteger seus dados com mais segurança do que nunca. Consulte a ajuda do Salesforce online para obter mais informações.

Suporte especializado de protocolo WS-*

Para lidar com os requisitos de protocolos de segurança (como WS-*), recomendamos estas alternativas.

• Gateway de segurança/XML – Injecte credenciais WS-Security (MuleSoft, IBM WebSeal ou Datapower, Layer7, TIBCO e assim por diante) no próprio fluxo de transação. Essa abordagem não requer alterações a serviços da Web no nível do aplicativo ou chamadas de serviço da Web do Salesforce. Você também pode reutilizar essa abordagem em toda a instalação do Salesforce. No entanto, ele requer design, configuração, teste e manutenção adicionais para gerenciar a injeção adequada de WS-Security na abordagem de gateway de segurança existente.
• Criptografia em nível de transporte – criptografe o canal de comunicação usando restrições de SSL e IP bidirecionais. Embora essa abordagem não implemente diretamente o protocolo WS-* sozinha, ela protege o canal de comunicação entre os aplicativos locais e o Salesforce sem passar um nome de usuário e senha. Também não requer alterações a classes geradas pelo Salesforce. No entanto, algumas modificações de serviços da Web locais podem ser necessárias (no próprio aplicativo ou na camada de middleware/ESB).
• Desenvolvimento personalizado do Salesforce – Adicione cabeçalhos do WS-Security à solicitação SOAP de saída por meio do utilitário WSDL2Apex. Isso gera uma classe do Apex semelhante a Java do arquivo WSDL usado para invocar o serviço interno. Embora essa abordagem não exija alterações a serviços da Web de back-end ou componentes adicionais no DMZ, ela exige:
  • um maior esforço de criação e teste
  • um processo relativamente complexo e manual para codificar manualmente os atributos WS-Security (incluindo serialização XML dentro do Apex code)
  • um esforço de manutenção de longo prazo maior

Nota: A última opção não é recomendada devido à sua complexidade e ao risco de que essas integrações precisem de revisões periódicas com base em atualizações regulares no Salesforce.

Outras considerações de segurança

• Credenciais nomeadas: A Salesforce remodelou sua arquitetura de autenticação introduzindo um modelo de credenciais nomeadas de dois níveis que separa claramente as preocupações entre conectividade e identidade. Use isso sempre que fizer chamadas por meio do Apex e evite criar seu próprio protocolo de autenticação. Isso também garante extensibilidade e mais segurança. As credenciais externas estão na base desse modelo. Eles armazenam os detalhes de autenticação reais e dão suporte a um conjunto avançado de protocolos, incluindo Credenciais do cliente do OAuth 2.0, Portador JWT e AWS Signature V4, ao mesmo tempo que também definem como as entidades de segurança são mapeadas: como uma única Entidade de segurança nomeada (compartilhada entre todos os usuários) ou Entidade de segurança Por usuário (em que cada usuário autentica com sua própria identidade). As Credenciais nomeadas, por sua vez, atuam como a camada do ponto de extremidade: elas definem o URL de chamada e fazem referência a uma Credencial externa para lidar com o apelido de autenticação, mantendo a configuração do ponto de extremidade desconectada do gerenciamento de credenciais. Para habilitar fluxos de autenticação por usuário, os administradores mapeiam Conjuntos de permissões para a entidade de segurança Credencial externa adequada, garantindo que apenas usuários com a atribuição de Conjunto de permissões certa possam chamar chamadas sob sua própria identidade. Esse design de duas camadas não apenas simplifica a configuração de chamada segura, mas também dá aos arquitetos muito mais flexibilidade e controle de governança sobre como as integrações são autenticadas entre sistemas conectados ao Salesforce. Para obter mais detalhes, consulte a documentação Credenciais nomeadas.
• OAuth 2.0: O OAuth 2.0 é uma estrutura de autorização padrão do setor que permite que um usuário conceda acesso limitado a seus recursos protegidos a um aplicativo de terceiros sem compartilhar suas credenciais (como senhas). Em vez de uma troca de senha direta, o usuário aprova uma solicitação de token de acesso, que o aplicativo então usa para acessar os dados do usuário de um servidor de recurso. Esse processo separa o aplicativo cliente da identidade e senha do usuário, aprimorando a segurança fornecendo uma “chave” temporária específica do escopo para acessar recursos. Para obter mais informações, consulte a documentação OAuth 2.0. Para pontos de extremidade com conformidade estrita com OAuth 2.1, um terceiro nível da arquitetura está disponível (Provedor de identidade de autenticação externo) para gerenciar a interação com o IDP de maneira compatível com a versão 2.1.
• Conexão privada: Quando você integra sua organização do Salesforce a aplicativos hospedados em serviços de nuvem de terceiros, é essencial poder enviar e receber o tráfego HTTP/s com segurança. Com a Conexão privada, aumente a segurança em suas integrações da Amazon Web Services (AWS) configurando uma conexão de rede totalmente gerenciada entre sua organização do Salesforce e sua AWS Virtual Private Cloud (VPC). Em seguida, encaminhe seu tráfego entre nuvens pela conexão, em vez de pela Internet pública, para reduzir a exposição a ameaças à segurança de terceiros. A Conexão privada está disponível em parceria com a AWS por meio de um recurso chamado AWS PrivateLink. A conexão privada é bidirecional: você pode iniciar o tráfego de entrada e saída. Com conexões de entrada, você pode enviar tráfego para o Salesforce usando as APIs padrão. Com as conexões de saída, você pode enviar o tráfego do Salesforce por meio de recursos como chamadas do Apex, serviços externos e objetos externos. Para obter mais informações, consulte a documentação do Private Connect.

O Salesforce Event Bus com Eventos de plataforma, Captura de dados de alteração (CDC) e API Pub/Sub permite que as empresas criem arquiteturas de estilo conduzidas por evento (EDAs).

Um EDA desconecta os consumidores de mensagens de evento (assinantes) dos produtores de mensagens de evento (publicadores), permitindo maior escala e flexibilidade. Os padrões específicos são abordados neste documento como parte da estrutura de padrões existente que compara e contrasta alternativas ou opções relacionadas. No entanto, obter uma compreensão holística da arquitetura conduzida por evento e como os padrões interagem pode ajudá-lo a selecionar o padrão certo para suas necessidades.

Khalid Mohammed é um destacado líder de arquitetos nos Serviços profissionais da Salesforce. Desde que entrou para a Salesforce em 2015, ele aproveitou seu amplo conhecimento em Arquitetura e Aplicativo Enterprise, aprimorado por várias transformações do cliente antes de seu mandato na Salesforce. Khalid lidera o Conselho de arquitetura de entrega e também é reconhecido como um líder de arquiteto técnico certificado.

Gulal Kumar é um arquiteto de engenharia de software na Salesforce, com foco em arquitetura de integração e dados. Com mais de 21 anos de experiência em integração e APIs, programas de modernização, segurança e iniciativas AIML, ele traz uma abundância de conhecimento. O Gulal está empenhado em promover iniciativas de transformação de negócios, aprimorar a segurança e a resiliência, promover a excelência de arquitetura e liderar iniciativas de AIML em vários domínios.

Sushant Verma é um arquiteto técnico na Salesforce, especializado em arquitetura de soluções e entrega completa de plataformas do Salesforce. Com profundo conhecimento em governança de plataforma, desenvolvimento de aplicativos, integração e DevOps, ele liderou vários programas de transformação do cliente em vários setores. A Sushant está comprometida em promover a excelência de entrega e resultados arquitetônicos escalonáveis.