Wechsel zu OAuth 2.0 für den Salesforce-Connector in Design Studio

Einführung

Salesforce stellt die SOAP-API-Authentifizierungsmethode login() (Benutzername, Passwort und Sicherheits-Token) ein. Alle Salesforce-Organisationen, die mit Basisauthentifizierung konfiguriert sind, nutzen diese Methode und müssen zur zweibeinigen OAuth 2.0-Client-Authentifizierung wechseln, um weiterhin zu funktionieren.

Salesforce stellt die SOAP-API als Ganzes nicht ein. Nur der Login-Schritt ändert sich – von einem SOAP-basierten login()-Aufruf zu einer OAuth 2.0-Token-Anforderung. Ihre bestehenden Assistenten, Transformationen und Operationen funktionieren wie bisher.

Diese Anleitung behandelt die umfassende Änderung für eine einzelne Salesforce-Organisation: was man in Salesforce konfiguriert, was man in Design Studio ändert und wie man das Ergebnis validiert, bevor man das Projekt migriert.

Diese Anleitung führt durch fünf Schritte:

1. Bestätige deine Design Studio- und Agent-Versionen und identifiziere alle Salesforce-Organisationen, die geändert werden müssen.
2. Erfasse eine Instanz-URL, eine Client-ID und einen Client-Secret aus einer externen Salesforce-Client-App oder einer verbundenen App.
3. Ändere die Salesforce-Organisation, um die zweibeinige OAuth 2.0-Client-Authentifizierung zu nutzen, und gebe die neuen Zugangsdaten ein.
4. Validiere die Änderung, indem du die Operationen bereitstellst und ausführst, die die Organisation nutzen.
5. Migriere die validierte Änderung in die Produktion.

Was sich ändert und was nicht

Authentifizierung ist eine Eigenschaft der Salesforce-Organisation, daher eine einzelne Änderung deckt alle Assistenten und Skripte ab, die diese Organisation nutzen:

Bevor Sie beginnen

Design Studio und Agent-Versionen überprüfen

2-legged OAuth 2.0 mit den Jitterbit Connect Salesforce-Assistenten erfordert Design Studio Version 11.59 oder später. Außerdem wird entweder ein Cloud Agent oder ein Private Agent Version 11.59 (für 11.x Agents) oder 12.3 oder später (für 12.x Agents) benötigt.

Überprüfen Sie die Agent-Gruppe für jede betroffene Umgebung. Die für das Projekt verfügbare Salesforce-API-Version hängt auch von diesen Versionen ab, wie in Unterstützte API-Versionen und Voraussetzungen aufgelistet.

Projekte und Organisationen identifizieren, die geändert werden sollen

Erstellen Sie einen Überblick, bevor Sie beginnen, damit jede Änderung bewusst und nicht reaktiv erfolgt:

1. Suchen Sie die Projekte, die Salesforce verwenden. Die Seite Endpoints Usage der Management Console listet jeden Salesforce-Endpoint in der Organisation auf, und die Endpoint-Details-Schublade zeigt das Projekt und die Umgebung, in denen jeder Endpoint verwendet wird. Diese Seite erfordert die Rollenberechtigung Admin.

2. Öffnen Sie in Design Studio jede Salesforce-Organisation in diesen Projekten und überprüfen Sie, ob das Kontrollkästchen Select OAuth 2.0 Client Credentials ausgewählt ist. Eine Organisation ohne Auswahl verwendet Standardauthentifizierung und benötigt die Änderung. Ein Projekt kann mehrere Salesforce-Organisationen mit unterschiedlichen Anmeldedaten enthalten, und jede benötigt eine eigene Änderung.

Scripts, die auf eine Salesforce-Organisation über Salesforce-Funktionen verweisen, müssen nicht bearbeitet werden, aber beziehen Sie die Vorgänge ein, die sie ausführen, wenn Sie validieren.

Benötigte Werte aus Salesforce sammeln

2-legged OAuth 2.0 authentifiziert sich mit einer Instance URL, einer Client-ID und einem Client-Secret, die aus einer Salesforce-Externe-Client-App oder Connected App stammen. Für das vollständige Verfahren siehe 2-legged OAuth 2.0 Voraussetzungen.

• Instance URL: Ihre Salesforce-Instance-URL, die von der Einstellung My Domain Ihrer Organisation abhängt. Mit aktivierter My Domain (Standard) hat sie die Form https://exampleDomain.my.salesforce.com.

• Client-ID und Client-Secret: Der Consumer Key und Consumer Secret Ihrer Salesforce-App.

  Important

  Ab Frühjahr 2026 hat Salesforce die Erstellung von Connected Apps eingeschränkt. Erstellen Sie eine Externe-Client-App, falls Sie noch keine vorhandene Connected App haben.

Bestätigen Sie unabhängig von der verwendeten App-Art diese Einstellungen in Salesforce:

• Enable Client Credentials Flow ist in den OAuth-Einstellungen der App und in ihren Client Credentials Flow-Richtlinien ausgewählt.
• Unter OAuth Scopes ist Manage user data via APIs (api) ausgewählt, zusammen mit allen anderen Scopes, die Ihre Integration benötigt.
• Für eine Externe-Client-App ist die Callback URL auf die URL für die Region Ihrer Organisation eingestellt.
• Ein Salesforce-Benutzer ist als Run As-Benutzer (oder Ausführungsbenutzer) der App zugewiesen.

