Salesforce per SQL - Vorbereitungen

Letztes Update: 22.06.2026

Einleitung

Dieser Artikel beschreibt den Zugriff auf ein Salesforce-CRM-System per SQL. Der Zugriff erfolgt mit Lobster Integration (Hier speziell in Version > 4.6.11) über eine JDBC-Schnittstelle.

 HINWEIS Im Artikel wird nicht beschrieben, wie der Zugriff auf die von Salesforce zur Verfügung gestellte HTTP/SOAP-Schnittstelle funktioniert.

Für die SQL-Zugriffe ist der Erwerb einer kostenpflichtigen Zusatz-Lizenz notwendig. Ebenso muss ein spezieller JDBC-Treiber der Firma CDATA, welcher im Rahmen der Lizenz zur Verfügung gestellt wird, dafür installiert sein.

 WARNUNG  Dieser JDBC-Treiber wandelt die von Lobster Integration kommenden SQL-Statements in Webservice-Aufrufe auf die Salesforce HTTP/SOAP-Schnittstelle um. Halten Sie die SQL-Statements einfach (z. B. keine komplizierten JOIN-Bedingungen). Je komplexer die Statements, desto höher ist die Wahrscheinlichkeit, dass die Umwandlung in Webservice-Aufrufe nicht mehr zu 100 % funktioniert.

Salesforce-Anbindung

Um mit Lobster Integration per SQL auf Salesforce zugreifen zu können, sind zwei Schritte notwendig:

1) JDBC-Treiber

Wenn die Lizenz aktiviert wurde, dann wird der JDBC-Treiber automatisch in Ihrem Update-Center angezeigt.

Nach dem Herunterladen des Treibers muss der Integration Server einmal neu gestartet werden. Danach kann mit dem nächsten Schritt fortgefahren werden.

Linux:

Integration Server neu starten.

Windows:

Hier muss einmal nach folgender Reihenfolge vorgegangen werden:

• Integration Server beenden

• Skript ./bin/hub.bat starten

• Skript ./bin/hub.bat mit Strg+c beenden

• Integration Server starten

Zur Vorgehensweise siehe auch: Lobster Application Wrapper für neuere Systeme.

 HINWEIS Es ist empfehlenswert, regelmäßig in das Update-Center zu schauen, um Aktualisierungen abzurufen und durchzuführen.

2) Hinzufügen von Datenbank-Aliasen

Es sind zwei Aliase notwendig, weil der JDBC-Treiber nicht über einen Alias Bulk- und normale Operationen ausführen kann.

Der Bulk-Alias wird beim Zugriff auf Salesforce in Phase 5 (SQLBulkUnit) verwendet. Der Nicht-Bulk-Alias für alle anderen Zugriffe (Phasen 1,3 und 4). Durch diese Trennung kann verhindert werden, dass große Bulkoperationen durch lange laufende Select-Statements blockiert werden.

Die Aliase werden erstellt unter Konfiguration > Datenbanken/Konnektoren. Nachfolgend finden Sie zwei Vorlagen, die Sie importieren können. Ihre Werte können Sie dann anpassen. Alternativ kann ein Alias auch über die Vorlagen > Vorlagen(Presets) > Salesforce angelegt werden.

a) Bulk Alias

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Lobster//DTD Configure 1.0//EN" "http://www.lobster.de/dtd/configure_1_1.dtd">
	<Configure class="com.ebd.hub.services.database.ConnectionService">
	<Call name="initPool">
		<Arg>
			<New class="com.ebd.hub.services.database.DatabaseSettings">
				<Set name="alias">salesforce</Set>
				<Set name="allowGrowing">True</Set>
				<Set name="database">jdbc:lobster:sforce2:</Set>
				<Set name="user">(your salesforce login username)</Set>
				<Set name="password">(your salesforce login password)</Set>
				<Call name="addNamedProperty">
					<Arg>Security Token</Arg>
					<Arg>(your security token)</Arg>
				</Call>
				<Call name="addNamedProperty">
					<Arg>Use Bulk API</Arg>
					<Arg>true</Arg>
				</Call>
				<Call name="addNamedProperty">
					<Arg>Bulk API Version</Arg>
					<Arg>v2</Arg>
				</Call>
 				<Call name="addNamedProperty">
					<Arg>Logfile</Arg>
					<Arg>"C:\Lobster\IS\logs\salesforce_jdbc\sf.log"</Arg>
				</Call> 
 				<Call name="addNamedProperty">
					<Arg>Verbosity</Arg>
					<Arg>0</Arg>
				</Call> 
  				<Call name="addNamedProperty">
					<Arg>Max Log File Size</Arg>
					<Arg>10MB</Arg>
				</Call>  
   	 	        <Set name="catalogName"></Set>
				<Set name="driver">de.lobster.jdbc.jdbc.sforce.SForceDriver</Set>
				<Set name="minSize">0</Set>
				<Set name="maxSize">0</Set>
				<Set name="idleTime">300000</Set>
				<Set name="sqlCommand"></Set>
				<Set name="rollback">True</Set>
				<Set name="caching">True</Set>
			</New>
		</Arg>
	</Call>
