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 (in unserem Szenario Exchange & SalesForce) herstellen können. Am einfachsten geht dies über den CB Query Analyzer. Hier habe ich meinen ConnectBridge-Server bereits über das Verwaltungstool für die Verbindung mit MS Exchange 365 und SalesForce konfiguriert, indem ich die erforderlichen Gruppen und Benutzer erstellt habe. Ich habe einen Benutzernamen namens “martin" mit dem Kennwort "1234”Dieser Benutzer hat Rechte für die Verbindung zu Exchange 365 und SalesForce. Nun werde ich im Query Analyzer zwei 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 auswählen 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: Damit die Datenanbieter – “externe Datenquellen” – als In-Process-Server – “im gleichen Prozess wie MS SQL Server” – instanziiert werden können. Dies ist erforderlich, um die Weitergabe von Authentifizierungsinformationen zwischen MS SQL Server und dem Anbieter zu vermeiden und um mit Datentypen wie (varchar(max), nvarchar(max), varbinary(max), text, ntext oder image) arbeiten zu können. Ohne diese Option können wir beispielsweise keine Daten vom Typ „image” aus Exchange abrufen und in unsere MS SQL Server-Datenbank einfügen.

4. Jetzt müssen wir MS SQL Server so konfigurieren, dass er sich mit externen Anbietern verbinden und Abfragen ausführen kann, um Daten von externen Anbietern abzufragen, die OLEDB verwenden – nennen wir sie “Externe OLEDB-Datenquellen”. Wir werden dies in drei Schritten tun:

a. Wir müssen ein neues Abfragefenster öffnen, indem wir auf die Schaltfläche “Neue Abfrage” klicken, wie in Abbildung 18 unten gezeigt. Es spielt keine Rolle, welche Datenbank aktiv ist, da unsere Aktion sich auf die gesamte MS SQL Server-Installation und damit auf jede einzelne Datenbank darin auswirkt. Wie unten gezeigt, habe ich „master“ als aktive/Zieldatenbank ausgewählt.

b. Wir müssen 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 System-Prozedur – und zeigen speziell die “erweiterten Optionen” an, indem wir diese Option auf 1 setzen. Dazu geben wir “exec sp_configure 'show advanced options', 1; reconfigure” ein und drücken F5, um den Befehl auszuführen. Wenn alles richtig funktioniert, sollten Sie eine Meldung erhalten, die der Meldung in Abbildung 19 unten ähnelt.

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

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. Anbieter: muss “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.

3. Nun müssen wir eine Verbindung zwischen dem Benutzer, der MS SQL Server verwendet/darauf zugreift, und dem Benutzer, der CB verwendet/darauf zugreift, herstellen. Der Benutzer, der MS SQL Server verwendet, wird als “Lokale Anmeldung” bezeichnet (in unserem Szenario ist dies “sa”), und der Benutzer, der CB verwendet/darauf zugreift, wird als „Remote-Benutzer” bezeichnet (in unserem Szenario ist dies Martin mit der Anmeldung „martin”). Dies müssen wir konfigurieren, und dazu klicken wir auf „Sicherheit” Registerkarte, um das Dialogfeld in Abbildung 23 unten anzuzeigen.

4. Wenn das oben gezeigte Dialogfeld angezeigt wird, klicken wir auf die Schaltfläche „Hinzufügen“ und geben den lokalen Anmeldenamen 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 möchten, aber warten Sie! Wir müssen noch einen Schritt machen. Jetzt müssen wir zu “Server-Optionen”Klicken Sie auf die Registerkarte „“ auf der linken Seite, um das Dialogfeld in Abbildung 25 unten anzuzeigen, und aktivieren Sie zwei Funktionen.

a. RPC: um ein bestimmtes Sicherheitsmerkmal zu aktivieren, das wir benötigen würden, wenn wir ein vererbtes Merkmal namens Entfernter Server – Mach dir jetzt keine Sorgen – damit die Anmeldevalidierung zwischen CB und MS SQL Server möglich ist.

b. RPC-Ausgang: aktivieren “Entfernter Prozeduraufruf”Funktion, da wir zulassen müssen, dass unsere gespeicherten Prozeduren remote ausgeführt werden 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 das “…”? Weil es der Syntax SERVER.DATABASE.SCHEMA.TABLE folgt und wie Sie in Abbildung 26 oben sehen können, lautet unser Server Exchange365_CU7, unsere Datenbank “ohne Namen”, unser Schema “ohne Namen” und schließlich unsere Tabelle „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 des MS Exchange-verknüpften Servers” befolgen, außer natürlich, dass wir die Verbindungszeichenfolge für SalesForce verwenden werden. Nachdem Sie diese Schritte befolgt haben, sollte Ihr verknüpfter 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 Ausführung des oben genannten Skripts sollten wir nichts aus der lokalen Datenbanktabelle einfügen, bis wir unsere beiden Zielsysteme (Exchange und SalesForce) und unsere lokale Datenbank synchronisiert haben. Andernfalls könnten wir versehentlich Datensätze duplizieren, da die Logik hier nicht überprüft, ob ein neuer Datensatz bereits auf diesen Zielsystemen vorhanden ist.

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 oben erstellten Trigger zu deaktivieren, “da wir die Synchronisierung durchführen, dürfen wir die durch den Trigger implementierte automatische Replikation nicht aktivieren”.”

2. Synchronisieren zwischen SalesForce und meiner Datenbank
Verwendung der E-Mail-Adresse des Kontakts als Abgleichschlüssel; Gibt es einen Kontakt in SalesForce, der nicht in meiner lokalen Kontakttabelle enthalten ist?

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

b. Nein: Vorname und Nachname des Kontakts in meiner lokalen Kontakttabelle aktualisieren

3. Synchronisieren zwischen MS Exchange und meiner Datenbank
Verwendung der E-Mail-Adresse des Kontakts als Abgleichschlüssel; Gibt es einen Kontakt auf Exchange, der nicht in meiner lokalen Kontakttabelle enthalten ist?

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

b. Nein: Vorname und Nachname des Kontakts in meiner lokalen Kontakttabelle 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 Abgleichschlüssel; Gibt es einen Kontakt in meiner lokalen Kontakttabelle, der nicht in SalesForce vorhanden ist?

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)

Die E-Mail-Adresse des Kontakts als Abgleichschlüssel verwenden; Gibt es einen Kontakt in meiner lokalen Kontakttabelle, der nicht in Exchange vorhanden ist?

a. Ja: Kontakt zu MS Exchange hinzufügen

b. Nein: Vorname und Nachname des Kontakts auf Exchange 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 gespeicherte Synchronisierungsprozedur “uspInitSync” wie unten gezeigt auszuführen. Die gespeicherte Prozedur 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.