Intégration SQL de Exchange et de Salesforce

En raison du succès de notre premier article technique qui peut être trouvé ici nous avons décidé de continuer. Cette fois-ci, nous allons examiner comment l'intégration entre Exchange et Salesforce peut être réalisée de la manière la plus simple. Nous utiliserons des requêtes SQL.

Pour l'intégration, nous utilisons CB Linked Server for Enterprise Applications. Demandez-nous un essai gratuit du produit.

Le scénario d'intégration requis ici est de synchroniser entre une table de contacts de la base de données locale, les contacts Exchange 365 et les contacts de la force de vente et d'avoir une réplication immédiate de la table de la base de données locale vers ces 2 systèmes cibles. Cela pourrait être utile pour avoir une sauvegarde des contacts hors ligne ou pour créer un entrepôt de données ou pour d'autres raisons.

La première étape consiste à s'assurer que vous êtes en mesure de vous connecter au système cible (Exchange et SalesForce dans notre scénario) ; la manière la plus simple de le faire est de passer par le CB Query Analyzer. Ici, j'ai déjà configuré mon serveur ConnectBridge via l'outil d'administration pour me connecter à MS Exchange 365 et à SalesForce en créant les groupes et les utilisateurs requis. J'ai créé un nom d'utilisateur appelé "martin"avec mot de passe1234”. Cet utilisateur a le droit de se connecter à Exchange 365 et à SalesForce. Maintenant, à partir de Query Analyzer, je vais créer 2 connexions vers chaque système cible et m'assurer que je peux me connecter avec succès.

Comme indiqué ci-dessus, nous avons une configuration et une connexion réussies aux deux systèmes cibles. Nous pouvons maintenant tester nos déclarations

Sur mon compte Exchange, j'ai 3 contacts comme indiqué ci-dessous

Nous allons maintenant tester les 4 opérations de base SÉLECTIONNER, INSÉRER, METTRE À JOUR ET SUPPRIMER

1. Sélection des contacts

En exécutant la déclaration ci-dessous, nous devrions obtenir les 3 contacts indiqués dans la figure 5.

SÉLECTIONNEZ [Prénom], [Nom], [Adresse électronique1] de [Contact] ;

2. Insertion d'un contact

En exécutant la déclaration ci-dessous, il faut insérer un nouveau contact comme indiqué dans la figure 6

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

3. Mise à jour d'un contact

L'exécution de la déclaration ci-dessous devrait mettre à jour le nom de famille du contact que nous avons inséré précédemment, comme indiqué dans la figure 7

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

4. Suppression d'un contact

L'exécution de la déclaration ci-dessous doit supprimer le contact nouvellement inséré, comme indiqué dans la figure 8

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

Sur mon compte SalesForce, je dispose de 17 contacts comme indiqué ci-dessous

Nous allons maintenant tester les 4 mêmes opérations de base : SÉLECTIONNER, INSÉRER, MISE À JOUR et SUPPRIMER.

1. Sélection des contacts

L'exécution de la déclaration ci-dessous devrait nous donner les 17 contacts indiqués dans la figure 10.

SÉLECTIONNEZ [Prénom], [Nom], [Courriel] DE [Contact] ;

2. Insertion d'un contact

En exécutant la déclaration ci-dessous, il faut insérer un nouveau contact comme indiqué à la figure 11

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

3. Mise à jour d'un contact

L'exécution de la déclaration ci-dessous devrait mettre à jour le nom de famille du contact que nous avons inséré précédemment, comme indiqué dans la figure 12

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

4. Suppression d'un contact

L'exécution de la déclaration ci-dessous doit supprimer le contact nouvellement inséré, comme indiqué dans la figure 13

SUPPRIMER DU CONTACT OÙ [Email] = 'peter@gmail.com' ;

