O processamento assíncrono aumenta a escalabilidade permitindo limites mais altos por contexto. As solicitações assíncronas são executadas em seus próprios threads nos bastidores, de modo que os usuários podem continuar trabalhando no lado do cliente enquanto as tarefas assíncronas são executadas em segundo plano.

A Salesforce Lightning Platform oferece uma variedade de tecnologias assíncronas que podem ser usadas para resolver um determinado caso de uso. Cada tecnologia tem benefícios e limites que você precisará considerar ao selecionar uma abordagem para cada caso de uso.

Ao escolher uma tecnologia para implementação, três considerações importantes a serem consideradas são:

1. O processamento assíncrono não é a melhor abordagem para todos os problemas. Pode ser tentador pensar em qualquer processo que não exija diretamente interação com o usuário como um bom candidato para processamento assíncrono, mas há algumas desvantagens. Primeiro, os processos assíncronos não têm SLA, o que significa que não há garantia de que um processo assíncrono seja concluído dentro de um período definido. Em segundo lugar, não há garantia de latência de resposta consistente. Se um processo assíncrono for concluído dentro de um determinado período, um processo subsequente poderá levar um tempo diferente para ser concluído. Portanto, mesmo que um usuário não esteja aguardando diretamente uma resposta, o processamento assíncrono pode não ser adequado para seu cenário se você tiver processos subsequentes que dependem de uma resposta ou se estiver preocupado que tempos de resposta excessivos possam fazer com que seus dados fiquem fora de sincronia com os dados em um sistema externo.
2. Há diferentes maneiras de processar solicitações assíncronas no Salesforce Platform, portanto, escolha a melhor abordagem. As tecnologias que oferecem suporte ao processamento assíncrono na Salesforce Platform funcionam de maneira diferente "sob o controle", e algumas foram projetadas para casos de uso muito específicos.
3. Se uma tecnologia for assíncrona no lado do cliente, isso não significa necessariamente que todo o processamento de ponta a ponta seja realizado em paralelo. Dependendo das escolhas que você faz, às vezes as mensagens do cliente ainda podem ser serializadas no lado do servidor.

Se você usar as tecnologias erradas ou as combinações erradas de tecnologias para um trabalho, poderão ocorrer consequências indesejadas que cancelem os benefícios do processamento assíncrono. Este guia fornece explicações e recomendações, bem como possíveis inconvenientes e antipadrões para vários casos de uso assíncronos, junto com a fundamentação para essas recomendações. Ele também fornece percepções sobre como várias técnicas de implementação assíncronas operam e são reguladas na Salesforce Platform.

Se você estiver tomando uma decisão sobre qual tecnologia usar, existe um focado Guia de decisão de processamento assíncrono que fornece um mapeamento rápido de casos de uso típicos para a tecnologia mais adequada.

A Salesforce Lightning Platform é uma plataforma abrangente baseada em IA que une funcionários, agentes de IA autônomos, dados da empresa e aplicativos em um único sistema confiável para aumentar a produtividade e a experiência do cliente. Ele permite a criação de uma "empresa ativa" conectando os aplicativos Customer 360, o Data Cloud e o Slack para automação completa.

Este documento não abrange tecnologias em outros ecossistemas, como MuleSoft, Informatica, Commerce Cloud, Tableau e Marketing Cloud.

Observe que este guia se concentra exclusivamente no processamento assíncrono dentro da Salesforce Lightning Platform. Se estiver procurando informações sobre padrões de integração assíncronos, confira Arquitetura orientada por evento.

