Cambiar a OAuth 2.0 para el conector de Salesforce en Jitterbit Studio

Introducción

Salesforce está retirando el método de autenticación login() de la API SOAP (nombre de usuario, contraseña y token de seguridad). Cualquier conexión de Salesforce configurada con Autenticación básica utiliza este método y debe cambiarse a OAuth 2.0 Client Credentials para seguir funcionando.

Salesforce no está retirando la API SOAP en general. Solo cambia el paso de inicio de sesión, de una llamada login() basada en SOAP a una solicitud de token OAuth 2.0, por lo que tus actividades, transformaciones y operaciones existentes siguen funcionando igual.

Esta guía cubre el cambio de extremo a extremo para una única conexión: qué configurar en Salesforce, qué cambiar en Studio y cómo validar el resultado antes de implementarlo. Los mismos pasos se aplican a los conectores Salesforce Service Cloud y ServiceMax, que comparten el mismo flujo de autenticación.

Las conexiones ya configuradas con OAuth 2.0 Client Credentials no requieren cambios.

Esta guía te lleva a través de cinco pasos:

1. Confirma la versión de tu agente e identifica cada conexión que necesita cambiar.
2. Recopila una URL de instancia, ID de cliente y secreto de cliente de una aplicación cliente externa de Salesforce o aplicación conectada.
3. Cambia la conexión a OAuth 2.0 Client Credentials e introduce las nuevas credenciales.
4. Verifica el cambio implementando y ejecutando las operaciones que usan la conexión.
5. Implementa el cambio en producción.

Qué cambia y qué no

El tipo de autenticación es una propiedad de la conexión, por lo que un único cambio cubre todas las actividades y scripts que usan esa conexión:

Antes de comenzar

Confirma la versión del agente

OAuth 2.0 Client Credentials requiere agentes en la nube, o un agente privado que cumpla con estas versiones mínimas:

Verifica el grupo de agentes para cada ambiente afectado.

Identifica las conexiones a cambiar

Prepara un inventario antes de empezar, para que cada cambio sea intencional y no reactivo. La página Endpoints Usage de la Consola de Administración es el único lugar que lista endpoints de Salesforce en todos los proyectos y ambientes de tu organización, así que comienza ahí:

1. Abre la página Endpoints Usage y busca las filas para el conector de Salesforce y la función SalesforceLogin. Esta página requiere el permiso de rol de Admin.

2. Haz clic en un endpoint para abrir el cajón de detalles del endpoint, que lista el Ambiente, Proyecto y Operación donde se usa ese endpoint.

3. Haz clic en Go to endpoint para abrir la conexión en Studio, luego verifica su tipo de autenticación. Las conexiones establecidas en Basic Auth necesitan el cambio.

4. Repite para cada fila de Salesforce para construir la lista completa.

Los scripts que hacen referencia a una conexión de Salesforce a través de funciones de Salesforce no necesitan edición, pero incluye las operaciones que los ejecutan cuando valides.

Recopila los valores que necesitas de Salesforce

OAuth 2.0 Client Credentials se autentica con una URL de instancia, un ID de cliente y un secreto de cliente, que provienen de una app de cliente externo de Salesforce o una app conectada. Para el procedimiento completo, consulta Requisitos previos de OAuth 2.0 de 2 patas.

• URL de instancia: Tu URL de instancia de Salesforce, que depende de la configuración My Domain de tu organización. Con My Domain habilitado (el predeterminado), toma la forma https://exampleDomain.my.salesforce.com.

• ID de cliente y secreto de cliente: La Consumer Key y Consumer Secret de tu app de Salesforce.

  Importante

  A partir de Spring 2026, Salesforce restringió la creación de apps conectadas. Crea una app de cliente externo a menos que ya tengas una app conectada existente.

Independientemente del tipo de app que uses, confirma estas configuraciones en Salesforce:

• Enable Client Credentials Flow está seleccionado en la configuración de OAuth de la app y en sus políticas de Client Credentials Flow.
• En OAuth Scopes, está seleccionado Manage user data via APIs (api), junto con cualquier otro scope que tu integración requiera.
• Para una app cliente externa, la Callback URL se establece en la URL de tu región de la organización.
• Un usuario de Salesforce se asigna como el usuario Run As (o de ejecución) de la app.

