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

Introducción

Salesforce está retirando el método de autenticación login() de SOAP API (nombre de usuario, contraseña y token de seguridad). Cualquier organización de Salesforce configurada con autenticación básica utiliza este método y debe cambiar a autenticación de cliente OAuth 2.0 de dos pasos para seguir funcionando.

Salesforce no está retirando SOAP API en su totalidad. 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 los asistentes, transformaciones y operaciones existentes siguen funcionando tal como están.

Esta guía cubre el cambio completo de una única organización de Salesforce: qué configurar en Salesforce, qué cambiar en Design Studio y cómo validar el resultado antes de migrar el proyecto.

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

1. Confirma tus versiones de Design Studio y agent e identifica cada organización de Salesforce que necesita cambiar.
2. Recopila una URL de instancia, ID de cliente y secreto de cliente de una aplicación de cliente externo de Salesforce o una aplicación conectada.
3. Cambia la organización de Salesforce para utilizar autenticación de cliente OAuth 2.0 de dos pasos e introduce las nuevas credenciales.
4. Verifica el cambio desplegando y ejecutando las operaciones que utilizan la organización.
5. Migra el cambio validado a producción.

Qué cambia y qué no

La autenticación es una propiedad de la organización de Salesforce, por lo que un único cambio cubre cada asistente y script que utiliza esa organización:

Antes de comenzar

Confirma las versiones de Design Studio y del agente

OAuth 2.0 de dos tramos con los asistentes de Jitterbit Connect Salesforce requiere Design Studio versión 11.59 o posterior. También requiere agentes en la nube o una versión de agente privado 11.59 (para agentes 11.x) o 12.3 o posterior (para agentes 12.x).

Verifica el grupo de agentes para cada entorno afectado. La versión de API de Salesforce disponible para el proyecto también depende de estas versiones, tal como se indica en Versiones de API admitidas y requisitos previos.

Identifica los proyectos y organizaciones que cambiarás

Crea un inventario antes de comenzar, de modo que cada cambio sea deliberado en lugar de reactivo:

1. Encuentra los proyectos que utilizan Salesforce. La página Endpoints Usage de Management Console enumera todos los puntos de conexión de Salesforce en la organización, y su cajón de detalles del punto de conexión muestra el Proyecto y el Entorno donde se utiliza cada punto de conexión. Esta página requiere el permiso de rol Admin.

2. En Design Studio, abre cada organización de Salesforce en esos proyectos y verifica si la casilla Select OAuth 2.0 Client Credentials está seleccionada. Una organización sin ella seleccionada utiliza autenticación básica y necesita el cambio. Un proyecto puede contener múltiples organizaciones de Salesforce utilizando credenciales diferentes, y cada una necesita su propio cambio.

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

Recopila los valores que necesitas de Salesforce

OAuth 2.0 de dos tramos se autentica con una URL de instancia, un ID de cliente y un secreto de cliente, que provienen de una aplicación de cliente externo de Salesforce o de una aplicación conectada. Para el procedimiento completo, consulta Requisitos previos de OAuth 2.0 de dos tramos.

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

• ID de cliente y secreto de cliente: La Consumer Key y Consumer Secret de tu aplicación de Salesforce.

  Important

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

Sea cual sea el tipo de aplicación que utilices, confirma estas configuraciones en Salesforce:

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

Cambiar la organización de Salesforce a OAuth 2.0

Realiza el cambio primero en un entorno que no sea de producción, luego migra el proyecto validado.

1. Anota los valores existentes de Nombre de usuario y Token de seguridad de la organización de Salesforce. Conservar estos valores te permite restaurar la autenticación básica si necesitas revertir los cambios antes de completar la validación.

2. En Design Studio, abre la organización de Salesforce existente.

3. Marca la casilla Seleccionar credenciales del cliente OAuth 2.0 para habilitar los campos de credenciales del cliente OAuth 2.0.

   

4. Ingresa la URL de instancia, ID de cliente y Secreto del cliente que recopilaste de Salesforce. Cada uno de estos campos admite variables de proyecto, lo que permite que el mismo proyecto use diferentes credenciales en cada entorno.

5. Haz clic en Probar inicio de sesión en Salesforce y confirma que recibes un mensaje de éxito. Si el inicio de sesión falla, el mensaje incluye información para ayudarte a resolver el problema.

Verificar el cambio

Una prueba de inicio de sesión exitosa solo confirma que las credenciales son válidas. Ejecuta las operaciones para confirmar que los permisos del usuario Ejecutar como son suficientes.

1. Utiliza Acciones > Implementar (consulta el menú Acciones en Menús principales) para implementar el proyecto en un entorno que no sea de producción.

2. Ejecuta cada operación que utilice la organización de Salesforce, incluidas las operaciones que ejecutan scripts que la referencian. Consulta Probar una operación.

3. Revisa el registro de operaciones y confirma que cada operación se realizó correctamente, comparando los recuentos de registros con una ejecución anterior al cambio. Un éxito con menos registros de lo esperado generalmente indica que el usuario Ejecutar como carece de acceso de lectura a algunos registros, objetos o campos. Consulta Revisar un registro de operaciones.

4. Verifica una muestra de registros escritos en Salesforce para confirmar que los valores de los campos se rellenaron como se esperaba.

5. (Opcional) Confirma que nada sigue utilizando la API SOAP login(). Salesforce proporciona una ejecución de prueba que bloquea todas las llamadas a login() en una organización y devuelve la misma respuesta que el retiro. En la configuración de Salesforce, en Actualizaciones de versión, abre la actualización Retiro de API SOAP login(), selecciona Ver actualización y luego selecciona Habilitar ejecución de prueba. Selecciona Deshabilitar ejecución de prueba para restaurar login().

   Caution

   Una ejecución de prueba se aplica a toda la organización de Salesforce, por lo que cualquier integración que aún utilice login() falla mientras esté habilitada. Ejecuta esto en un sandbox después de haber cambiado cada proyecto de Design Studio que se autentica en esa organización.

6. (Opcional, solo agentes privados) Para confirmar la versión exacta de la API de Salesforce que utilizó una solicitud, consulta el archivo de registro tomcat/logs/catalina.out del agente inmediatamente después de hacer clic en Test Salesforce Login o ejecutar una operación. Se 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 API invocada.

Migra el cambio a producción

1. Una vez validado, usa File > Migrate Project (consulta el Menú File en Menús principales) para migrar el proyecto a tu entorno de producción.

2. Si el entorno de producción utiliza credenciales de aplicación de Salesforce separadas, repite los pasos en Cambia la organización de Salesforce a OAuth 2.0 para la organización de Salesforce de ese entorno.

3. Usa Actions > Deploy para desplegar el proyecto en el entorno de producción, luego confirma que las primeras ejecuciones programadas o activadas se completen exitosamente.

4. Una vez que valides todos los entornos, puedes aceptar la solicitud para actualizar el proyecto a una versión posterior de la API de Salesforce y retirar la cuenta de Salesforce que se usaba anteriormente para la autenticación básica de acuerdo con las prácticas de tu organización.

¿Necesitas ayuda?

Para un cambio coordinado o ayuda en su planeación, contacta al soporte de Jitterbit o a Jitterbit Professional Services.