SQL-Integration von Exchange und Salesforce

Aufgrund des Erfolgs unseres ersten Fachartikels, den Sie hier finden hier beschlossen wir, weiterzumachen. Dieses Mal werden wir uns ansehen, wie eine Integration zwischen Exchange und Salesforce auf einfachste Weise erreicht werden kann. Wir werden SQL-Abfragen verwenden.

Für die Integration verwenden wir CB Linked Server for Enterprise Applications. Fragen Sie uns nach einer kostenlosen Testversion des Produkts.

Das hier erforderliche Integrationsszenario ist die Synchronisierung zwischen einer lokalen Datenbankkontakttabelle, Exchange 365-Kontakten und SalesForce-Kontakten und eine sofortige Replikation von der lokalen Datenbanktabelle auf diese beiden Zielsysteme. Dies kann nützlich sein, um ein Offline-Backup von Kontakten zu erstellen, ein Data Warehouse zu erstellen oder aus anderen Gründen.

Der erste Schritt besteht darin, sicherzustellen, dass Sie eine Verbindung zum Zielsystem (Exchange & SalesForce in unserem Szenario) herstellen können; am einfachsten geht das über den CB Query Analyzer. Hier habe ich meinen ConnectBridge-Server bereits über das Verwaltungstool für die Verbindung zu MS Exchange 365 und zu SalesForce konfiguriert, indem ich die erforderlichen Gruppen und Benutzer erstellt habe. Ich habe einen Benutzernamen namens "martin" mit Passwort "1234”. Dieser Benutzer hat das Recht, eine Verbindung zu Exchange 365 und SalesForce herzustellen. Nun werde ich vom Query Analyzer aus 2 Verbindungen zu jedem Zielsystem erstellen und sicherstellen, dass ich erfolgreich eine Verbindung herstellen kann.

Wie oben gezeigt, haben wir eine erfolgreiche Konfiguration und Verbindung zu beiden Zielsystemen. Jetzt können wir unsere Aussagen testen

Auf meinem Exchange-Konto habe ich 3 Kontakte wie unten dargestellt

Nun werden wir die 4 Grundoperationen SELECT, INSERT, UPDATE & DELETE testen

1. Auswahl der Kontakte

Die Ausführung der nachstehenden Erklärung sollte uns die in Abbildung 5 dargestellten 3 Kontakte liefern.

SELECT [GivenName],[SurName],[Email1EmailAddress] FROM [Contact];

2. Einfügen eines Kontakts

Durch Ausführen der folgenden Anweisung sollte ein neuer Kontakt, wie in Abbildung 6 dargestellt, eingefügt werden

INSERT INTO Contact([GivenName],[SurName],[Email1EmailAddress]) VALUES ('Peter','K.', 'peter@gmail.com');

3. Aktualisieren eines Kontakts

Die Ausführung der untenstehenden Erklärung sollte den Nachnamen des Kontaktes, den wir früher eingefügt haben, aktualisieren, wie in Abbildung 7 gezeigt

UPDATE Contact SET [SurName] = 'Keys' WHERE [Email1EmailAddress] LIKE 'peter@gmail.com';

4. Löschen eines Kontakts

Die Ausführung der folgenden Anweisung sollte den neu eingefügten Kontakt löschen, wie in Abbildung 8 dargestellt

DELETE FROM Contact WHERE [Email1EmailAddress] LIKE 'peter@gmail.com';

In meinem SalesForce-Konto verfüge ich über 17 Kontakte, wie unten dargestellt

Jetzt werden wir die gleichen 4 Grundoperationen SELECT, INSERT, UPDATE & DELETE testen.

1. Auswahl der Kontakte

Die Ausführung der nachstehenden Erklärung sollte uns die in Abbildung 10 dargestellten 17 Kontakte liefern.

SELECT [FirstName],[LastName],[Email] FROM [Contact];

2. Einfügen eines Kontakts

