Ir para o conteúdo

Mudança para OAuth 2.0 para o conector Salesforce no Design Studio

Introdução

A Salesforce está descontinuando o método de autenticação login() da API SOAP (nome de usuário, senha e token de segurança). Qualquer organização Salesforce configurada com autenticação básica usa este método e deve ser alterada para autenticação cliente OAuth 2.0 de duas pernas para continuar funcionando.

Quando O que acontece
Agora, na versão 65.0 da API Salesforce e posteriores O login() da API SOAP não está disponível, portanto uma organização Salesforce usando autenticação básica falha nessas versões de API. As versões de API 31.0 a 64.0 ainda funcionam por enquanto.
Lançamento Salesforce Summer '27 (meados de 2027) O login() da API SOAP será descontinuado nas versões de API 31.0 a 64.0, portanto qualquer organização Salesforce ainda usando autenticação básica falhará quando sua organização for atualizada.

A Salesforce não está descontinuando a API SOAP como um todo. Apenas a etapa de login muda, de uma chamada login() baseada em SOAP para uma solicitação de token OAuth 2.0, portanto seus assistentes, transformações e operações existentes continuam funcionando como estão.

Este guia cobre a alteração de ponta a ponta para uma única organização Salesforce: o que configurar no Salesforce, o que alterar no Design Studio e como validar o resultado antes de migrar o projeto.

Não aceite o prompt de atualização da versão de API do Salesforce primeiro

Quando você abre um projeto que usa uma versão anterior de API Salesforce, o Design Studio exibe um prompt para atualizar na caixa de diálogo Atualizar versão do Salesforce?. Aceitar esse prompt (Sim) enquanto a organização Salesforce ainda usa autenticação básica move o projeto para uma versão de API onde login() não está disponível e as operações falham. Conclua a alteração para OAuth 2.0 descrita nesta página antes de aceitar uma atualização para a versão de API Salesforce 65 ou posterior; selecione Não para manter o projeto em sua versão atual por enquanto. Para ver a versão que um projeto usa atualmente sem alterá-la, vá para Ações > Atualizar versão do Salesforce (consulte Menu Ações em Menus principais). A caixa de diálogo Atualizar projeto? informa a versão atual. Feche a caixa de diálogo sem atualizar.

Este guia percorre cinco etapas:

  1. Confirme suas versões do Design Studio e do agent e identifique todas as organizações Salesforce que precisam ser alteradas.
  2. Colete uma URL de instância, ID do cliente e segredo do cliente de um aplicativo cliente externo Salesforce ou aplicativo conectado.
  3. Altere a organização Salesforce para usar autenticação cliente OAuth 2.0 de duas pernas e insira as novas credenciais.
  4. Verifique a alteração implantando e executando as operações que usam a organização.
  5. Migre a alteração validada para produção.

O que muda e o que não muda

A autenticação é uma propriedade da organização Salesforce, portanto uma única alteração cobre cada assistente e script que usa essa organização:

%%{init: {"themeVariables": {"lineColor": "#6b7280", "edgeLabelBackground": "#f5f5f5"}}}%% flowchart LR A["Operation runs"] --> B{"Authentication"} B -->|"Before: SOAP API login()
with user name, password,
and security token"| C["Salesforce session"] B -->|"After: OAuth 2.0 token request
with client ID
and client secret"| C C --> D["Salesforce SOAP API call
Query, Insert, Update,
Upsert, or Delete"] D --> E["Records read or written"]
Componente Ação necessária
Organização Salesforce Selecione a caixa de seleção Selecionar Credenciais do Cliente OAuth 2.0 e complete os campos URL da Instância, ID do Cliente e Segredo do Cliente no lugar de Nome de usuário, Senha e Token de Segurança.
Assistentes Jitterbit Connect Salesforce Nenhuma ação necessária. Os assistentes Consulta, Inserir, Atualizar, Atualizar ou Inserir, Excluir e Processo em Massa mantêm suas seleções de objetos e esquemas existentes.
Transformações e mapeamentos Nenhuma ação necessária.
Operações e agendamentos Nenhuma ação necessária.
Scripts que usam funções Salesforce Nenhuma ação necessária. Funções como SalesforceLogin referenciam a organização Salesforce.
Permissões Salesforce Verifique se o usuário Executar Como tem acesso equivalente à conta usada anteriormente para autenticação básica. Consulte o aviso em Colete os valores necessários do Salesforce.