Nous savons maintenant que nous pouvons sélectionner, mettre à jour, insérer et supprimer des contacts de Exchange & SalesForce. Ce que nous devons faire maintenant, c'est copier la chaîne de connexion de Query Analyzer et nos déclarations testées pour les utiliser plus tard dans notre solution MS SQL Server.

Pour copier la connexion à partir de l'analyseur de requêtes, il suffit de cliquer avec le bouton droit de la souris sur la connexion, de cliquer sur Modifier et d'aller dans l'onglet Avancé et de copier le texte à partir de là comme indiqué ci-dessous dans la figure 14.

Voici mes chaînes de connexion pour les deux systèmes cibles.

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'

Nous sommes maintenant prêts à ouvrir le serveur MS SQL et à commencer à mettre en œuvre notre solution d'intégration du serveur SQL.

Pour pouvoir travailler avec des sources de données externes via la fonction SQL Server Linked Server, nous devons effectuer les configurations suivantes

1. Démarrez Microsoft SQL Server Management Studio et connectez-vous en utilisant soit l'authentification Windows, soit le nom d'utilisateur et le mot de passe, comme indiqué ci-dessous à la figure 15

2. Naviguer vers Sever Objects -> Serveurs liés -> Fournisseurs -> MSDASQL en développant les nœuds correspondants comme indiqué ci-dessus dans la figure 16. Cliquez avec le bouton droit de la souris sur MSDASQL - Microsoft Data Access SQL - et sélectionnez Propriétés pour afficher le dialogue de la figure 17

3. Nous devons nous assurer que les paramètres/options suivants sont vérifiés :

a. Niveau zéro uniquement: Pour des raisons de sécurité, nous devons nous assurer que seuls les fournisseurs OLE DB qui sont conformes à l'interface OLE DB de niveau 0 sont pris en charge.

b. Autoriser l'entrée en matièreLe but est de permettre au(x) fournisseur(s) de données - "sources de données externes" - d'être instancié(s) en tant que serveur in-process - "dans le même processus que MS SQL Server". Nous devons faire cela pour éviter de passer des informations d'authentification entre MS SQL Server et le fournisseur et pour pouvoir travailler avec des types de données comme (varchar(max), nvarchar(max), varbinary(max), text, ntext, ou image). Sans activer cette option, nous ne pourrons pas obtenir une donnée de type image de Exchange - par exemple - et l'insérer dans notre base de données MS SQL Server.

4. Nous devons maintenant permettre à MS SQL Server de se connecter aux fournisseurs externes et d'exécuter des requêtes pour interroger les données des fournisseurs externes qui utilisent l'OLEDB - appelons-les "Sources de données externes de l'OLEDB”. Nous le ferons en trois étapes :

a. Nous devons ouvrir une nouvelle fenêtre de requête en cliquant sur le bouton "Nouvelle requête" comme indiqué dans la figure 18 ci-dessous. Peu importe la base de données active, car ce que nous allons faire va affecter toute l'installation de MS SQL Server et, à son tour, chacune des bases de données qui s'y trouvent. Comme le montre le schéma ci-dessous, j'ai "master" comme base de données active/cible

b. Nous devons reconfigurer MS SQL Server afin de pouvoir modifier/configurer ses options avancées. Pour ce faire, nous allons exécuter une procédure stockée appelée "sp_configure" - c'est une procédure stockée système préinstallée - et nous allons spécifiquement "montrer les options avancées" - en définissant cette option à 1. Pour ce faire, nous tapons "exec sp_configure 'show advanced options', 1 ; reconfigure" et nous appuyons sur F5 pour exécuter. Si tout se passe bien, vous devriez obtenir un message similaire à celui de la Figure 19 ci-dessous