Durch Ausführen der folgenden Anweisung sollte ein neuer Kontakt, wie in Abbildung 11 dargestellt, eingefügt werden

INSERT INTO Contact([Firstname],[LastName],[Email]) VALUES ('Peter','K.', 'peter@gmail.com');

3. Aktualisieren eines Kontakts

Die Ausführung der untenstehenden Erklärung sollte den Nachnamen des Kontaktes, den wir früher eingefügt haben, aktualisieren, wie in Abbildung 12 gezeigt

UPDATE Contact SET [LastName] = 'Keys' WHERE [Email] = 'peter@gmail.com';

4. Löschen eines Kontakts

Die Ausführung der folgenden Anweisung sollte den neu eingefügten Kontakt löschen, wie in Abbildung 13 dargestellt

DELETE FROM Contact WHERE [Email] = 'peter@gmail.com';

Jetzt wissen wir, dass wir in der Lage sind, Kontakte in Exchange & SalesForce auszuwählen, zu aktualisieren, einzufügen und zu löschen. Was wir jetzt tun müssen, ist, die Verbindungszeichenfolge aus Query Analyzer und unsere getesteten Anweisungen zu kopieren, um sie später in unserer MS SQL Server-Lösung zu verwenden.

Um die Verbindung aus dem Abfrageanalysator zu kopieren, brauchen wir nur mit der rechten Maustaste auf die Verbindung zu klicken, auf Bearbeiten zu klicken und zur Registerkarte Erweitert zu gehen und den Text von dort aus zu kopieren, wie unten in Abbildung 14 dargestellt.

Hier sind meine Verbindungszeichenfolgen für beide Zielsysteme.

Exchange

Driver={Media Gateway ODBC Driver};impl='CORBA';host='localhost';port='8087';acc='ACC_EXCH365_CU7';uid='martin';pwd='1234'

SalesForce

Driver={Media Gateway ODBC Driver};IMPL=CORBA;HOST='localhost';PORT='8087';ACC='ACC_SALF_CBD';UID='martin';PWD='1234'

Jetzt sind wir bereit, MS SQL Server zu öffnen und mit der Implementierung unserer SQL Server-Integrationslösung zu beginnen.

Um mit externen Datenquellen über die Funktion SQL Server Linked Server arbeiten zu können, müssen wir die folgenden Konfigurationen vornehmen

1. Starten Sie Microsoft SQL Server Management Studio und melden Sie sich entweder mit der Windows-Authentifizierung oder mit Benutzername und Kennwort an, wie unten in Abbildung 15 dargestellt

2. Navigieren Sie zu Sever-Objekte -> Verknüpfte Server -> Anbieter -> MSDASQL durch Erweitern der entsprechenden Knoten, wie oben in Abbildung 16 dargestellt. Klicken Sie mit der rechten Maustaste auf MSDASQL - Microsoft Data Access SQL - und wählen Sie Eigenschaften um den Dialog in Abbildung 17 zu zeigen

3. Wir müssen sicherstellen, dass die folgenden Einstellungen/Optionen überprüft werden:

a. Nur Ebene Null: Aus Sicherheitsgründen müssen wir sicherstellen, dass nur OLE DB-Provider unterstützt werden, die mit der OLE DB-Schnittstelle der Ebene 0 konform sind.

b. In-Prozess zulassen: Die Datenanbieter - "externe Datenquellen" - sollen als prozessinterne Server - "im selben Prozess wie MS SQL Server" - instanziiert werden können. Dies ist notwendig, um die Weitergabe von Authentifizierungsinformationen zwischen MS SQL Server und dem Provider zu vermeiden und um mit Datentypen wie (varchar(max), nvarchar(max), varbinary(max), text, ntext oder image) arbeiten zu können. Ohne die Aktivierung dieser Option können wir zum Beispiel keine Daten vom Typ Bild von Exchange abrufen und in unsere MS SQL Server-Datenbank einfügen.