Cambia la conexión a OAuth 2.0

Realiza el cambio en un ambiente que no sea producción primero, luego promociona el proyecto validado.

1. Registra los valores existentes de Server host, Sandbox y Username de la conexión. Mantener estos valores te permite restaurar la conexión si necesitas revertir antes de que la validación se complete.

2. Abre la conexión de Salesforce para editarla desde la paleta de componentes de diseño, la pestaña Componentes del panel del proyecto, o la página Global Endpoints.

3. Cambia Authentication type de Basic Auth a OAuth 2.0 Client Credentials. Los campos de credenciales cambian a Instance URL, Client ID y Client secret.

   

4. Ingresa la Instance URL, Client ID y Client secret que recopilaste de Salesforce. Cada uno de estos campos admite variables de proyecto, lo que permite que el mismo proyecto use credenciales diferentes en cada ambiente.

5. Haz clic en Test para verificar la conexión, luego haz clic en Save.

Para obtener una descripción de cada campo en esta pantalla, consulta Configura una conexión de Salesforce.

Verifica el cambio

Una prueba de conexión exitosa solo confirma que las credenciales son válidas. Ejecuta las operaciones para confirmar que los permisos del usuario Run As son suficientes.

1. Sigue los pasos en Despliega y ejecuta una operación para desplegar y ejecutar las operaciones que utilizan la conexión actualizada, incluyendo cualquier operación que ejecute scripts que hagan referencia a la conexión.

2. En los registros de operación, confirma que cada operación se ejecutó correctamente y compara los recuentos de registros con una ejecución anterior al cambio. Un éxito con menos registros de lo esperado generalmente indica que el usuario Run As carece de acceso de lectura a algunos registros, objetos o campos.

3. Abre una actividad que utilice la conexión y haz clic en Refresh para recargar la lista Select Object(s) desde Salesforce. Si objetos o campos que existían antes ahora faltan, el usuario Run As carece de acceso a ellos en Salesforce.

4. Verifica spot-check en los registros escritos en Salesforce para confirmar que los valores de los campos se completaron como se esperaba.

5. (Opcional) Confirma que nada sigue usando SOAP API login(). Salesforce proporciona una ejecución de prueba que bloquea todas las llamadas login() a una org y devuelve la misma respuesta que el retiro. En Salesforce Setup, bajo Release Updates, abre la actualización SOAP API login() Retirement, selecciona View Update, luego selecciona Enable Test Run. Selecciona Disable Test Run para restaurar login().

   Precaución

   Una ejecución de prueba se aplica a toda la org de Salesforce, por lo que cualquier integración que aún use login() falla mientras está habilitada. Ejecuta en un sandbox después de haber cambiado cada conexión que se autentica en esa org.

6. (Opcional, solo agentes privados) Para confirmar la versión exacta de la API de Salesforce que utilizó una solicitud, consulta el registro tomcat/logs/catalina.out del agente inmediatamente después de hacer clic en Test en la conexión o ejecutar una operación. Registra la URL de la solicitud, por ejemplo Service request URL: https://login.salesforce.com/services/Soap/u/64.0, donde el número después de /u/ es la versión de la API invocada.

Implementa el cambio

1. Una vez validado, sigue los pasos en Project transfer para transferir el proyecto a tu entorno de producción.

2. Si el entorno de producción utiliza credenciales de aplicación de Salesforce separadas, actualiza la conexión con los valores de esa aplicación. Usar project variables para el ID de cliente y el secreto de cliente limita esto a un cambio de valor de variable por entorno.

3. Sigue los pasos en Deploy and execute an operation para implementar las operaciones que usan la conexión actualizada, luego confirma que las primeras ejecuciones programadas o activadas se completen correctamente.

4. Una vez que se valide cada entorno, retira la cuenta de Salesforce que se usó previamente para Basic Auth de acuerdo con las prácticas de tu organización.

¿Necesitas ayuda?

Para errores de autenticación y configuración, consulta Salesforce connector troubleshooting.

Para un cambio coordinado o ayuda para planificarlo, contacta al Jitterbit support o a Jitterbit Professional Services.