• Antes de usar o processamento assíncrono, certifique-se de que seus casos de uso se encaixam no padrão. Os padrões assíncronos não têm SLA, estão sujeitos a vários mecanismos de controlador, podem ter limites de capacidade definidos com base no licenciamento e podem causar atrasos de processamento devido à natureza finita dos recursos alocados à infraestrutura assíncrona na Salesforce Platform. Considere seriamente essas limitações ao usar processamento assíncrono em cenários em que um usuário precisa de uma resposta do sistema antes de continuar o trabalho.
• O processamento assíncrono com o Salesforce não é uma solução para necessidades de escala ilimitadas. A Salesforce Platform não é dimensionada de modo infinito, e padrões assíncronos ainda estão sujeitos a limitações. O processamento assíncrono usa threads, que contêm as informações contextuais de que uma CPU precisa para executar um fluxo de instruções. Os threads podem ser executados em paralelo. O número de threads disponíveis em qualquer CPU é limitado, portanto, a plataforma tem mecanismos em vigor para garantir que seus threads disponíveis sejam usados da maneira mais eficiente possível. O mecanismo de controle de fluxo da plataforma impede que as organizações consumam fitas demais e afetem negativamente outras organizações. O algoritmo de uso justo da plataforma controla o número de threads que uma organização tem disponíveis para cada tipo de mensagem em particular.
• Saiba quando as transações são verdadeiramente assíncronas. Alguns padrões de arquitetura se comportam de maneira assíncrona de ponta a ponta. No entanto, outros processos se comportam de maneira assíncrona no lado do cliente ou do navegador, mas serializam solicitações no lado do servidor, que então estão sujeitas a limites síncronos do controlador.
• Para criar integrações de saída em grande escala da Salesforce Platform, use eventos de plataforma e middleware robusto em vez de chamadas via Apex assíncrono. Como há um número finito de threads assíncronos disponíveis na plataforma, as integrações de saída via Apex assíncrono têm escalabilidade limitada. Se a sua organização tiver integrações de saída que envolvem grandes volumes de mensagens, exceder o número de threads disponíveis e ter longos tempos de processamento, então o uso de Apex assíncrono inevitavelmente introduzirá atrasos.
• Não se esqueça de incorporar monitoramento ao usar processamento assíncrono. Com o monitoramento, você pode detectar problemas o mais cedo possível e corrigi-los antes de ocorrerem incidentes de desempenho importantes.
• Tome em conta os eventos que podem causar cargas extremas. Ao projetar processos assíncronos, certifique-se de que eles possam gerenciar de modo previsível picos e lacunas da carga de trabalho. Considere como sua implementação lida com eventos inesperados, como falhas de energia, e projete proteções que mitiguem a perda de dados ou a perda de funcionalidade.

Ao selecionar uma abordagem para processamento assíncrono no lado do servidor, primeiro avalie os requisitos e os recursos disponíveis da sua organização. Sua meta é selecionar uma abordagem que minimize os custos de implementação e manutenção enquanto ainda garante a escalabilidade e minimiza a probabilidade de violações de limite. Essa meta depende das considerações técnicas descritas nas próximas seções, bem como da composição da sua equipe. Por exemplo, considere se você tem desenvolvedores do Apex em sua equipe que podem manter sua solução de código profissional. Caso contrário, uma abordagem declarativa pode fazer mais sentido. Lembre-se também de que diferentes conjuntos de limites podem se aplicar a diferentes ferramentas.

Considere o caso de uso de um processo de pedido assíncrono no Salesforce. Quando um pedido é salvo, ele aciona uma mensagem para um sistema de gerenciamento de armazém externo com instruções especiais sobre como empacotar e enviar um item. O usuário que faz o pedido não precisa de uma resposta imediata do sistema de gerenciamento de armazém, portanto, a solicitação pode ser enviada de modo assíncrono. O processamento assíncrono permite que o usuário continue seu trabalho sem atrasos.

Considerações para sua arquitetura:

• Quantos processos simultâneos são necessários?
• Como os processos simultâneos interagem entre si?
• Quantas consultas SOQL serão executadas em cada processo?
• Quantas operações DML serão executadas em cada processo?
• Quanto tempo cada processo será executado?
• Quão sensíveis os processos são para um momento específico?

A arquitetura de locatário da Salesforce Platform isola e suporta simultaneamente os requisitos variados de muitos locatários (organizações). Todos os métodos assíncronos do Apex abordados neste guia são executados na mesma infraestrutura assíncrona na Salesforce Platform. Eles usam uma estrutura de enfileiramento de mensagens governada por dois mecanismos de imposição principais: controle de fluxo e uso justo.

O controle de fluxo e os mecanismos de uso justo impedem que um único locatário use recursos de servidor em excesso e não deixe recursos suficientes para os locatários restantes. Embora seja útil entender como esses mecanismos funcionam, sua principal vantagem deve ser que seguir as práticas recomendadas de processamento assíncronas, como as descritas nas próximas seções, reduz significativamente sua probabilidade de encontrar problemas com eles.

O mecanismo de controle de fluxo da plataforma impede que uma organização inunda um determinado tipo de mensagem, o que consome muitos threads e afeta negativamente outras organizações. Antes de a estrutura adicionar novas entradas à fila associada a um tipo de mensagem, ela verifica as primeiras várias mil entradas existentes na fila. Se a maioria das entradas existentes estiver associada à mesma organização e essa organização já tiver entradas em conversas de trabalhadores, as entradas recém-adicionadas serão movidas para a parte traseira da fila. Esse processo é chamado de reenfileiramento. Reenfileiramento geralmente ocorre em processos do Apex em lote e da API em massa porque eles muitas vezes inserem um grande número de entradas em suas filas ao mesmo tempo.