4. Jetzt müssen wir MS SQL Server in die Lage versetzen, eine Verbindung zu externen Anbietern herzustellen und Abfragen auszuführen, um Daten von externen Anbietern abzufragen, die OLEDB verwenden - nennen wir sie "Externe OLEDB-Datenquellen”. Wir werden das in 3 Schritten tun:

a. Wir müssen ein neues Abfragefenster öffnen, indem wir auf die Schaltfläche Neue Abfrage klicken, wie in Abbildung 18 unten dargestellt. Es spielt keine Rolle, welche Datenbank aktiv ist, denn was wir tun werden, wirkt sich auf die gesamte MS SQL Server-Installation und damit auf jede einzelne Datenbank aus. Wie unten gezeigt, habe ich "master" als aktive/Zieldatenbank

b. Wir müssen den MS SQL Server neu konfigurieren, damit wir seine erweiterten Optionen ändern/konfigurieren können. Dazu führen wir eine gespeicherte Prozedur namens "sp_configure" aus - es handelt sich um eine vorinstallierte gespeicherte Systemprozedur - und wir werden speziell "erweiterte Optionen anzeigen" - indem wir diese Option auf 1 setzen. Dazu geben wir "exec sp_configure 'show advanced options', 1; reconfigure" ein und drücken F5 zur Ausführung. Wenn alles klappt, sollten Sie eine Meldung ähnlich der in Abbildung 19 unten erhalten

c. Jetzt müssen wir MS SQL Server erlauben, diese "Externe OLEDB-Datenquellen" mit etwas namens "Verteilte Ad-hoc-Abfragen". Standardmäßig lässt MS SQL Server die "Ad Hoc Distributed Queries" nicht zu. Daher müssen wir diese erweiterte Option neu konfigurieren - deshalb haben wir den vorherigen Schritt durchgeführt - indem wir die gespeicherte Prozedur "sp_configure" mit der Einstellung "Ad Hoc Distributed Queries" und dem Wert 1 ausführen, um sie zu aktivieren. Wenn alles richtig läuft, sollten Sie nach der Ausführung von "exec sp_configure 'Ad Hoc Distributed Queries', 1; reconfigure" eine Meldung ähnlich der in Abbildung 20 unten erhalten

Jetzt können wir so viele Linked Server hinzufügen, wie wir wollen, da unser MS SQL Server richtig konfiguriert ist, um dies zu ermöglichen.

1. navigieren Sie zu Sever Objects -> Verknüpfte Server. Rechtsklick auf Verknüpfte Server und wählen Sie Neuer verlinkter Server wie in der folgenden Abbildung 21 dargestellt

2. Im neuen Dialogfeld Verknüpfter Server, wie in Abbildung 22 unten dargestellt, müssen Sie Folgendes angeben:

a. Name des verknüpften Servers: könnte jeder gültige Name sein, ich wähle Exchange365_CU7.

b. Anbietermuss "Microsoft OLE DB Providers for ODBC Drivers" sein, da ConnectBridge ODBC verwendet.

c. Anbieter-String: Hier fügen wir die Verbindungszeichenfolge ein, die wir zuvor aus Query Analyzer kopiert haben.

Jetzt müssen wir eine Beziehung zwischen dem Benutzer, der MS SQL Server verwendet/auf ihn zugreift, und dem Benutzer, der CB verwendet/auf ihn zugreift, herstellen. Der Benutzer, der MS SQL Server benutzt, wird Local Login genannt (in unserem Szenario "sa") und der Benutzer, der CB benutzt/auf CB zugreift, wird Remote User genannt (in unserem Szenario Martin mit login martin). Das ist es, was wir konfigurieren müssen, und dazu klicken wir auf "SicherheitRegisterkarte ", um den Dialog in Abbildung 23 unten anzuzeigen

4. Wenn das obige Dialogfeld angezeigt wird, klicken wir auf die Schaltfläche Hinzufügen und geben die lokale Anmeldung und den Remote-Benutzer wie vereinbart ein. Das habe ich hier in Abbildung 24 getan