</Configure>

b) Nicht-Bulk-Alias

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Lobster//DTD Configure 1.0//EN" "http://www.lobster.de/dtd/configure_1_1.dtd">
    <Configure class="com.ebd.hub.services.database.ConnectionService">
		<Call name="initPool">
		    <Arg>
		        <New class="com.ebd.hub.services.database.DatabaseSettings">
		            <Set name="alias">salesforce_nobulk</Set>
		            <Set name="allowGrowing">True</Set>
		            <Set name="database">jdbc:lobster:sforce2:Logfile="C:\Lobster\IS\logs\salesforce_jdbc\sf.log";Verbosity="3";Max Log File Size="10MB"</Set>
		            <Set name="user">(your salesforce login username)</Set>
		            <Set name="password">(your salesforce login password)</Set>
		            <Call name="addNamedProperty">
		                <Arg>Security Token</Arg>
		                <Arg>(your security token)</Arg>
		            </Call>
		            <Call name="addNamedProperty">
		                <Arg>Use Bulk API</Arg>
		                <Arg>false</Arg>
		            </Call>
		            <Call name="addNamedProperty">
		                <Arg>Use Connection Pooling</Arg>
		                <Arg>true</Arg>
		            </Call>
		            <Set name="catalogName"></Set>
		            <Set name="driver">de.lobster.jdbc.jdbc.sforce.SForceDriver</Set>
		            <Set name="minSize">0</Set>
		            <Set name="maxSize">0</Set>
		            <Set name="idleTime">300000</Set>
		            <Set name="sqlCommand"></Set>
		            <Set name="rollback">True</Set>
		            <Set name="caching">True</Set>
		        </New>
		    </Arg>
		</Call>
</Configure>

c) Zugriff auf andere Salesforce-Instanzen

Produktive Instanzen werden über login.salesforce.com erreicht, Sandbox-Instanzen (= vom Produktivsystem geklontes Testsystem) über test.salesforce.com.

Um auf ein Testsystem (Sandbox) zuzugreifen, ergänzen Sie im Alias folgendes JDBC-Property. Der Default für Use Sandbox ist false:

<Call name="addNamedProperty">
    <Arg>Use Sandbox</Arg>
    <Arg>true</Arg>
</Call>

Es ist auch möglich, sich bei Salesforce eigene Subdomains zu kaufen, z. B. firmenname.my.salesforce.com

Um über diese URL auf die Salesforce-Instanz zugreifen zu können, muss der Parameter LoginURL ergänzt werden. Das gilt für die Sandbox und das Produktivsystem. Für die Sandbox muss zusätzlich der Parameter Use Sandbox auf true stehen.

<Call name="addNamedProperty">
    <Arg>LoginURL</Arg>
    <Arg>https://<mysubdomain>.my.salesforce.com/services/Soap/c/60.0</Arg>
</Call>

 HINWEIS 60.0 ist aktuell die Salesforce-API-Version, die vom JDBC-Treiber unterstützt wird (Stand: 04/2024).

d) Proxy-Konfiguration

Bitte alle Parameter per addNamedProperty in den Alias eintragen.

Weitere Details in der Treiber-Doku: https://cdn.cdata.com/help/RFK/jdbc/Connection.htm

OAuth2+PKCE konfigurieren (optional, falls erforderlich/gewünscht)

 HINWEIS OAuth2+PKCE benötigt den CData-Salesforce-Treiber ab Version 25.0.9595.0. Diese Voraussetzung gilt nur für den Treiber. Sie ist unabhängig von der Lobster Data Platform und der _data-Version.

Voraussetzungen für die Verwendung von OAuth2+PKCE in Verbindung mit dem Salesforce-JDBC-Treiber:

a) Es muss auf Salesforce-Seite eine entsprechende App erstellt werden.

b) Die Werte für Client ID (Consumer Key) und Client Secret (Consumer Secret) müssen bekannt sein.