O mecanismo de uso justo da plataforma implementa um sistema baseado em nível. O sistema garante que cada organização na Salesforce Platform receba uma parte adequada do tempo de processamento para um determinado tipo de mensagem, incluindo tipos de mensagem Futuros, Enfileiráveis e Em lote. Se uma organização dominar um determinado tipo de mensagem durante o mesmo tempo em que outras organizações estão esperando para realizar o trabalho no mesmo tipo de mensagem, o algoritmo de uso justo reduzirá o número de threads que a organização tem disponíveis para esse tipo de mensagem específico.

Um benefício do uso de métodos assíncronos do Apex é que alguns limites de regulador, como limites de consulta SOQL e limites de tamanho de heap, são maiores. No entanto, não conte demais com esses métodos. Devido aos recursos finitos alocados a infraestruturas assíncronas, o uso pesado do Future, do Queueable e do Apex em lote pode causar atrasos de processamento decorrentes de limitações baseadas em uso justo e controle de fluxo.

Chamadas de saída que usam o Apex assíncrono contam para o limite do Apex assíncrono. O limite diário no momento é de 250 mil ou 200 vezes o número de licenças de usuário aplicáveis, o que for maior. Esse limite pode ser um problema para casos de uso de alto volume. Se você exceder o limite, seus trabalhos assíncronos do Apex e suas chamadas de saída associadas falharão.

Além disso, como a plataforma tem um número finito de threads assíncronos disponíveis, as integrações de saída via Apex assíncrono têm escalabilidade limitada. Qualquer integração de saída de alto volume que exceda o número de threads disponíveis pode ter longos tempos de processamento e levar a atrasos.

Para casos de uso de alto volume, considere estas abordagens alternativas. Chamadas de API com essas abordagens contam para o limite diário de solicitações de API, que é significativamente maior que o limite diário assíncrono do Apex. Assim, essas abordagens são mais escalonáveis. Observe, porém, que ainda há limitações físicas sobre o número de solicitações simultâneas que qualquer CPU pode processar.

• Middleware Agendado Pull. Evite atrasos associados a trabalhos de integração de saída de alto volume usando middleware para extrair os dados de forma agendada, em vez de enviá-los por push por meio do Apex assíncrono. Os softwares intermediários, como a MuleSoft Anypoint Platform, podem usar a API SOAP nativa ou a API REST de maneira síncrona para que poucos, se houver, atrasos sejam introduzidos. O Middleware também pode usar a API em massa nativa para grandes volumes de dados.

Puxamento

• Middleware Pull via notificação de evento de plataforma. Em vez de colocar em fila o Apex assíncrono Futuro, Enfileirável ou em lote para realizar integrações de saída, você pode usar eventos de plataforma. O evento de plataforma pode entregar as informações de saída em si ou instruir uma ferramenta de middleware a extrair as informações necessárias por meio de uma API nativa e entregá-las ao seu destino final. Nenhuma dessas abordagens está sujeita aos atrasos aos quais o Apex assíncrono está sujeito. No entanto, os limites de evento de plataforma ainda se aplicam.

Com o Apex enfileirável, você pode executar processos do Apex que envolvem operações extensivas de banco de dados ou chamadas de serviços da Web externos de forma assíncrona. Para usar o Apex enfileirável, implemente a interface enfileirável e adicione um trabalho à fila de trabalhos do Apex. Essa abordagem garante que o trabalho do Apex assíncrono seja executado em segundo plano em seu próprio thread isolado e não atrase a execução da lógica principal do Apex. Cada trabalho em fila é executado quando os recursos do sistema ficam disponíveis.

O Apex enfileirável representa a evolução do Apex assíncrono. Ele oferece recursos que não estão disponíveis para métodos futuros do Apex, incluindo:

• IDs de trabalho: Quando você envia um trabalho invocando o método System.enqueueJob, o método retorna o ID do novo trabalho. Você pode usar esse ID para identificar seu trabalho. Para monitorar seu progresso, visualize a página Trabalhos do Apex na Configuração do Salesforce ou consulte o objeto AsyncApexJob.
• Suporte para tipos não primitivos: As classes enfileiráveis podem conter variáveis de membro de tipos de dados não primitivos, como sObjects ou tipos personalizados do Apex.
• Suporte para cadeia de trabalhos: Você pode encadear trabalhos enfileiráveis iniciando um segundo trabalho de um trabalho em execução. Essa técnica pode ajudá-lo a lidar com cenários envolvendo dependências de processo.
• Controle de profundidade máxima: Você pode configurar trabalhos enfileiráveis com uma profundidade máxima de pilha para garantir que as cadeias de trabalhos não terminem com recursão inesperada.
• Assinaturas de desduplicação: Os trabalhos enfileiráveis fornecem uma assinatura opcional para detectar e remover trabalhos duplicados.
• Atraso configurável: Você pode definir um atraso de até 10 minutos antes da execução do trabalho enfileirável.
• Finalizadores da transação: Você pode anexar uma sequência pós-ação a um trabalho enfileirável e realizar ações relevantes com base em seu resultado. Por exemplo, um finalizador de transação pode enfileirar novamente um trabalho enfileirável que falhou devido a uma exceção não tratada até cinco vezes.

O Salesforce usa uma estrutura baseada em fila para lidar com processos assíncronos. Essa fila é usada para balancear as cargas de trabalho de solicitação entre organizações. Para garantir que sua organização use essa fila da maneira mais eficiente possível:

• Evite enfileirar métodos futuros ou enfileiráveis diretamente de ações geradas por grandes volumes de atividades do usuário final ou chamadas à API de integração. Essa abordagem pode rapidamente esgotar os limites diários assíncronos do Apex, resultando em sérios impactos de negócios.
• Evite enfileirar mais de uma ação assíncrona por ação síncrona. Quando vários métodos assíncronos são enfileirados de uma única ação síncrona, as atividades assíncronas geralmente são executadas ao mesmo tempo e contribuem para a contenção de bloqueio de linha e/ou erros de tempo limite de bloqueio de linha.
• Evite adicionar grandes números de métodos futuros ou enfileiráveis à fila assíncrona.
• Garanta que os métodos futuros e enfileiráveis sejam executados o mais rápido possível. Quanto mais tempo um método futuro levar para ser executado, maior será a probabilidade de que as solicitações por trás dele na fila sejam atrasadas. Para garantir a execução rápida de trabalhos em lote, minimize os tempos de chamada de serviço da Web, ajuste as consultas usadas em seus métodos futuros e otimize qualquer outra automação de objeto, incluindo processos do Criador de processos, regras de fluxo de trabalho, fluxos e acionadores do Apex.
• Teste seus métodos assíncronos em escala. Use um ambiente que gere o número máximo de métodos que você espera lidar. Esse teste ajuda a determinar se você encontrará problemas com desempenho ou limites em seu ambiente de produção. Considere também o impacto sobre os limites diários cumulativos.
• Use o Apex em lote em vez de métodos futuros ou enfileiráveis para processar grandes números de registros. O Apex em lote pode lidar com processos complexos e de longa duração que são executados em milhares de registros e pode ser agendado para execução em horários de folga quando mais recursos estiverem disponíveis.

Use o Apex agendado para executar em um horário especificado e com uma frequência repetida definida por uma expressão cron. Embora o ato de agendar o Apex por meio da expressão cron seja um processo assíncrono, o código subjacente é executado de forma síncrona quando o trabalho é iniciado. O Apex agendado é ideal para tarefas de manutenção diárias ou semanais.

• Você só pode ter 100 trabalhos do Apex agendados por vez. Para evitar essa limitação, considere usar um fluxo acionado por agenda que invoque o Apex code em vez de usar o Apex agendado.
• Tenha cuidado extremo se estiver planejando agendar uma aula a partir de um acionador. Você deve garantir que o acionador não adicione mais classes agendadas do que o limite. Em particular, considere atualizações de API em massa, assistentes de importação, alterações de registro em massa por meio da interface do usuário e todos os casos em que mais de um registro pode ser atualizado por vez.
• Para tarefas únicas que precisam ser agendadas até 10 minutos no futuro, use um trabalho enfileirável atrasado. Essa abordagem não conta para o limite de 100 trabalhos agendados.
• O Apex agendado é executado em um contexto síncrono com limites síncronos.
• Considere por quanto tempo o trabalho agendado será executado. Um trabalho de execução longa pode se sobrepor ao início do próximo trabalho agendado.
• O Salesforce agenda a classe para execução no horário especificado. A execução real pode ser adiada com base na disponibilidade do serviço. Os trabalhos agendados para execução durante o tempo de inatividade de manutenção de serviço serão agendados para execução após o retorno do serviço.
• Use System.scheduleBatch para agendar trabalhos em lote em vez de ter um trabalho agendado com o único propósito de enfileirar um trabalho em lote.