Antes de começar

A autenticação básica pode já estar bloqueada na sua organização Salesforce

O Salesforce desativa a API SOAP login() por padrão em organizações criadas a partir de Winter '26 e, onde está ativada, o usuário que se autentica precisa da permissão Use Any API Auth. Se uma organização Salesforce que usa autenticação básica já falha na autenticação, verifique ambas antes de continuar a solução de problemas. Mudar para autenticação de cliente OAuth 2.0 de 2 pernas remove a dependência de qualquer uma delas.

Confirme as versões do Design Studio e do agent

O OAuth 2.0 de 2 pernas com os assistentes Jitterbit Connect Salesforce exige Design Studio versão 11.59 ou posterior. Também exige agents na nuvem ou um agent privado versão 11.59 (para agents 11.x) ou 12.3 ou posterior (para agents 12.x).

Verifique o grupo de agents para cada ambiente afetado. A versão da API Salesforce disponível para o projeto também depende dessas versões, conforme listado em Versões de API suportadas e pré-requisitos.

Identifique os projetos e organizações a alterar

Faça um inventário antes de começar, para que cada alteração seja deliberada e não reativa:

  1. Encontre os projetos que usam Salesforce. A página Endpoints Usage do Management Console lista todos os endpoints Salesforce na organização, e sua drawer de detalhes do endpoint mostra o Project e Environment onde cada endpoint é usado. Esta página exige a permissão de função Admin.

  2. No Design Studio, abra cada organização Salesforce nesses projetos e verifique se a caixa de seleção Select OAuth 2.0 Client Credentials está marcada. Uma organização sem ela marcada usa autenticação básica e precisa da alteração. Um projeto pode conter múltiplas organizações Salesforce usando credenciais diferentes, e cada uma precisa sua própria alteração.

Endpoints que não foram executados recentemente

A página Endpoints Usage relata endpoints usados por uma operação que foi executada pelo menos uma vez nos últimos 12 meses em uma versão de agent 11.49 ou posterior. Para capturar organizações configuradas em projetos que não foram executados nessa janela, abra esses projetos no Design Studio e verifique cada organização Salesforce diretamente.

Scripts que fazem referência a uma organização Salesforce através de funções Salesforce não precisam de edição, mas inclua as operações que as executam quando validar.

Colete os valores necessários do Salesforce

O OAuth 2.0 de 2 pernas se autentica com uma URL de instância, um ID de cliente e um segredo do cliente, que vêm de um app de cliente externo Salesforce ou um app conectado. Para o procedimento completo, consulte Pré-requisitos OAuth 2.0 de 2 pernas.

  • Instance URL: Sua URL de instância Salesforce, que depende da configuração My Domain da sua organização. Com My Domain ativado (o padrão), ele tem a forma https://exampleDomain.my.salesforce.com.

  • Client ID e client secret: A Consumer Key e Consumer Secret do seu app Salesforce.

    Important

    A partir de Spring 2026, o Salesforce restringiu a criação de apps conectados. Crie um app de cliente externo a menos que você já tenha um app conectado existente.

Qualquer que seja o tipo de app que use, confirme estas configurações no Salesforce:

  • Enable Client Credentials Flow está marcado nas configurações OAuth do app e em suas políticas de Client Credentials Flow.
  • Em OAuth Scopes, Manage user data via APIs (api) está marcado, junto com qualquer outro escopo que sua integração exija.
  • Para um app de cliente externo, a Callback URL está definida para a URL da região da sua organização.
  • Um usuário Salesforce está atribuído como o usuário Run As (ou execução) do app.

Verifique as permissões do usuário Executar Como

O usuário Executar Como determina o que a conexão pode acessar, substituindo as permissões da conta Salesforce usada anteriormente para autenticação básica. Se esse usuário tiver permissões mais restritas, as operações poderão falhar ou retornar dados incompletos em vez de falhar completamente. Antes de implantar, confirme se o usuário Executar Como tem acesso a todos os objetos e campos usados pelos assistentes existentes. Para orgs da Enterprise Edition, a Salesforce recomenda um usuário com a permissão API Only User. Use uma conta de integração dedicada em vez da conta de um indivíduo nomeado, para que a conexão não quebre se o acesso dessa pessoa mudar.