c. Nous devons maintenant permettre à MS SQL Server d'interroger ces "Sources de données externes de l'OLEDB" en utilisant quelque chose appelé "Requêtes ad hoc distribuées". Par défaut, MS SQL Server ne permet pas les "Ad Hoc Distributed Queries", nous devons donc reconfigurer cette option avancée - c'est pourquoi nous avons fait l'étape précédente - en exécutant la procédure stockée "sp_configure" en passant le paramètre "Ad Hoc Distributed Queries" et la valeur 1 pour l'activer. Si tout va bien, vous devriez obtenir un message similaire à celui de la Figure 20 ci-dessous après avoir exécuté "exec sp_configure 'Ad Hoc Distributed Queries', 1 ; reconfigure".

Nous pouvons maintenant ajouter autant de serveurs liés que nous le souhaitons, puisque notre serveur MS SQL est correctement configuré pour le permettre.

1. naviguez vers Sever Objects -> Serveurs liés. Cliquer sur le bouton droit de la souris Serveurs liés et choisir Nouveau serveur lié comme le montre la figure 21 ci-dessous

2. Dans la nouvelle boîte de dialogue du serveur lié, comme le montre la figure 22 ci-dessous, vous devez fournir ce qui suit :

a. Nom du serveur liéPour le nom de la personne, je choisis Exchange365_CU7.

b. Fournisseurdoit être "Microsoft OLE DB Providers for ODBC Drivers", car ConnectBridge utilise ODBC.

c. Chaîne de fournisseurs: ici, nous collons la chaîne de connexion que nous avons copiée précédemment de l'Analyseur de requêtes.

3) Il faut maintenant établir une relation entre l'utilisateur qui utilise ou accède à MS SQL Server et l'utilisateur qui utilise ou accède à CB. L'utilisateur utilisant MS SQL Server est appelé Local Login (dans notre scénario, c'est "sa") et l'utilisateur utilisant / accédant à CB est appelé Remote User (dans notre scénario, c'est Martin avec login martin). C'est ce que nous devons configurer, et pour ce faire, nous cliquons sur "sécurité"pour afficher le dialogue de la figure 23 ci-dessous

4. Lorsque la boîte de dialogue ci-dessus s'affiche, nous cliquons sur le bouton Ajouter et nous saisissons le nom d'utilisateur local et l'utilisateur distant comme nous l'avons convenu. C'est ce que j'ai fait ici, à la figure 24

5. Je sais que vous voulez clore le dialogue, mais attendez ! Nous devons faire un pas de plus. Maintenant, nous devons aller à "Options du serveurL'onglet " à gauche " permet d'afficher le dialogue de la figure 25 ci-dessous et d'activer 2 fonctionnalités

a. RPCpour activer un certain dispositif de sécurité dont nous aurions besoin lorsque nous utilisons un dispositif existant appelé Serveur à distance - ne vous inquiétez pas pour l'instant - pour que la validation de la connexion entre CB et MS SQL Server soit possible

b. RPC Outpour permettre "Appel de procédure à distance"Nous devons en effet permettre à nos procédures stockées de fonctionner à distance

6. Maintenant, nous cliquons sur OK et c'est terminé ! Oui ! Nous avons configuré le serveur MS SQL pour qu'il se connecte à Exchange. Maintenant nous pouvons voir la plate-forme Exchange comme une base de données dans MS SQL Server, nous pouvons voir le tableau appelé Contacts, nous pouvons montrer une liste de contacts de Exchange, tout cela, sans avoir à accéder à la base de données Exchange comme vous pouvez le voir dans la figure 26 ci-dessous

Avant de développer notre solution d'intégration, nous devons nous assurer que nous sommes en mesure d'effectuer la manipulation des données de base sur MS Exchange via notre serveur lié nouvellement configuré.

1. Sélection des contacts

L'exécution de la déclaration ci-dessous devrait nous donner les 3 contacts du MS Exchange.

CHOISIR Prénom, Nom, Courriel1Adresse électronique DE L'ÉCHANGE365_CU7...Contact ;