Historicamente, chamadas síncronas feitas a partir de um método do Apex em execução em um contexto de transação síncrona do Apex, como um controlador do Visualforce ou um controlador de componente do Lightning, estavam sujeitas ao limite de simultaneidade do Apex para solicitações de execução longa. A partir da versão Winter '19, as chamadas síncronas não são mais contadas como de execução longa. Embora as continuações do Apex tenham sido criadas inicialmente como uma solução para chamadas síncronas que resultaram em solicitações de execução longa, elas também fornecem alguns benefícios adicionais.

• Uma única ação síncrona pode realizar até três ações de continuação. A continuação anterior deve ser concluída antes de uma nova ação de continuação ser realizada.
• Cada ação de continuação pode realizar no máximo três chamadas, que são executadas em paralelo.
• Quando todas as chamadas realizadas por uma ação de continuação forem concluídas, a plataforma chamará o método de retorno de chamada de continuação para lidar com os resultados.

Embora as continuações sejam executadas de forma assíncrona em relação à ação síncrona de origem, há diferenças importantes entre as Continuations do Apex e outras técnicas assíncronas do Apex, como os métodos futuros, Queueable ou Batch. As principais diferenças são:

• As continuações não são colocadas em fila de modo algum.
• As continuações não contribuem para o limite diário de execução assíncrona do Apex.
• As continuações alternam o contexto de thread no servidor de aplicativos de um thread de plataforma Apex pesado para um thread leve que realiza apenas chamadas. Para fins de execução de chamadas que podem durar até 120 segundos, as continuações oferecem importantes economias de memória do servidor do aplicativo.
• Originalmente, as continuações só podiam ser executadas a partir de uma chamada remota JavaScript do Visualforce. No entanto, na versão Summer '19, continuidades foram adicionadas oficialmente à estrutura do Componente do Lightning, o que eliminou a necessidade do Visualforce.

Eventos de plataforma são a implementação da Salesforce Platform de uma arquitetura puramente orientada por evento. Você pode encontrar mais detalhes sobre os componentes associados a esse tipo de arquitetura no Guia do arquiteto para arquitetura conduzida por evento.

Eventos de plataforma e acionadores/fluxos de evento de plataforma são muitas vezes ótimas alternativas para executar Apex assíncrono. Eles também são uma ótima maneira de invocar o processamento fora da plataforma. Por exemplo, você pode usar uma combinação de relés de evento da Amazon Web Services (AWS) e eventos de plataforma para invocar a funcionalidade de computação sem servidor no AWS Lambda. O trabalho realizado de modo relativamente rápido e sem nenhuma chamada (que não é possível de um acionador de evento de plataforma ou fluxo) é um ótimo candidato para uma combinação de evento/acionador de plataforma ou evento/fluxo.

Os eventos publicados no barramento por meio de publicar após a confirmação são entregues em ordem e podem ser processados em massa pelo acionador ou fluxo em um contexto síncrono separado. O contexto é síncrono e impõe todos os limites do controlador síncrono. Escolha o tamanho do lote de acionador de evento de plataforma/fluxo com cuidado para evitar atingir limites.

• Conforme os eventos são publicados no barramento de eventos, eles estão disponíveis para os consumidores. No caso de acionadores de evento (Apex ou fluxo), esses eventos são enviados para os threads síncronos disponíveis no nível do aplicativo (um thread por acionador de evento/fluxo). Observe que esse processo não tem um SLA.
• Quando operações de publicação são adicionadas à fila, o resultado do processo de enfileiramento é armazenado no objeto Database.SaveResult. Essas entradas indicam apenas se a operação de enfileiramento foi bem-sucedida ou não. Para obter o resultado final de um evento publicado por meio do barramento de eventos, implemente um retorno de publicação do Apex. Com essas informações adicionais, você pode tomar decisões sobre ações adicionais, como tentar republicar eventos com falha.
• Embora os eventos de plataforma não estejam sujeitos aos mesmos limites do Apex assíncrono, eles têm seus próprios conjuntos de limites de governador. Se você encontrar problemas com limites, poderá habilitar as métricas de uso de eventos aprimoradas para determinar se eventos específicos estão usando mais suas alocações do que o esperado. Se você precisar de maior taxa de transferência em acionadores de evento, considere usar assinaturas paralelas para processar eventos simultaneamente, em vez de em um único fluxo. Com assinaturas paralelas, você pode dimensionar acionadores de evento da plataforma Apex para lidar com grandes volumes de eventos. Assinaturas paralelas estão disponíveis para eventos de plataforma de alto volume personalizados, mas não para eventos padrão ou eventos de alteração.
• Os eventos de plataforma têm duas opções para o comportamento de publicação:
  • Publicar imediatamente: Os eventos são publicados imediatamente durante a transação, antes da confirmação do banco de dados final. Os eventos publicados dessa maneira não têm garantia de serem publicados na ordem.
  • Publicar após confirmação: Os eventos são publicados no momento em que a transação do banco de dados é confirmada com sucesso. Os eventos publicados dessa maneira têm garantia de serem publicados na ordem.