5. Okay, ich weiß, dass Sie den Dialog schließen wollen, aber warten Sie! wir müssen noch einen Schritt weitergehen. Jetzt müssen wir zu "Server-Optionen" auf der linken Seite, um den Dialog in Abbildung 25 unten anzuzeigen und 2 Funktionen zu aktivieren

a. RPC: um ein bestimmtes Sicherheitsmerkmal zu aktivieren, das wir benötigen würden, wenn wir ein vererbtes Merkmal namens Entfernter Server - Machen Sie sich jetzt keine Sorgen - so dass eine Login-Validierung zwischen CB und MS SQL Server möglich ist

b. RPC-Ausgang: zu aktivieren "Entfernter Prozeduraufruf"Funktion, da wir es unseren gespeicherten Prozeduren ermöglichen müssen, aus der Ferne ausgeführt werden zu können.

6. Jetzt klicken wir okay und wir sind fertig! Ja! Wir haben MS SQL Server für die Verbindung mit Exchange konfiguriert. Jetzt können wir die Exchange-Plattform als Datenbank in MS SQL Server sehen, wir können eine Tabelle mit dem Namen Kontakte sehen, wir können eine Liste von Kontakten aus Exchange anzeigen, all dies, ohne auf die Exchange-Datenbank zuzugreifen, wie Sie in Abbildung 26 unten sehen konnten

Bevor wir unsere Integrationslösung entwickeln, müssen wir sicher sein, dass wir in der Lage sind, die Grunddatenmanipulation auf MS Exchange über unseren neu konfigurierten Linked Server durchzuführen.

1. Auswahl der Kontakte

Die Ausführung der untenstehenden Erklärung sollte uns die 3 Kontakte von MS Exchange liefern.

SELECT GivenName, SurName, Email1EmailAddress FROM EXCHANGE365_CU7...Contact;

Warum zum "..."? Weil es der Syntax SERVER.DATABASE.SCHEMA.TABLE folgt, und wie Sie in Abbildung 26 oben sehen konnten, ist unser Server Exchange365_CU7, unsere Datenbank ist "ohne Namen", unser Schema ist "ohne Namen" und unsere Tabelle ist schließlich "Kontakte".

2. Einfügen eines Kontakts

Durch Ausführen der untenstehenden Erklärung sollte ein neuer Kontakt eingefügt werden.