Alterar a org Salesforce para OAuth 2.0

Faça a alteração primeiro em um ambiente de não produção e depois migre o projeto validado.

  1. Anote os valores existentes de Nome de usuário e Token de segurança da org Salesforce. Manter esses valores permite restaurar a autenticação básica se precisar reverter antes de concluir a validação.

  2. No Design Studio, abra o assistente de org Salesforce existente.

  3. Marque a caixa de seleção Selecionar Credenciais de Cliente OAuth 2.0 para ativar os campos de credencial de cliente OAuth 2.0.

    Assistente de Org Salesforce com a caixa de seleção Selecionar Credenciais de Cliente OAuth 2.0 marcada

  4. Digite a URL da instância, a ID do cliente e o Segredo do cliente que você coletou do Salesforce. Cada um desses campos oferece suporte a variáveis de projeto, o que permite que o mesmo projeto use credenciais diferentes em cada ambiente.

  5. Clique em Testar login do Salesforce e confirme se recebe uma mensagem de sucesso. Se o login falhar, a mensagem inclui informações para ajudar a resolver o problema.

Veja isso configurado no Design Studio

Verificar a alteração

Um teste de login bem-sucedido confirma apenas que as credenciais são válidas. Execute as operações para confirmar se as permissões do usuário Executar Como são suficientes.

  1. Use Ações > Implantar (veja Menu Ações em Menus principais) para implantar o projeto em um ambiente de não produção.

  2. Execute cada operação que usa a org Salesforce, incluindo qualquer operação que execute scripts referenciando-a. Veja Testar uma operação.

  3. Revise o log da operação e confirme se cada operação foi bem-sucedida, verificando as contagens de registros em relação a uma execução anterior à alteração. Um sucesso com menos registros do que o esperado geralmente indica que o usuário Executar Como não tem acesso de leitura a alguns registros, objetos ou campos. Veja Revisar um log de operação.

  4. Faça uma verificação rápida dos registros gravados no Salesforce para confirmar se os valores dos campos foram preenchidos conforme esperado.

  5. (Opcional) Confirme se nada ainda usa a API SOAP login(). A Salesforce fornece uma execução de teste que bloqueia todas as chamadas login() para uma org e retorna a mesma resposta que a desativação. No Salesforce Setup, em Release Updates, abra a atualização SOAP API login() Retirement, selecione View Update e depois selecione Enable Test Run. Selecione Disable Test Run para restaurar login().

    Caution

    Uma execução de teste se aplica a toda a org Salesforce, portanto, qualquer integração que ainda use login() falhará enquanto estiver ativada. Execute-a em um sandbox depois de ter alterado todos os projetos do Design Studio que se autenticam nessa org.

  6. (Opcional, apenas para agentes privados) Para confirmar a versão exata da API Salesforce que uma solicitação usou, verifique o log tomcat/logs/catalina.out do agente logo após clicar em Test Salesforce Login ou executar uma operação. Ele registra a URL da solicitação, por exemplo Service request URL: https://login.salesforce.com/services/Soap/u/64.0, onde o número após /u/ é a versão da API invocada.

Migrar a alteração para produção

  1. Após validar, use File > Migrate Project (veja File menu em Main menus) para migrar o projeto para seu ambiente de produção.

  2. Se o ambiente de produção usa credenciais de aplicativo Salesforce separadas, repita as etapas em Change the Salesforce org to OAuth 2.0 para a org Salesforce desse ambiente.

  3. Use Actions > Deploy para implantar o projeto no ambiente de produção, em seguida, confirme se as primeiras execuções agendadas ou acionadas completam com êxito.

  4. Quando todos os ambientes estiverem validados, você pode aceitar o aviso para atualizar o projeto para uma versão posterior da API Salesforce e desativar a conta Salesforce anteriormente usada para autenticação básica de acordo com as práticas de sua organização.

Precisa de ajuda?

Para uma alteração coordenada ou assistência ao planejá-la, entre em contato com Jitterbit support ou Jitterbit Professional Services.