É útil usar Publicar imediatamente para casos de uso como registro, em que você deseja publicar o evento de registro independentemente de a transação ser bem-sucedida e confirmada ou falhar e reverter. É possível publicar imediatamente um evento de plataforma que seja consumido por um acionador de evento de plataforma. O acionador de evento de plataforma então compete por um bloqueio de linha de banco de dados com a transação que o publicou. Revise todos os designs cuidadosamente antes de publicar imediatamente eventos de plataforma para garantir que você evite esse cenário.

Fluxos assíncronos fornecem alternativas de código baixo ao Apex assíncrono. Como acontece com outras formas de processamento assíncrono, eles são executados em segundo plano quando os recursos estão disponíveis. Fluxos assíncronos também não têm SLAs e podem ter tempos de espera imprevisíveis.

Os caminhos agendados são baseados em acionador cron para serem executados em um horário específico. Eles são executados quando os registros são criados, atualizados ou excluídos e dão a você controle granular sobre quando executar a automação em relação à alteração do registro. (Exemplo: enviar um email a um usuário uma hora antes do vencimento da tarefa.) Diferentemente dos métodos futuros do Apex, que estão limitados a um máximo de 50 métodos enfileirados em uma transação síncrona, as ações de fluxo agendadas atualmente não têm um limite máximo de enfileiramento por transação. No entanto, há uma configuração de tamanho de lote na definição do caminho agendado que permite algum controle sobre quantos registros são processados pela execução do fluxo de caminho agendado.

Caminhos assíncronos podem ser adicionados a fluxos acionados por registro. Eles são executados em segundo plano e não atrasam a execução da transação que acionou o fluxo originalmente. Você pode usar um caminho assíncrono para executar uma operação de execução longa ou qualquer operação que queira executar em seu próprio horário. Caminhos assíncronos podem ajudar a evitar erros de DML mistos que ocorrem quando você precisa atualizar um valor em um registro relacionado que não faz parte do registro que acionou o fluxo.

Nota: As mensagens de saída são um recurso legado e os eventos de plataforma (descritos na seção anterior) são uma abordagem mais moderna e oferecem maior flexibilidade. Eventos de plataforma são o padrão recomendado pela Salesforce para integração conduzida por evento.

Mensagens de saída fornecem um meio de comunicação de saída assíncrona por meio da API SOAP. Quando configurada no Salesforce, a definição de mensagem de saída produz um WSDL SOAP que pode ser consumido por um provedor de serviços da Web externo. As mensagens de saída podem ser acionadas de regras de fluxo de trabalho, processos do Criador de processos ou acionadores de fluxo após salvar do Lightning. Uma mensagem SOAP de saída pode conter até 100 notificações. Cada notificação contém o ID do objeto e uma referência aos dados do sObject associados. Se as informações no objeto subjacente mudarem depois que a notificação for colocada na fila, mas antes de ela ser enviada, apenas os dados mais recentes serão entregues, não as alterações intermediárias.

Quando um ouvinte de mensagem de saída (o serviço da Web configurado com o WSDL gerado) recebe uma mensagem, ele usa as informações de ID da sessão incluídas para chamar a API da Plataforma do Lightning para atualizar o registro no Salesforce que acionou a mensagem de saída.

• As mensagens de saída não são processadas por meio da infraestrutura assíncrona baseada em fila no Salesforce que executa atividades como métodos futuros, Apex enfileirável, Apex em lote, API em massa e assim por diante. Em vez disso, os registros são armazenados localmente no objeto OutboundMessage. As mensagens são despachadas e testadas novamente por meio de um processo em segundo plano agendado local.
• As mensagens não são enviadas de modo síncrono quando a ação de mensagem de saída é executada pela automação de início (por exemplo, um acionador de fluxo após salvar). Em vez disso, eles permanecem no objeto OutboundMessage até serem enviados com sucesso ou serem descartados após 24 horas de entrega malsucedida.
• Para evitar um loop infinito de mensagens de saída, garanta que o usuário que atualiza os objetos não tenha a permissão Enviar mensagens de saída.