Pourquoi le "..." ? Parce qu'il suit la syntaxe SERVER.DATABASE.SCHEMA.TABLE et comme vous avez pu le voir sur la figure 26 ci-dessus, notre serveur est Exchange365_CU7, notre base de données est "sans nom", notre schéma est "sans nom" et enfin notre table est Contacts.

2. Insertion d'un contact

En exécutant la déclaration ci-dessous, vous devez insérer un nouveau contact.

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

3. Mise à jour d'un contact

L'exécution de la déclaration ci-dessous doit mettre à jour le nom de famille du contact que nous avons inséré précédemment

EXEC('UPDATE Contact SET [SurName] = "Keys" WHERE [Email1EmailAddress] LIKE
"peter@gmail.com";') À L'ADRESSE EXCHANGE365_CU7 ;

4. Suppression d'un contact

L'exécution de la déclaration ci-dessous doit supprimer le contact nouvellement inséré

EXEC ('DELETE FROM Contact WHERE [Email1EmailAddress] LIKE
"peter@gmail.com";') À L'ADRESSE EXCHANGE365_CU7 ;

Nous allons suivre les étapes de la section "4.2 Configuration du serveur lié MS Exchange", sauf bien sûr que nous allons utiliser la chaîne de connexion pour SalesForce. Après avoir suivi ces étapes, votre serveur lié devrait être configuré avec succès comme indiqué ci-dessous.

Comme nous l'avons fait auparavant également avec le serveur lié MS Exchange, nous devons nous assurer que nous sommes en mesure d'effectuer les tâches de manipulation des données de base via le serveur lié à la force de vente.

Pour raccourcir le guide, la figure 32 ci-dessous teste toutes les déclarations suivantes

1. Sélection des contacts

L'exécution de la déclaration ci-dessous devrait nous donner les contacts de SalesForce.

CHOISIR Prénom, Nom, Courriel1Adresse électronique DE L'ÉCHANGE365_CU7...Contact ;

2. Insertion d'un contact

En exécutant la déclaration ci-dessous, vous devez insérer un nouveau contact.

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

3. Mise à jour d'un contact

L'exécution de la déclaration ci-dessous doit mettre à jour le nom de famille du contact que nous avons inséré précédemment

EXEC('UPDATE Contact SET [SurName] = "Keys" WHERE [Email1EmailAddress] LIKE
"peter@gmail.com";') À L'ADRESSE EXCHANGE365_CU7 ;

4. Suppression d'un contact

L'exécution de la déclaration ci-dessous doit supprimer le contact nouvellement inséré

EXEC ('DELETE FROM Contact WHERE [Email1EmailAddress] LIKE
"peter@gmail.com";') À L'ADRESSE EXCHANGE365_CU7 ;

À partir de là, nous devons disposer d'une véritable base de données locale sur notre serveur MS SQL local. Si vous en avez déjà une, vous pouvez l'utiliser sinon nous devons créer une nouvelle base de données. J'ai créé une base de données appelée ConnectingSoftware avec une table appelée LocalContacts. Dans cette table, il n'y a qu'un seul enregistrement, comme le montre la figure 33 ci-dessous.

La première étape de notre solution consiste à reproduire les modifications apportées à la table de notre base de données locale à la fois pour SalesForce et Exchange. Nous allons mettre en œuvre cette solution via le déclencheur de la table.

Le script SQL pour le déclencheur est présenté ci-dessous :

CREATE TRIGGER [dbo] [trgSyncContact]
ON [dbo] [Contacts locaux]
APRÈS INSERTION, MISE À JOUR, SUPPRESSION
AS
DÉBUT
déclarer @Opération varchar(50)
déclarer @FirstName nvarchar(max)
déclarer @LastName nvarchar(max)
déclarer @Email varchar(255)
déclarer @Deleted_FirstName nvarchar(max)
déclarer @Deleted_LastName nvarchar(max)
déclarer @Deleted_Email varchar(255)

SI COLUMNS_UPDATED() > 0
DÉBUT
--si nous avons mis à jour des colonnes, alors nous avons soit inséré soit supprimé un
record
S'IL EXISTE (SÉLECTIONNEZ * DE SUPPRIMÉ)
DÉBUT
--si nous avons supprimé des valeurs, alors il s'agissait d'une opération de mise à jour
SELECT @FirstName = inséré.FirstName, @LastName =
inserted.LastName, @Email = inserted.Email,
@Deleted_FirstName = supprimé.FirstName,
@Deleted_LastName = supprimé.LastName, @Deleted_Email =
supprimé.Email
De supprimé, inséré
--SalesForce
Exec ('UPDATE Contact SET FirstName = ?, LastName = ?, Email = ?
OÙ Prénom = ? et Nom = ? et Email = ?
@Prénom, @Nom, @Email, @Prénom_supprimé,
@Deleted_LastName, @Deleted_Email) à SALESFORCE_CBD ;
--Exchange
EXEC ('UPDATE Contact SET GivenName = ?, SurName = ?,
Adresse électronique1 = ? WHERE GivenName = ? et SurName =
? et Email1EmailAddress = ?', @FirstName, @LastName,
@Email, @Deleted_FirstName, @Deleted_LastName,
@Deleted_Email) à EXCHANGE365_CU7 ;
FIN
ELSE
DÉBUT
--si ce n'était pas une opération de mise à jour, alors c'était une insertion
SELECT @FirstName = Prénom, @LastName = Nom, @Email =
Courriel
DE inséré
--SalesForce
Les valeurs de l'option Exec ('Insérer dans Contact (FirstName, LastName, Email)
( ?,?, ?)', @FirstName, @LastName, @Email) à
SALESFORCE_CBD ;
--MS Exchange
EXEC ('Insérer dans Contact (Prénom, Nom de famille,
Email1EmailAddress) valeurs( ?,?, ?)', @FirstName,
@LastName, @Email) à EXCHANGE365_CU7 ;
FIN
FIN
ELSE
DÉBUT
--si l'opération n'a pas été mise à jour/insérée alors elle a été supprimée
SELECT @Deleted_Email = Email FROM supprimé
--SalesForce
Exec ("Delete From Contact Where Email = ?", @Deleted_Email) à
SALESFORCE_CBD ;
--MS Exchange
Exec ("Delete From Contact Where Email1EmailAddress = ?",
@Deleted_Email) à EXCHANGE365_CU7 ;
FIN
FIN

Attention : après avoir exécuté le script ci-dessus, nous ne devons rien insérer de la table de la base de données locale tant que nous n'avons pas synchronisé nos 2 systèmes cibles (Exchange et SalesForce) avec notre base de données locale, sinon nous pourrions nous retrouver avec des enregistrements accidentellement dupliqués puisque la logique ici ne vérifie pas si un nouvel enregistrement a déjà existé sur ces systèmes cibles.

La deuxième étape de notre solution consiste à synchroniser entre MS Exchange, SalesForce et notre table de contacts locaux, de sorte que chaque système ait le même ensemble de contacts.

Pour ce faire, nous allons rédiger une procédure stockée. La logique de la procédure est de :

1. Très important pour désactiver le déclencheur que nous avons créé ci-dessus "comme nous faisons la synchronisation, nous ne devons pas activer la réplication automatique mise en œuvre par le déclencheur".

2. Synchroniser entre SalesForce et ma base de données
Utilisation de l'adresse électronique du contact comme clé de correspondance ; Y a-t-il un contact sur SalesForce et non dans mon tableau des contacts locaux ?

a. Oui : ajouter un contact à mon tableau des contacts locaux

b. Non : Mettre à jour le prénom et le nom du contact dans mon tableau des contacts locaux

3. Synchroniser entre MS Exchange et ma base de données
Utilisation de l'adresse électronique du contact comme clé de correspondance ; Y a-t-il un contact sur Exchange et non dans mon tableau des contacts locaux ?

a. Oui : ajouter un contact à mon tableau des contacts locaux

b. Non : Mettre à jour le prénom et le nom du contact dans mon tableau des contacts locaux

À ce stade, ma table de contacts locale dispose de tous les contacts de SalesForce et de MS Exchange en plus des enregistrements qui figuraient à l'origine dans la table. Nous devons maintenant mettre à jour chaque système cible en y ajoutant les contacts de l'autre système cible et la base de données locale

4. Mise à jour des contacts sur SalesForce (par les contacts de Exchange & ma table locale)

Utilisation de l'adresse électronique du contact comme clé de correspondance ; Y a-t-il un contact dans mon tableau des contacts locaux et non dans SalesForce ?

a. Oui : ajouter un contact à la force de vente

b. Non : Mettre à jour le prénom et le nom du contact sur SalesForce

5. Mise à jour des contacts sur Exchange (par les contacts de SalesForce & ma table locale)

Utilisation de l'adresse électronique du contact comme clé de correspondance ; Y a-t-il un contact dans mon tableau des contacts locaux et non sur Exchange ?

a. Oui : ajouter un contact à la MS Exchange

b. Non : Mettre à jour le prénom et le nom du contact sur Exchange

6. Maintenant, nous pouvons activer le déclencheur que nous avons désactivé précédemment, de sorte que la réplication automatique est de nouveau activée.

Le script SQL suivant mettra en œuvre la logique décrite ci-dessus

PROCÉDURE DE CRÉATION [dbo] [uspInitSync]
-- Ajoutez ici les paramètres de la procédure stockée
AS
DÉBUT
-- Ajout de l'option SET NOCOUNT ON pour éviter que des ensembles de résultats supplémentaires
-- interférant avec les déclarations SELECT.
METTRE NOCOUNT ON ;

-désactiver le déclencheur afin que, lors de l'insertion de la SalesForce, nous n'endurions pas
--en ajoutant à nouveau les contacts à la SalesForce
DISABLE TRIGGER [trgSyncContact] ON LocalContacts ;

--fusionner les dossiers de SalesForce à LocalDB
DECLARE @ImportedContacts Table(FirstName nvarchar(max), LastName
nvarchar(max), Email varchar(255)) ;

--mettre à jour / insérer des contacts dans LocalDB en utilisant SalesForce comme source
MERGE LocalContacts AS target
UTILISATION (SÉLECTIONNER le prénom, le nom, le courriel de SalesForce_CBD...Contact)
Source AS
ON (cible.Email LIKE source.Email)
LORSQU'ILS SONT APPARIÉS, ALORS
MISE À JOUR DU PRÉNOM = source.Prénom, Nom =
source.Nom de famille
LORSQU'IL N'Y A PAS DE CORRESPONDANCE À CE MOMENT-LÀ
INSERER (Prénom, Nom, Courriel)
VALEURS (source.Prénom, source.Nom, source.Courriel)
OUTPUT inséré.Prénom, inséré.Nom, inséré.Courriel
INTO @ImportedContacts ;

-montrer les contacts insérés dans LocalDB de SalesForce
sélectionnez * à partir de @ImportedContacts ;

--mettre à jour / insérer des contacts dans la LocalDB en utilisant Exchange comme source
MERGE LocalContacts AS target
UTILISATION (SÉLECTIONNER le prénom, le nom de famille, l'adresse électronique1 DE
EXCHANGE365_CU7...Contact) AS source
ON (target.Email LIKE source.Email1EmailAddress)
LORSQU'ILS SONT APPARIÉS, ALORS
MISE À JOUR DU PRÉNOM = source.Prénom, Nom =
source.Nom de famille
LORSQU'IL N'Y A PAS DE CORRESPONDANCE À CE MOMENT-LÀ
INSERER (Prénom, Nom, Courriel)
VALEURS (source.Nom.Prénom, source.Nom,
source.Email1EmailAddress)
OUTPUT inséré.Prénom, inséré.Nom, inséré.Courriel
INTO @ImportedContacts ;

--afficher les contacts insérés en utilisant une variable de table
sélectionnez * à partir de @ImportedContacts ;

--copiez maintenant tout à SalesForce & Exchange pour qu'ils aient une copie exacte
--de LocalDB après que LocalDB soit synchronisé avec tous les systèmes
-Je dois utiliser le curseur et si parce qu'utiliser l'insert....sélectionner....où pas
--existe ne fonctionnait pas avec les tables distantes et aussi fusionner ne fonctionne pas avec
--tables distantes
Déclarer @FirstName nvarchar(max)
déclarer @LastName nvarchar(max)
déclarer @Email varchar(255)
déclarer @SQL nvarchar(max)

DECLARE Contacts_cursor CURSOR FAST_FORWARD FOR
SÉLECTIONNER le prénom, le nom, le courriel de LocalContacts ;

OPEN Contacts_cursor
RECHERCHEZ LE SUIVANT DE CONTACTS_cursor DANS @Prénom, @Nom, @Email
ALORS QUE @@FETCH_STATUS = 0
DÉBUT
SI EXISTE (SÉLECTIONNER L'ADRESSE ÉLECTRONIQUE1 DE L'ÉCHANGE365_CU7...Contact
OÙ Email1Adresse électronique LIKE @Email)
EXEC ('UPDATE Contact SET GivenName = ?, SurName = ? OÙ
Email1EmailAddress = ?', @FirstName, @LastName, @Email)
à l'adresse EXCHANGE365_CU7 ;
ELSE
EXEC ('Insérer dans Contact (Prénom, Nom de famille,
Email1EmailAddress) valeurs( ?,?, ?)', @FirstName,
@LastName, @Email) à EXCHANGE365_CU7 ;

SI EXISTE (SÉLECTIONNER L'E-Mail de SalesForce_CBD...Contacter OÙ l'E-Mail EST LIÉ
@Email)
Exec ('UPDATE Contact SET FirstName = ?, LastName = ? OÙ
Email = ?', @FirstName, @LastName, @Email) à
SalesForce_CBD ;
ELSE
Les valeurs de l'option Exec ('Insérer dans Contact (FirstName, LastName, Email)
( ?,?, ?)', @FirstName, @LastName, @Email) à
SalesForce_CBD ;

RECHERCHEZ LE SUIVANT DE CONTACTS_cursor DANS @Prénom, @Nom, @Email
FIN
Fermer le curseur Contacts ;
DEALLOCATE Contacts_cursor ;

--activer le déclencheur afin que toute modification soit prise en compte dans la LPP en ligne
ENABLE TRIGGER [trgSyncContact] ON LocalContacts ;
FIN

La première étape consiste maintenant à exécuter la procédure de synchronisation stockée "uspInitSync" comme indiqué ci-dessous, la procédure stockée a été exécutée sans erreur.

Nous avons également pu constater que de nouveaux contacts ont été ajoutés au MS Exchange

Et de nouveaux contacts ajoutés à la SalesForce

Et notre table de base de données locale a maintenant de nouveaux contacts

Nous pouvons voir la réplication automatique en action également

1. Insérer un contact dans la base de données locale, le supprimer de SalesForce et Exchange

2. La mise à jour du contact dans la base de données locale le met à jour dans SalesForce et Exchange

3. Supprimer un contact de la base de données locale, le supprimer de SalesForce et Exchange

Nous avons essayé de garder la logique de la solution aussi simple que possible, cependant la logique pourrait être améliorée et modifiée pour de meilleures performances et des fonctionnalités plus complexes.

Vous pouvez trouver plus d'informations sur ce produit sur la page produit de CB Linked Server for Enterprise Applications.