EXEC ('INTO Kontakt EINFÜGEN([Vorname], [Nachname], [E-Mail1EmailAdresse])
WERTE ("Peter", "K.", "peter@gmail.com");') BEI BÖRSEN365_CU7;

3. Aktualisieren eines Kontakts

Die Ausführung der untenstehenden Erklärung sollte den Nachnamen der Kontaktperson aktualisieren, den wir zuvor eingefügt haben

EXEC('UPDATE Kontakt SET [Nachname] = "Schlüssel" WHERE [Email1EmailAddress] LIKE
"peter@gmail.com";') BEI EXCHANGE365_CU7;

4. Löschen eines Kontakts

Die Ausführung der folgenden Anweisung sollte den neu eingefügten Kontakt löschen

AUSFÜHREN ('LÖSCHEN VON Kontakt WO [E-Mail1EmailAdresse] WIE
"peter@gmail.com";') BEI EXCHANGE365_CU7;

Wir werden die Schritte aus Abschnitt "4.2 Konfigurieren von MS Exchange Linked Server" befolgen, außer dass wir natürlich den Connection String für SalesForce verwenden werden. Nachdem Sie diese Schritte befolgt haben, sollte Ihr Linked Server, wie unten gezeigt, erfolgreich konfiguriert sein.

Wie zuvor auch bei MS Exchange Linked Server müssen wir sicherstellen, dass wir in der Lage sind, die grundlegenden Datenmanipulationsaufgaben über den SalesForce Linked Server durchzuführen.

Zur Verkürzung des Leitfadens werden in Abbildung 32 unten alle folgenden Aussagen getestet

1. Auswahl der Kontakte

Die Ausführung der untenstehenden Erklärung sollte uns die Kontakte von SalesForce liefern.

SELECT GivenName, SurName, Email1EmailAddress FROM EXCHANGE365_CU7...Contact;

2. Einfügen eines Kontakts

Durch Ausführen der untenstehenden Erklärung sollte ein neuer Kontakt eingefügt werden.

EXEC ('INTO Kontakt EINFÜGEN([Vorname], [Nachname], [E-Mail1EmailAdresse])
WERTE ("Peter", "K.", "peter@gmail.com");') BEI BÖRSEN365_CU7;

3. Aktualisieren eines Kontakts

Die Ausführung der untenstehenden Erklärung sollte den Nachnamen der Kontaktperson aktualisieren, den wir zuvor eingefügt haben

EXEC('UPDATE Kontakt SET [Nachname] = "Schlüssel" WHERE [Email1EmailAddress] LIKE
"peter@gmail.com";') BEI EXCHANGE365_CU7;

4. Löschen eines Kontakts

Die Ausführung der folgenden Anweisung sollte den neu eingefügten Kontakt löschen

AUSFÜHREN ('LÖSCHEN VON Kontakt WO [E-Mail1EmailAdresse] WIE
"peter@gmail.com";') BEI EXCHANGE365_CU7;

Von hier aus müssen wir eine tatsächliche lokale Datenbank auf unserem lokalen MS SQL Server haben. Wenn Sie bereits über eine solche Datenbank verfügen, können Sie diese verwenden, andernfalls müssen wir eine neue Datenbank erstellen. Ich habe eine Datenbank namens ConnectingSoftware mit 1 Tabelle namens LocalContacts erstellt. In dieser Tabelle gibt es nur einen Datensatz, wie unten in Abbildung 33 dargestellt.

Der erste Schritt in unserer Lösung besteht darin, die Änderungen in unserer lokalen Datenbanktabelle sowohl in SalesForce als auch in Exchange zu replizieren. wir werden dies per Tabellen-Trigger implementieren.

SQL-Skript für den Trigger ist unten dargestellt:

TRIGGER ERSTELLEN [dbo].[trgSyncKontakt]
ON [dbo]. [Lokale Kontakte]
NACH EINFÜGEN, AKTUALISIEREN, LÖSCHEN
AS
BEGINN
deklarieren @Operation varchar(50)
@Vorname nvarchar(max) deklarieren
@LastName nvarchar(max) deklarieren
deklarieren @Email varchar(255)
declare @Deleted_FirstName nvarchar(max)
deklarieren @Deleted_LastName nvarchar(max)
deklarieren Sie @Gelöschte_Email varchar(255)

WENN COLUMNS_UPDATED() > 0
BEGINN
-- wenn wir Spalten aktualisiert haben, dann haben wir entweder eine
Aufzeichnung
FALLS VORHANDEN (WÄHLEN SIE * VON GELÖSCHT)
BEGINN
-- wenn wir Werte gelöscht haben, dann war es eine Aktualisierungsoperation
SELECT @Vorname = eingefügt.Vorname, @Nachname =
eingefügt.Nachname, @Email = eingefügt.email,
@Deleted_FirstName = gelöscht.Vorname,
@Deleted_LastName = gelöscht.Nachname, @Deleted_Email =
gelöscht.E-Mail
FROM gelöscht, eingefügt
--Vertriebskraft
Ausführen ('UPDATE Kontakt SET Vorname = ?, Nachname = ?, E-Mail = ?
WHERE Vorname = ? und Nachname = ? und E-Mail = ?',
@Vorname, @Nachname, @E-Mail, @Gelöschter_Vorname,
@Deleted_LastName, @Deleted_Email) bei SALESFORCE_CBD;
-Austausch
EXEC ('UPDATE Contact SET Vorname = ?, Nachname = ?,
E-Mail1EmailAdresse = ? WHERE Vorname = ? und Nachname = ?
? und E-Mail1EmailAdresse = ?', @Vorname, @Nachname,
@E-Mail, @gelöschter_Vorname, @gelöschter_Nachname,
@Gelöschte_E-Mail) bei EXCHANGE365_CU7;
END
ELSE
BEGINN
-- wenn es kein Update-Vorgang war, dann war es Einfügen
SELECT @Vorname = Vorname, @Nachname = Nachname, @E-Mail =
E-Mail
FROM eingefügt
--Vertriebskraft
Exec ('In Kontakt einfügen (Vorname, Nachname, E-Mail) Werte
(?,?,?,?)', @Vorname, @Nachname, @Email) unter
SALESFORCE_CBD;
--MS-Austausch
EXEC ('In Kontakt einfügen (Vorname, Nachname,
E-Mail1EmailAdresse) Werte(?,?,?,?)', @Vorname,
@Nachname, @Email) bei EXCHANGE365_CU7;
END
END
ELSE
BEGINN
-- wenn die Operation nicht aktualisiert/eingefügt wurde, dann wurde sie gelöscht
SELECT @Deleted_Email = E-Mail FROM gelöscht
--Vertriebskraft
Ausführen ('Aus Kontakt löschen, wobei E-Mail = ?', @Deleted_Email) unter
SALESFORCE_CBD;
--MS-Austausch
Ausführen ('Aus Kontakt löschen, wobei Email1EmailAddress = ?',
@Gelöschte_E-Mail) bei EXCHANGE365_CU7;
END
END

Warnung: Nach der Ausführung des obigen Skripts sollten wir nichts aus der lokalen Datenbanktabelle einfügen, bis wir zwischen unseren beiden Zielsystemen (Exchange und SalesForce) und unserer lokalen Datenbank synchronisiert haben. Andernfalls könnten wir versehentlich Datensätze duplizieren, da die Logik hier nicht prüft, ob auf diesen Zielsystemen bereits ein neuer Datensatz existiert.

Der zweite Schritt in unserer Lösung besteht in der Synchronisierung zwischen MS Exchange, SalesForce und unserer Tabelle mit den lokalen Kontakten, so dass jedes System den gleichen Satz von Kontakten hat.

Um das zu tun, werden wir eine gespeicherte Prozedur schreiben. Die Logik der Prozedur besteht darin, dies zu tun:

1. Es ist sehr wichtig, den Trigger, den wir oben erstellt haben, zu deaktivieren, "da wir die Synchronisation durchführen, dürfen wir die automatische Replikation, die durch den Trigger implementiert wird, nicht aktivieren".

2. Synchronisieren zwischen SalesForce und meiner Datenbank
Verwendung der E-Mail-Adresse des Kontakts als Übereinstimmungsschlüssel; Gibt es einen Kontakt in SalesForce und nicht in meiner Tabelle der lokalen Kontakte?

a. Ja: Kontakt zu meiner lokalen Kontakttabelle hinzufügen

b. Nein: Vorname und Nachname des Kontakts in der Tabelle meiner lokalen Kontakte aktualisieren

3. Synchronisieren zwischen MS Exchange und meiner Datenbank
Verwendung der E-Mail-Adresse des Kontakts als passenden Schlüssel; Gibt es einen Kontakt im Exchange und nicht in meiner Tabelle der lokalen Kontakte?

a. Ja: Kontakt zu meiner lokalen Kontakttabelle hinzufügen

b. Nein: Vorname und Nachname des Kontakts in der Tabelle meiner lokalen Kontakte aktualisieren

Zum jetzigen Zeitpunkt enthält meine lokale Kontakttabelle alle Kontakte aus SalesForce und MS Exchange zusätzlich zu den Datensätzen, die ursprünglich in der Tabelle enthalten waren. Jetzt müssen wir jedes Zielsystem durch die Kontakte aus dem anderen Zielsystem und der lokalen Datenbank aktualisieren.

4. Kontakte in SalesForce aktualisieren (durch Kontakte aus Exchange & meinem lokalen Tisch)

Verwendung der E-Mail-Adresse des Kontakts als Übereinstimmungsschlüssel; Gibt es einen Kontakt in meiner lokalen Kontakttabelle und nicht in SalesForce?

a. Ja: Kontakt zu SalesForce hinzufügen

b. Nein: Vorname und Nachname des Kontakts in SalesForce aktualisieren

5. Kontakte auf Exchange aktualisieren (durch Kontakte von SalesForce & meinem lokalen Tisch)

Verwendung der E-Mail-Adresse des Kontakts als passenden Schlüssel; Gibt es einen Kontakt in meiner Tabelle der lokalen Kontakte und nicht in Exchange?

a. Ja: Kontakt zu MS Exchange hinzufügen

b. Nein: Vorname und Nachname des Kontakts im Austausch aktualisieren

6. Jetzt können wir den Auslöser aktivieren, den wir zuvor deaktiviert hatten, so dass die automatische Replikation wieder eingeschaltet ist.

Das folgende SQL-Skript implementiert die oben besprochene Logik

ERSTELLVERFAHREN [dbo].[uspInitSync]
-- Fügen Sie hier die Parameter für die Stored Procedure hinzu
AS
BEGINN
-- SET NOCOUNT ON hinzugefügt, um zu verhindern, dass zusätzliche Ergebnismengen
-- Beeinträchtigung von SELECT-Anweisungen.
SET NOCOUNT ON;

-Deaktivieren Sie den Auslöser, damit wir beim Einfügen aus SalesForce nicht
--erneutes Hinzufügen der Kontakte zu SalesForce
DEAKTIVIERBARER TRIGGER [trgSyncContact] für lokale Kontakte;

-Datensätze von SalesForce mit LocalDB zusammenführen
DECLARE @ImportierteKontakte-Tabelle(Vorname nvarchar(max), Nachname
nvarchar(max), E-Mail varchar(255));

-aktualisieren/einfügen von Kontakten in LocalDB mit SalesForce als Quelle
MERGE LocalContacts AS Ziel
BENUTZUNG (SELECT Vorname, Nachname, E-Mail FROM SalesForce_CBD...Kontakt)
AS-Quelle
ON (Ziel.E-Mail LIKE Quelle.E-Mail)
BEI ÜBEREINSTIMMUNG DANN
UPDATE SET Vorname = Quelle.Vorname, Nachname =
Quelle.Nachname
WENN NICHT ÜBEREINSTIMMEND DANN
INSERT (Vorname, Nachname, E-Mail)
WERTE (Quelle.Vorname, Quelle.Nachname, Quelle.E-Mail)
OUTPUT eingefügt.Vorname, eingefügt.Nachname, eingefügt.E-Mail
INTO @ImportierteKontakte;

-eingefügte Kontakte in LocalDB von SalesForce anzeigen
wählen Sie * aus @ImportedContacts;

-aktualisieren/einfügen von Kontakten in LocalDB mit Exchange als Quelle
MERGE LocalContacts AS Ziel
BENUTZUNG (SELECT Vorname, Nachname, E-Mail1E-MailAdresse VON
EXCHANGE365_CU7...Kontakt) AS-Quelle
ON (Ziel.Email LIKE Quelle.Email1EmailAdresse)
BEI ÜBEREINSTIMMUNG DANN
UPDATE SET Vorname = Quelle.Vorname, Nachname =
Quelle.Nachname
WENN NICHT ÜBEREINSTIMMEND DANN
INSERT (Vorname, Nachname, E-Mail)
WERTE (Quelle.Vorname, Quelle.Nachname,
Quelle.E-Mail1EmailAdresse)
OUTPUT eingefügt.Vorname, eingefügt.Nachname, eingefügt.E-Mail
INTO @ImportierteKontakte;

-eingefügte Kontakte mittels Tabellenvariable anzeigen
wählen Sie * aus @ImportedContacts;

--jetzt alles an SalesForce & Exchange kopieren, damit sie eine exakte Kopie erhalten
--von LocalDB, nachdem LocalDB mit allen Systemen synchronisiert wurde
--I müssen cursour verwenden und wenn, weil die Verwendung von insert.....select......where not
--existiert funktionierte nicht mit entfernten Tabellen und auch Merge funktioniert nicht mit
--ferne Tabellen
@Vorname nvarchar(max) deklarieren
@LastName nvarchar(max) deklarieren
deklarieren @Email varchar(255)
@SQL nvarchar(max) deklarieren

DECLARE Kontakte_Cursor CURSOR FAST_FORWARD FOR
SELECT Vorname, Nachname, E-Mail von LocalContacts;

OPEN-Kontakte_Cursor
FETCH NEXT FROM Kontakte_Cursor INTO @Vorname, @Nachname, @E-Mail
WÄHREND @@FETCH_STATUS = 0
BEGINN
WENN ERREICHT (SELECT Email1EmailAddress FROM EXCHANGE365_CU7...Kontakt
WHERE Email1EmailAdresse LIKE @Email)
EXEC ('UPDATE Contact SET Vorname = ?, Nachname = ? WO
E-Mail1E-MailAdresse = ?', @Vorname, @Nachname, @E-Mail)
bei EXCHANGE365_CU7;
ELSE
EXEC ('In Kontakt einfügen (Vorname, Nachname,
E-Mail1EmailAdresse) Werte(?,?,?,?)', @Vorname,
@Nachname, @Email) bei EXCHANGE365_CU7;

WENN ERREICHT (E-Mail AUS WÄHLEN VON SalesForce_CBD...Kontakt WIE E-Mail
@E-Mail)
Ausführen ('UPDATE Kontakt SET Vorname = ?, Nachname = ? WO
E-Mail = ?', @Vorname, @Nachname, @E-Mail) unter
SalesForce_CBD;
ELSE
Exec ('In Kontakt einfügen (Vorname, Nachname, E-Mail) Werte
(?,?,?,?)', @Vorname, @Nachname, @Email) unter
SalesForce_CBD;

FETCH NEXT FROM Kontakte_Cursor INTO @Vorname, @Nachname, @E-Mail
END
CLOSE Kontakte_Cursor;
DEALLOCATE Kontakte_Cursor; DEALLOCATE Kontakte_Cursor;

--aktivieren Sie den Trigger, so dass jede Änderung im Online-LOB reflektiert wird
TRIGGER AKTIVIEREN [trgSyncContact] für lokale Kontakte;
END

Der erste Schritt besteht nun darin, die Synchronisierungs-Stored Procedure "uspInitSync" wie unten gezeigt auszuführen, die Stored Procedure wurde ohne Fehler ausgeführt.

Wir konnten auch sehen, dass neue Kontakte zu MS Exchange hinzugefügt wurden.

Und neue Kontakte zu SalesForce hinzugefügt

Und unsere lokale Datenbanktabelle hat jetzt neue Kontakte

Wir können die automatische Replikation auch in Aktion sehen

1. Kontakt aus lokaler Datenbank einfügen, löscht ihn aus SalesForce und Exchange

2. Die Aktualisierung des Kontakts in der lokalen Datenbank aktualisiert ihn in SalesForce und Exchange

3. Kontakt aus lokaler Datenbank löschen, löscht ihn aus SalesForce und Exchange

Wir haben versucht, die Lösungslogik so einfach wie möglich zu halten, aber die Logik könnte noch weiter verbessert und für eine bessere Leistung und komplexere Funktionen optimiert werden.

Weitere Informationen zu diesem Produkt finden Sie auf der Produktseite von CB Linked Server for Enterprise Applications.