Bei Fragen hierzu ziehen Sie bitte die offizielle Salesforce-Dokumentation zurate oder wenden sich an Ihren Salesforce-Berater.

Es sind verschiedene Schritte notwendig, um den Prozess zum automatischen Erneuern des Token zu ermöglichen. Auf jeden Fall wird eine Lobster Integration benötigt, die bereits Zugriff auf Salesforce hat, zunächst mit User/Passwort-Authentifizierung, wie es zuvor in diesem Dokument beschrieben wurde.

Über die Admin-Konsole oder SQL-Konsole in den Plug-ins müssen verschiedene Prozeduren ausgeführt werden.

Im Folgenden wird nun Schritt für Schritt das Holen des Access-Tokens und des Refresh-Tokens beschrieben.

 HINWEIS Es darf keiner der Schritte ausgelassen werden, da diese aufeinander aufbauen! Das Holen vom ersten Access und Refresh Token kann über einen Alias gemacht werden. Aber alle Aliase müssen am Schluss für OAuth2 konfiguriert sein.

Schritt 1: Salesforce-Alias vorbereiten

Im Salesforce-Alias müssen unter JDBC Properties nachfolgende Properties ergänzt werden. Wichtig ist, dass die CallbackURL in Salesforce und in Lobster Integration http://localhost:33333 lautet. Dies ist die Standard-Callback-URL für Headless Machines.

Alle Platzhalter in eckigen Klammern müssen noch mit den realen Werten bestückt werden.

<Call name="addNamedProperty">
	<Arg>AuthScheme</Arg>
	<Arg>OAuth2PKCE</Arg>
</Call>
<Call name="addNamedProperty">
    <Arg>OAuthClientId</Arg>
    <Arg>[Client Id(Consumer Key)]</Arg>
</Call>                
<Call name="addNamedProperty">
    <Arg>OAuthClientSecret</Arg>
    <Arg>[Client Secret(Consumer Secret)]</Arg>
</Call>
<Call name="addNamedProperty">
    <Arg>CallbackURL</Arg>
    <Arg>http://localhost:33333</Arg>
</Call>
<Call name="addNamedProperty">
    <Arg>InitiateOAuth</Arg>
    <Arg>OFF</Arg>
</Call>
<Call name="addNamedProperty">
    <Arg>OAuthSettingsLocation</Arg>
    <Arg>[<your_Lobster_home_directory>]/conf/Salesforce/OAuthSettings.txt</Arg>
</Call>
<Call name="addNamedProperty">
    <Arg>LoginURL</Arg>
    <Arg>[LoginURL]</Arg>
</Call>
<Call name="addNamedProperty">
    <Arg>OAuthAccessTokenURL</Arg>
    <Arg>[OAuthAccessTokenURL]</Arg>
</Call>

Schritt 2: Authorization URL und PKCE-Verifier holen

Als Erstes wird die Authorization URL von Salesforce geholt. Öffnen Sie dazu die Admin-Konsole und navigieren Sie zu Tools > SQL Monitor. Im Verlauf wird immer der SQL Monitor erwähnt, alternativ kann immer auch unter Plugins die SQL Konsole verwendet werden.

Als Datenbank-Alias wird der Salesforce-Alias verwendet, der im Schritt 1 angepasst wurde.

Dann muss der folgende Befehl ausgeführt werden:

execute GetOAuthAuthorizationUrl

Als Ergebnis werden die Authorization URL und der PKCE-Verifier zurückgegeben.

Tragen Sie den PKCE-Verifier als Property PKCEVerifier in den Salesforce-Alias ein. Der Treiber benötigt diesen Wert in Schritt 3.

<Call name="addNamedProperty">
    <Arg>PKCEVerifier</Arg>
    <Arg>[PKCE-Verifier]</Arg>
</Call>

Beispiel:

 HINWEIS Die Authorization URL ist teilweise URL-codiert. Wandeln Sie das %3D am Ende des state-Werts zurück in =. Im Beispiel wird %3D%3D zu ==. Den codierten Wert redirect_uri ändern Sie nicht.

Rufen Sie die Authorization URL anschließend in einem Browser auf. Der Browser muss sich dafür nicht auf dem Integration Server befinden.

Die Antwort vom Server auf den Request ist ein Redirect. Es ist möglich, dass im Browser ein Fehler angezeigt wird, da die URL mit localhost:33333 nicht existiert, das ist aber korrekt so.

Die Redirect URL, die in der Adressleiste vom Browser erscheint, kann z. B. so aussehen:

Der Wert des Parameters code ist der Authorization Code. Dieser wird für den nächsten Schritt benötigt. Im Beispiel ist es der Wert YVByeDR5X0t6c2NXenl5easdfasdfkRmRyakxtNlNScEJNR2hFbG8wNTlJb2t2c1IzTVJ1UHU0Skg3aXdfYjMzYkRiM2NrZ1FZbWc9PQ==

Schritt 3: Access Token und Refresh Token holen

Mit dem Authorization Code aus Schritt 2 muss im SQL Monitor nun folgende Prozedur aufgerufen werden:

execute GetOAuthAccessToken Verifier='<Authorization Code>'

Diese Prozedur gibt eine Tabelle mit einem Datensatz zurück. Benötigt werden aus diesem Datensatz die Werte für Access Token und Refresh Token.

Schritt 4: Token im Alias hinterlegen

Nun muss der Salesforce-Alias unter Konfiguration > Datenbanken/Konnektoren angepasst werden. Es muss einmal der Access Token und Refresh Token aus Schritt 3 ergänzt werden. Ebenso muss der Wert für Parameter InitiateOAuth in REFRESH umbenannt werden.

<Call name="addNamedProperty">
    <Arg>InitiateOAuth</Arg>
    <Arg>REFRESH</Arg>
</Call>    
<Call name="addNamedProperty">
    <Arg>OAuthAccessToken</Arg>
    <Arg>[Access Token]</Arg>
</Call>
<Call name="addNamedProperty">
    <Arg>OAuthRefreshToken</Arg>
    <Arg>[Refresh Token]</Arg>
</Call> 

Logging

Aktivierung

Um das Logging des JDBC-Treibers zu aktivieren, werden am Alias des JDBC-Treibers zusätzliche Parameter angegeben:

<Call name="addNamedProperty">
    <Arg>Logfile</Arg>
    <Arg>"C:\Lobster\IS\logs\salesforce_jdbc\sf.log"</Arg>
</Call>    
<Call name="addNamedProperty">
    <Arg>Max Log File Size</Arg>
    <Arg>"10MB"</Arg>
</Call> 
<Call name="addNamedProperty">
    <Arg>Verbosity</Arg>
    <Arg>0</Arg>
</Call> 

Im Logfile steht im Klartext, was zwischen JDBC-Treiber und Salesforce ausgetauscht wurde (je nach Verbosity in unterschiedlichem Detaillierungsgrad).

Hier kann sowohl erzeugtes SQL als auch die zwischen JDBC-Treiber und Salesforce übertragenen HTTP-Requests/Responses einsehen.

In der Regel ist Verbosity = 3 auf einem Test-System ausreichend zur Fehlersuche. Deaktivieren Sie das Logging, sobald Sie es nicht mehr benötigen.

 WARNUNG  Auf einem Produktivsystem sollte das Logging nur mit äußerster Vorsicht aktiviert werden, weil hier gegebenenfalls schnell sehr große Log-Dateien entstehen können!

Das Logfile entsteht nicht gleich beim Start des Integration Servers, sondern erst beim ersten Zugriff auf den jeweiligen Datenbank-Alias.

Logfile Rollover

Ist die Max Log File Size erreicht, findet ein Rollover statt. Die aktuelle Logdatei erhält einen Zeitstempel yyyyMMddHH-mmss im Dateinamen, und eine neue Logdatei (mit dem in Logfile angegebenen Namen) wird angelegt. Das weitere Logging findet dann in dieser neuen Datei statt.

Technische Besonderheiten in Salesforce

Nachfolgend werden ein paar technische Besonderheiten beschrieben, die für die Verwendung der JDBC-Schnittstelle zu Salesforce relevant sind.

Metadaten-Cache

Beim ersten Zugriff auf ein Salesforce-Objekt werden zunächst die Metadaten des Objekts angefordert und in einen internen Cache (MetaCache) gelegt.

Dies erhöht zwar einerseits die Geschwindigkeit für zukünftige Zugriffe auf dieses Objekt, hat aber andererseits zur Folge, dass bei Änderungen am Objekt (z. B. Hinzufügen oder Entfernen eines Feldes am Salesforce Objekt) ein Neuaufbau des Caches erfolgen muss.

Um den Cache neu aufzubauen, ist es notwendig, den Integration Server einmal komplett neu zu starten.

Salesforce Bulk API

Bulk Jobs bieten den Vorteil, dass große Datenmengen wesentlich schneller per Insert oder Update verarbeitet werden können.