O Email-to-Case normalmente funciona de maneira síncrona. Há um limite de quatro threads síncronos para lidar com solicitações de entrada do Email-to-Case. A forma síncrona do manipulador mantém uma conexão com o servidor de correspondência do Salesforce (MTA) de entrada que recebe o email. No entanto, há motivos pelos quais o Email-to-Case pode ser processado de modo assíncrono:

• O Email-to-Case está sujeito a limites de thread, especificamente, um total de 10 threads de manipulador por servidor de aplicativo: quatro threads para processamento síncrono e seis threads para processamento assíncrono.
• Se um manipulador de email síncrono exceder 15 segundos do tempo de execução, esse endereço de serviço de email específico será marcado como assíncrono por um período de 30 minutos. Solicitações subsequentes do manipulador para esse endereço de serviço resultam em uma mensagem enfileirada para MessageTypeName = MAILCATCHER_EMAIL_TO_CASE, junto com uma referência ao conteúdo do email.
• Se um encadeamento síncrono já estiver em uso para uma determinada organização e endereço de serviço, as solicitações adicionais para esse endereço de serviço serão colocadas na fila de modo assíncrono.
• Se um email processado de modo síncrono encontrar um erro, como um tempo limite de bloqueio de linha, a solicitação será salva e colocada na fila de modo assíncrono.
• Se não houver threads de manipulador síncrono disponíveis, a solicitação será colocada na fila de modo assíncrono.

• Há uma opção de desduplicação quando você configura o Email-to-Case, mas ele não desduplica anexos até depois que o email é processado. Essa desduplicação economiza espaço no banco de dados, mas não reduz os tempos de processamento de email. No entanto, você pode melhorar o desempenho implementando um manipulador personalizado do Apex Email-to-Case para processamento de mensagens. Essa implementação não afeta os limites do controlador, mas dá ao manipulador acesso à mensagem de email e a todos os seus anexos antes que algo seja confirmado no banco de dados. Esse acesso permite que você calcule somas de verificação para todos os anexos incluídos e descartar qualquer um que você considere desnecessário, incluindo duplicados, imagens de assinatura bem conhecidas ou tipos de arquivo indesejados.
• A confirmação de anexos de email no Salesforce Files é responsável pela maior parte do tempo de processamento de email. Conforme as respostas de resposta para ou do contato aumentam e a cadeia de email aumenta, o tempo de processamento de cada email também aumenta. Se a opção de email "Responder apenas com novo conteúdo" não estiver selecionada, as cadeias de email crescerão a cada resposta. Portanto, recomendamos usar um manipulador Email-to-Case do Apex com lógica que implemente a remoção de duplicação de anexos no momento do processamento.
• Apesar da invocação de acionadores do Apex como parte da manipulação, os manipuladores do Email-to-Case estão isentos do limite do Apex simultâneo.

Para processar grandes volumes de registros de modo assíncrono, considere usar uma destas abordagens.

Você pode usar o Apex em lote para criar processos complexos e de longa duração que envolvem milhares de registros. O Apex em lote opera dividindo seu conjunto de registros e processando-o em blocos gerenciáveis. Por exemplo, você pode criar uma solução de arquivamento que seja executada diariamente e adicione registros mais antigos que uma determinada data a um arquivo. Ou você pode criar uma operação de limpeza de dados que analisa todas as contas e oportunidades diariamente e realiza as atualizações necessárias com base em um conjunto de critérios predefinidos.