Salesforce Org auf OAuth 2.0 umstellen

Nehmen Sie die Änderung zuerst in einer Nicht-Produktionsumgebung vor und migrieren Sie dann das validierte Projekt.

1. Notieren Sie sich die vorhandenen Werte Benutzername und Sicherheitstoken des Salesforce Org. Die Beibehaltung dieser Werte ermöglicht es Ihnen, die Standardauthentifizierung wiederherzustellen, wenn Sie vor Abschluss der Validierung einen Rollback durchführen müssen.

2. Öffnen Sie in Design Studio den vorhandenen Salesforce Org.

3. Aktivieren Sie das Kontrollkästchen OAuth 2.0-Clientanmeldedaten auswählen, um die OAuth 2.0-Clientanmeldedatenfelder zu aktivieren.

   

4. Geben Sie die Instance-URL, die Client-ID und das Clientgeheimnis ein, die Sie von Salesforce gesammelt haben. Jedes dieser Felder unterstützt Projektvariablen, sodass dasselbe Projekt in jeder Umgebung unterschiedliche Anmeldedaten verwenden kann.

5. Klicken Sie auf Salesforce-Anmeldung testen und bestätigen Sie, dass Sie eine Erfolgsmeldung erhalten. Wenn die Anmeldung fehlschlägt, enthält die Meldung Informationen zur Behebung des Problems.

Änderung überprüfen

Ein erfolgreicher Anmeldetest bestätigt nur, dass die Anmeldedaten gültig sind. Führen Sie die Operationen aus, um zu bestätigen, dass die Berechtigungen des Run As-Benutzers ausreichend sind.

1. Verwenden Sie Actions > Deploy (siehe Menü „Actions" in Hauptmenüs), um das Projekt in einer Nicht-Produktionsumgebung bereitstellen](/de/management-console/environments/).

2. Führen Sie jede Operation aus, die den Salesforce Org verwendet, einschließlich aller Operationen, die darauf verweisende Skripte ausführen. Siehe Operation testen.

3. Überprüfen Sie das Operationsprotokoll und bestätigen Sie, dass jede Operation erfolgreich war, indem Sie die Datensatzzahlen mit einem Lauf vor der Änderung vergleichen. Ein Erfolg mit weniger Datensätzen als erwartet deutet normalerweise darauf hin, dass der Run As-Benutzer keinen Lesezugriff auf einige Datensätze, Objekte oder Felder hat. Siehe Operationsprotokoll überprüfen.

4. Überprüfen Sie geschriebene Datensätze in Salesforce stichprobenartig, um zu bestätigen, dass Feldwerte wie erwartet gefüllt wurden.

5. (Optional) Bestätigen Sie, dass noch nichts die SOAP-API login() verwendet. Salesforce stellt einen Testlauf bereit, der alle login()-Aufrufe an einen Org blockiert und dieselbe Antwort wie bei der Einstellung zurückgibt. Öffnen Sie in Salesforce Setup unter Release Updates das Update SOAP API login() Retirement, wählen Sie View Update aus und wählen Sie dann Enable Test Run. Wählen Sie Disable Test Run, um login() wiederherzustellen.

   Caution

   Ein Testlauf gilt für den gesamten Salesforce Org, daher schlagen alle Integrationen fehl, die noch login() verwenden, während dieser aktiviert ist. Führen Sie ihn in einer Sandbox aus, nachdem Sie jedes Design Studio-Projekt geändert haben, das sich bei diesem Org authentifiziert.

6. (Optional, nur private Agenten) Um die genaue Salesforce-API-Version zu bestätigen, die eine Anfrage verwendet hat, prüfen Sie das tomcat/logs/catalina.out-Protokoll des Agenten unmittelbar nach dem Klicken auf Test Salesforce Login oder nach dem Ausführen eines Vorgangs. Das Protokoll enthält die Anfrage-URL, z. B. Service request URL: https://login.salesforce.com/services/Soap/u/64.0, wobei die Zahl nach /u/ die aufgerufene API-Version ist.

Änderung in die Produktion übernehmen

1. Nach der Validierung nutzen Sie File > Migrate Project (siehe File menu unter Main menus), um das Projekt in Ihre Produktionsumgebung zu migrieren.

2. Falls die Produktionsumgebung separate Salesforce-App-Anmeldedaten nutzt, wiederholen Sie die Schritte in Change the Salesforce org to OAuth 2.0 für die Salesforce-Organisation dieser Umgebung.

3. Nutzen Sie Actions > Deploy, um das Projekt in der Produktionsumgebung bereitzustellen, und bestätigen Sie, dass die ersten geplanten oder ausgelösten Ausführungen erfolgreich abgeschlossen werden.

4. Nachdem alle Umgebungen validiert sind, können Sie die Eingabeaufforderung akzeptieren, um das Projekt auf eine neuere Salesforce-API-Version zu aktualisieren, und stilllegen Sie das Salesforce-Konto, das zuvor für die Standardauthentifizierung verwendet wurde, gemäß den Praktiken Ihrer Organisation.

Benötigen Sie Hilfe?

Für eine koordinierte Änderung oder Unterstützung bei ihrer Planung kontaktieren Sie Jitterbit support oder Jitterbit Professional Services.