In Salesforce gibt es Limitierungen (abhängig von der lizenzierten Salesforce Edition) bezüglich Verbindungen pro Tag und Anzahl Batches pro Tag, deshalb ist es sinnvoll, große Datenmengen als Bulk zu übertragen.

 WARNUNG  Bulk Jobs in Salesforce entstehen nur, wenn der verwendete Datenbank-Alias use Bulk API = true gesetzt hat und in Phase 5 die SQLBulkUnit verwendet wird.

Es entsteht kein Bulk Job in Salesforce, wenn der verwendete Datenbank-Alias zwar use Bulk API= true gesetzt hat, aber das Insert/Update durch Phase 3 (Funktion) oder Phase 4 (Datenbankknoten) erzeugt wurde.

Wird die SQLBulkUnit mit einem Datenbank-Alias verwendet, der use Bulk API= false gesetzt hat, gibt es eine Fehlermeldung in Phase 5: Got no salesforce job-ID.

In der Salesforce-GUI öffnen Sie Setup > Environments > Jobs > Bulk Data Load Jobs. Dort sehen Sie alle laufenden und fertiggestellten Bulk Jobs.

Ein Bulk Job besteht aus 1-n Batches, in jedem Batch können 1 - max. 9999 (Einstellung SqlBulkUnit - Max. sql statements in batch) Records enthalten sein.

Pro Datenbank-Knoten in der Lobster Data Platform entsteht ein Salesforce Bulk Job (auch bei mehreren Datenblättern/Records entsteht nur ein Bulk Job pro Knoten - die Daten aus den einzelnen Datenblättern werden zusammengefasst).

Die Salesforce Bulk Jobs werden seriell von Lobster Integration abgearbeitet.

Die einzelnen Batches eines Bulk Jobs werden in Salesforce parallel abgearbeitet.

 WARNUNG  delete before insert  kann mit der SQLBulkUnit im Zusammenhang mit Salesforce nicht verwendet werden!

Objekte/Felder

In Salesforce gibt es Standardobjekte (Type = Standard Object, wird von Salesforce so zur Verfügung gestellt, wie z. B. Account) und selbst angelegte Objekte (Type = Custom Object). Jedes Objekt hat ein Label (zur Anzeige in der GUI), sowie einen API-Namen (mit diesem kann über die API auf das Objekt zugegriffen werden).

Am API-Namen kann erkannt werden, ob es sich um ein Custom Object handelt, in dem Fall endet dieser mit __c.

Ein Objekt hat 1-n Felder. Felder haben ein Field Label (zur Anzeige in der GUI) sowie einen Field Name (für den API-Zugriff). Handelt es sich um ein customized Field, so endet der Field Name wiederum mit __c.

Über den Object Manager (Setup/Object Manager) in der Salesforce-GUI können Details zum Aufbau der einzelnen Objekte und deren Felder angezeigt werden.

Standardobjekte können nicht gelöscht, jedoch neue Felder/Objekte hinzugefügt werden. Standardfelder können nicht gelöscht oder verändert werden.

Objekt-Beziehungen

In Salesforce können zwischen den Objekten Beziehungen gesetzt werden. Es gibt zwei Haupttypen von Beziehungen: Lookup- und Master-Detail. Wie diese verwendet werden können, ist in Abschnitt Salesforce per SQL - Tutorial beschrieben.

Lookup-Beziehung (Nachschlage-Beziehung)

Lookup-Beziehungen werden normalerweise verwendet, wenn Objekte miteinander in Beziehung stehen.

Beispiel aus den Salesforce-Standardobjekten: Account und Contact. Ein Contact ist ein relativ lockeres Element, das einem Account zugeordnet sein kann, aber auch unabhängig für sich allein existieren kann.

Um ein Contact-Objekt an ein Account-Objekt zu hängen, muss in Contact das Feld AccountId (welches vom Datentyp Lookup(Account) ist) mit der internen ID eines Account-Objekts gefüllt sein. Ist dieses Feld mit der internen ID des Accounts gefüllt, erscheint auf der Salesforce-Oberfläche auch ein Link am Kontakt zum Account.

Master-Detail-Beziehung

Bei einer Master-Detail-Beziehung ist das Detail-Objekt nicht eigenständig. Es ist abhängig vom Master. Sobald ein Datensatz aus dem Master-Objekt gelöscht wird, werden auch alle dazugehörigen Detaildatensätze gelöscht. Bei der Erstellung von Master-Detail-Beziehungen wird das Beziehungsfeld stets im Detailobjekt erstellt.

Ein Beispiel hierfür aus den Salesforce-Standardobjekten kann hier leider nicht angegeben werden, da ein Standardobjekt niemals ein Detail-Objekt sein kann.