• O Apex em lote é melhor para processar grandes quantidades de dados porque o Apex assíncrono tem limites mais altos do que o Apex síncrono. O Apex em lote também tem um desempenho mais eficiente quando processa mais itens por lote, pois usa operações em massa que geram menos sobrecarga do gerenciamento de filas. Portanto, para evitar acionar o mecanismo de controle de fluxo por meio de inundação de filas e evitar esgotar o limite diário assíncrono do Apex, não crie lotes com tamanhos de escopo pequenos ou que tenham tempos de processamento rápidos.
• Evite colocar em fila trabalhos em lote diretamente de ações geradas por grandes volumes de atividades do usuário final ou chamadas à API de integração. Essa abordagem pode rapidamente esgotar a fila flexível. Se você planeja invocar um trabalho em lote de um acionador, deverá garantir que o acionador não adicione mais trabalhos em lote que o limite.
• O Apex em lote é limitado a um máximo de cinco threads simultâneos, o que limita sua taxa de transferência muito mais do que os métodos futuros ou o Apex enfileirável.
• Os trabalhos em lote que envolvem grandes volumes de dados devem idealmente ser agendados para execução fora do horário de pico para liberar recursos para processos que exigem respostas em tempo real ou quase em tempo real.
• Quando você chama System.scheduleBatch, a plataforma agenda seu trabalho para execução no horário especificado. A execução real ocorre nesse horário ou posterior, dependendo da disponibilidade do serviço.
• O agendador é executado no contexto do sistema. Todas as classes são executadas, independentemente de o usuário que agendou a execução ter ou não permissão para executar a classe.
• Todos os limites do Apex agendados se aplicam a trabalhos em lote agendados usando System.scheduleBatch. Depois que o trabalho em lote é colocado na fila (com um status de Em espera ou Em fila), todos os limites de trabalho em lote se aplicam e o trabalho não conta mais para os limites agendados do Apex.
• Para um trabalho em lote com uma agenda recorrente, considere o comportamento correto se o trabalho anterior ainda estiver sendo executado quando o novo trabalho começar a ser executado.
• Os trabalhos em lote enfileirados de transações síncronas do Apex usam a fila flexível. A fila flexível está limitada a um máximo de 100 itens a qualquer momento. Se uma transação tentar adicionar mais entradas, a plataforma gerará erros e não enviará o trabalho em lote.
• Chamadas e outras operações não transacionais de trabalhos em lote devem seguir as considerações de design idempotente. Os trabalhos em lote colocados na fila antes de um tempo de inatividade de manutenção de serviço do Salesforce permanecer na fila. Depois que o tempo de inatividade do serviço termina e os recursos do sistema estão disponíveis, os trabalhos em lote em fila são executados. Se um trabalho em lote estiver em execução quando o tempo de inatividade ocorrer, a execução do lote será revertida e reiniciada após a restauração do serviço. Como os métodos de execução podem ser executados várias vezes, qualquer operação não transacional, como chamadas, pode ser repetida.
• Considere configurar o trabalho em lote para gerar eventos BatchApexErrorEvent para lidar com cenários de erro e exceção.

Um fluxo acionado por agenda é um fluxo agendado para ser executado em um horário especificado e com uma frequência repetida (diária, semanal ou uma vez) para realizar ações em um lote de registros. (Exemplo: atualize um campo em todos os casos com um status de "Aberto" às 2h todas as noites.) Fluxos agendados são executados por meio do mecanismo do acionador cron e processados em massa.

• Um fluxo acionado por agenda executa 200 registros por invocação, mas será executado com vários threads simultâneos se houver mais de 200 registros presentes.
• Fluxos acionados por agenda são executados em um contexto síncrono com limites síncronos.
• No momento, não há maneira de controlar o número de registros processados por invocação de fluxo agendada. Se a execução for para mais de 200 registros, existe um perigo real de erros Concomitantes do Apex.

A API em massa é baseada em princípios REST e é otimizada para trabalhar com grandes conjuntos de dados. Você pode usá-lo para inserir, atualizar, inserir e atualizar, consultar ou excluir muitos registros de modo assíncrono e processar os resultados mais tarde. A Salesforce Platform processa a solicitação em segundo plano. Por outro lado, a API SOAP e a API REST usam solicitações síncronas e são otimizadas para aplicativos cliente em tempo real que atualizam alguns registros por vez. Você pode usar ambas as APIs para processar muitos registros, mas quando os conjuntos de dados contêm centenas de milhares de registros, eles são menos práticos. A estrutura assíncrona da API em massa é projetada para tornar simples e eficiente o processamento de dados de alguns milhares a milhões de registros.

A maneira mais fácil de usar a API em massa é habilitá-la para processar registros no Data Loader usando arquivos CSV. Com o Data Loader, você não precisa escrever seu próprio aplicativo cliente. Porém, às vezes, requisitos exclusivos exigem a criação de um aplicativo personalizado.

Há duas APIs em massa disponíveis na Salesforce Platform.

• A API 2.0 em massa é a API mais recente. Ele fornece um fluxo de trabalho simplificado e fácil de usar e é o foco para aprimoramentos.
• A API em massa original ainda tem suporte total, mas não está mais sendo aprimorada. Recomendamos usar a API 2.0 em massa quando possível.

Para obter mais informações sobre limites de API, consulte Limites de API em massa e Limites de API em massa 2.0.

Consulte este guia ao criar ou considerar o processamento assíncrono na Salesforce Platform. Sempre é uma boa ideia entender todo o escopo de opções disponíveis para você e como elas podem se ajustar ao seu caso de uso específico. Avalie cuidadosamente sua paisagem atual antes de fazer alterações em qualquer arquitetura existente, especialmente se sua solução atual estiver funcionando bem.