Copier des données de et vers Salesforce à l’aide d’Azure Data Factory ou d’Azure Synapse Analytics
S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics
Conseil
Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !
Cet article décrit comment utiliser l’activité de copie dans des pipelines Azure Data Factory et Azure Synapse pour copier des données depuis et vers Salesforce Service Cloud. Il s’appuie sur l’article Vue d’ensemble de l’activité de copie.
Important
Le nouveau connecteur Salesforce fournit une prise en charge native de Salesforce. Si vous utilisez le connecteur Salesforce hérité dans votre solution, mettez à niveau votre connecteur Salesforce avant le 11 octobre 2024. Reportez-vous à cette section pour plus d’informations sur la différence entre la version héritée et la dernière version.
Fonctionnalités prises en charge
Ce connecteur Salesforce est pris en charge pour les fonctionnalités suivantes :
Fonctionnalités prises en charge | IR |
---|---|
Activité de copie (source/récepteur) | ① ② |
Activité de recherche | ① ② |
① Runtime d’intégration Azure ② Runtime d’intégration auto-hébergé
Pour obtenir la liste des magasins de données pris en charge en tant que sources ou récepteurs, consultez la table Magasins de données pris en charge.
Ce connecteur Salesforce prend en charge :
- Développeur Salesforce, éditions professionnelle, d’entreprise ou illimitées.
- Copier de données depuis et vers un domaine personnalisé (un domaine personnalisé peut être configuré dans les environnements de production et de bac à sable).
Vous pouvez définir explicitement la version de l’API utilisée pour lire/écrire des données via la propriété apiVersion
dans le service lié. Lorsque vous copiez des données dans Salesforce, le connecteur utilise l’API BULK 2.0.
Prérequis
L’autorisation de l’API doit être activée dans Salesforce.
Vous devez configurer les applications connectées dans le portail Salesforce en faisant référence à ce document officiel ou à nos instructions pas à pas dans la suggestion de cet article.
Important
- L’utilisateur d’exécution doit disposer de l’autorisation API uniquement.
- L’heure d’expiration du jeton d’accès peut être modifiée par le biais de stratégies de session plutôt que par le jeton d’actualisation.
Limites de l’API en bloc Salesforce 2.0
Nous utilisons l’API en bloc Salesforce 2.0 pour interroger et ingérer des données. Dans l’API en bloc 2.0, les lots sont créés automatiquement. Vous pouvez envoyer jusqu’à 15 000 lots par période propagée de 24 heures. Si les lots dépassent la limite, vous rencontrez des échecs.
Dans l’API en bloc 2.0, seuls les travaux d’ingestion consomment des lots. Les travaux de requête ne le font pas. Pour plus d’informations, consultez Comment les requêtes sont traitées dans le Guide du développeur de l’API en bloc 2.0.
Pour plus d’informations, consultez la section « Limites généraux » dans Salesforce Developer Limits (Limites des développeurs Salesforce).
Bien démarrer
Pour effectuer l’activité Copie avec un pipeline, vous pouvez vous servir de l’un des outils ou kits SDK suivants :
- L’outil Copier des données
- Le portail Azure
- Le kit SDK .NET
- Le kit SDK Python
- Azure PowerShell
- L’API REST
- Le modèle Azure Resource Manager
Créer un service lié à Salesforce à l’aide de l’interface utilisateur
Utilisez les étapes suivantes pour créer un service lié à Salesforce dans l’interface utilisateur du portail Azure.
Accédez à l’onglet Gérer dans votre espace de travail Azure Data Factory ou Synapse et sélectionnez Services liés, puis cliquez sur Nouveau :
Recherchez Salesforce et sélectionnez le connecteur Salesforce.
Configurez les informations du service, testez la connexion et créez le nouveau service lié.
Informations de configuration des connecteurs
Les sections suivantes fournissent des informations sur les propriétés utilisées pour définir des entités spécifiques au connecteur Salesforce.
Propriétés du service lié
Les propriétés suivantes sont prises en charge pour le service lié Salesforce :
Propriété | Description | Obligatoire |
---|---|---|
type | La propriété de type doit être définie sur SalesforceV2. | Oui |
environmentUrl | Spécifiez l’URL de l’instance Salesforce. Par exemple, spécifiez "https://<domainName>.my.salesforce.com" pour copier des données à partir du domaine personnalisé. Découvrez comment configurer ou afficher votre domaine personnalisé en vous référant à cet article. |
Oui |
authenticationType | Type d'authentification utilisé pour se connecter à Salesforce. La valeur autorisée est OAuth2ClientCredentials. |
Oui |
clientId | Spécifiez l’ID client de l’application connectée Salesforce OAuth 2.0. Pour plus d’informations, consultez cet article | Oui |
clientSecret | Spécifiez la clé secrète client de l’application connectée Salesforce OAuth 2.0. Pour plus d’informations, consultez cet article | Oui |
apiVersion | Spécifiez la version de l’API Bulk 2.0 de Salesforce à utiliser, par exemple 52.0 . L’API Bulk 2.0 prend uniquement en charge la version d’API >= 47.0. Pour en savoir plus sur la version de l’API Bulk 2.0, consultez cet article. Une défaillance se produit si vous utilisez une version d’API inférieure. |
Oui |
connectVia | Le runtime d’intégration à utiliser pour se connecter à la banque de données. À défaut de spécification, le runtime d’intégration Azure par défaut est utilisé. | Non |
Exemple : Stocker les informations d’identification
{
"name": "SalesforceLinkedService",
"properties": {
"type": "SalesforceV2",
"typeProperties": {
"environmentUrl": "<environment URL>",
"authenticationType": "OAuth2ClientCredentials",
"clientId": "<client ID>",
"clientSecret": {
"type": "SecureString",
"value": "<client secret>"
},
"apiVersion": "<API Version>"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Exemple : Stocker les informations d’identification dans Key Vault
{
"name": "SalesforceLinkedService",
"properties": {
"type": "SalesforceV2",
"typeProperties": {
"environmentUrl": "<environment URL>",
"authenticationType": "OAuth2ClientCredentials",
"clientId": "<client ID>",
"clientSecret": {
"type": "AzureKeyVaultSecret",
"secretName": "<secret name of client secret in AKV>",
"store":{
"referenceName": "<Azure Key Vault linked service>",
"type": "LinkedServiceReference"
}
},
"apiVersion": "<API Version>"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Exemple : stocker les informations d’identification dans Key Vault, ainsi que environmentUrl et clientId
En stockant des informations d’identification dans Key Vault, ainsi que environmentUrl et clientId, vous pouvez utiliser plus longtemps l’interface utilisateur pour modifier les paramètres. La case à cocher Spécifier le contenu dynamique au format JSON doit être cochée et vous devez manuellement cette configuration. L’avantage de ce scénario est que vous pouvez dériver tous les paramètres de configuration de Key Vault au lieu de paramétriser tout autre élément ici.
{
"name": "SalesforceLinkedService",
"properties": {
"type": "SalesforceV2",
"typeProperties": {
"environmentUrl": {
"type": "AzureKeyVaultSecret",
"secretName": "<secret name of environment URL in AKV>",
"store": {
"referenceName": "<Azure Key Vault linked service>",
"type": "LinkedServiceReference"
},
},
"authenticationType": "OAuth2ClientCredentials",
"clientId": {
"type": "AzureKeyVaultSecret",
"secretName": "<secret name of client ID in AKV>",
"store": {
"referenceName": "<Azure Key Vault linked service>",
"type": "LinkedServiceReference"
},
},
"clientSecret": {
"type": "AzureKeyVaultSecret",
"secretName": "<secret name of client secret in AKV>",
"store":{
"referenceName": "<Azure Key Vault linked service>",
"type": "LinkedServiceReference"
}
},
"apiVersion": "<API Version>"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Propriétés du jeu de données
Pour obtenir la liste complète des sections et propriétés disponibles pour la définition de jeux de données, consultez l’article Jeux de données. Cette section fournit la liste des propriétés prises en charge par le jeu de données Salesforce.
Pour copier des données depuis et vers Salesforce, définissez la propriété de type du jeu de données sur SalesforceV2Object. Les propriétés suivantes sont prises en charge.
Propriété | Description | Obligatoire |
---|---|---|
type | La propriété de type doit être définie sur SalesforceV2Object. | Oui |
objectApiName | Nom d’objet Salesforce duquel extraire des données. La version du runtime d’intégration auto-hébergé applicable est 5.44.8984.1 ou ultérieure. | Non pour la source (si « query » est spécifié dans la source), oui pour le récepteur |
reportId | L’ID du rapport Salesforce à partir duquel récupérer des données. Cela n’est pas pris en charge dans le récepteur. Notez qu’il existe des limitations lorsque vous utilisez des rapports. La version du runtime d’intégration auto-hébergé applicable est 5.44.8984.1 ou ultérieure. | Non pour la source (si « query » est spécifié dans la source), non pris en charge dans le récepteur |
Important
La partie « __c » du nom de l’API est requise pour tout objet personnalisé.
Exemple :
{
"name": "SalesforceDataset",
"properties": {
"type": "SalesforceV2Object",
"typeProperties": {
"objectApiName": "MyTable__c"
},
"schema": [],
"linkedServiceName": {
"referenceName": "<Salesforce linked service name>",
"type": "LinkedServiceReference"
}
}
}
Propriétés de l’activité de copie
Pour obtenir la liste complète des sections et des propriétés disponibles pour la définition des activités, consultez l’article Pipelines. Cette section fournit la liste des propriétés prises en charge par la source et le récepteur Salesforce.
Salesforce en tant que type de source
Pour copier des données à partir de Salesforce, définissez le type de source sur SalesforceV2Source dans l’activité de copie. Les propriétés suivantes sont prises en charge dans la section source de l’activité de copie.
Propriété | Description | Obligatoire |
---|---|---|
type | La propriété de type de la source d’activité de copie doit être définie sur SalesforceV2Source. | Oui |
query | Utilise la requête personnalisée pour lire des données. Vous pouvez utiliser une requête Salesforce Object Query Language (SOQL) uniquement avec des limitations. Pour connaître les limitations SOQL, consultez cet article. Si la requête n’est pas spécifiée, toutes les données de l’objet Salesforce spécifié dans « objectApiName/reportId » dans le jeu de données sont récupérées. | Non (si « objectApiName/reportId » est spécifié dans le jeu de données) |
includeDeletedObjects | Indique si seuls les enregistrements existants doivent être interrogés ou si tous les enregistrements, y compris ceux qui ont été supprimés, doivent être interrogés. Si ce n’est pas spécifié, le comportement par défaut est false. Les valeurs autorisées sont : false (par défaut), true. |
Non |
Important
La partie « __c » du nom de l’API est requise pour tout objet personnalisé.
Exemple :
"activities":[
{
"name": "CopyFromSalesforce",
"type": "Copy",
"inputs": [
{
"referenceName": "<Salesforce input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "SalesforceV2Source",
"query": "SELECT Col_Currency__c, Col_Date__c, Col_Email__c FROM AllDataType__c",
"includeDeletedObjects": false
},
"sink": {
"type": "<sink type>"
}
}
}
]
Salesforce comme type de récepteur
Pour copier des données vers Salesforce, définissez le type de récepteur sur SalesforceV2Sink dans l’activité de copie. Les propriétés suivantes sont prises en charge dans la section récepteur de l’activité de copie.
Propriété | Description | Obligatoire |
---|---|---|
type | La propriété de type du récepteur d’activité de copie doit être définie sur SalesforceV2Sink. | Oui |
writeBehavior | Comportement d’écriture de l’opération. Les valeurs autorisées sont Insert et Upsert. |
Non (la valeur par défaut est un point Insert) |
externalIdFieldName | Nom du champ ID externe pour l’opération upsert. Le champ spécifié doit être défini en tant que « Champ ID externe » dans l’objet Salesforce. Il ne peut pas avoir de valeurs NULL dans les données d’entrée correspondantes. | Oui, pour « Upsert » |
writeBatchSize | Nombre de lignes de données écrites dans Salesforce pour chaque lot. Nous vous suggérons de définir cette valeur entre 10 000 et 200 000. Un trop petit nombre de lignes dans chaque lot réduit les performances de copie. Un trop grand nombre de lignes dans chaque lot peut entraîner une expiration du délai d’attente de l’API. | Non (la valeur par défaut est 100 000) |
ignoreNullValues | Indique si les valeurs NULL des données d’entrée doivent être ignorées pendant une opération d’écriture. Les valeurs autorisées sont true et false. - True : Conserver les données dans l’objet de destination quand vous effectuez une opération upsert ou de mise à jour. Insérer une valeur définie par défaut lorsque vous effectuez une opération insert. - False : Mettre à jour les données dans l’objet de destination avec la valeur NULL quand vous effectuez une opération upsert ou de mise à jour. Insérer une valeur NULL lorsque vous effectuez une opération insert. |
Non (valeur par défaut : false) |
maxConcurrentConnections | La limite supérieure de connexions simultanées établies au magasin de données pendant l’exécution de l’activité. Spécifiez une valeur uniquement lorsque vous souhaitez limiter les connexions simultanées. | Aucune |
Exemple : Récepteur Salesforce dans une activité de copie
"activities":[
{
"name": "CopyToSalesforce",
"type": "Copy",
"inputs": [
{
"referenceName": "<input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<Salesforce output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "<source type>"
},
"sink": {
"type": "SalesforceV2Sink",
"writeBehavior": "Upsert",
"externalIdFieldName": "CustomerId__c",
"writeBatchSize": 10000,
"ignoreNullValues": true
}
}
}
]
Mappage de type de données pour Salesforce
Lorsque vous copiez des données de Salesforce, les mappages suivants sont utilisés entre les types de données Salesforce et les types de données intermédiaires en interne dans le service. Pour découvrir comment l’activité de copie mappe le schéma et le type de données la source au récepteur, consultez Mappage de schéma dans l’activité de copie.
Type de données Salesforce | Type de données de service intermédiaire |
---|---|
Numérotation automatique | String |
Case à cocher | Boolean |
Devise | Decimal |
Date | DateTime |
Date/Heure | DateTime |
String | |
id | String |
Relation de recherche | String |
Liste déroulante à sélection multiple | String |
Number | Decimal |
Pourcentage | Decimal |
Téléphone | String |
Liste déroulante | String |
Texte | String |
Zone de texte | String |
Zone de texte (long) | String |
Zone de texte (enrichi) | String |
Texte (chiffré) | String |
URL | String |
Notes
Le type numérique Salesforce est mappé au type décimal dans Azure Data Factory et les pipelines Azure Synapse en tant que type de données de service intermédiaire. Le type décimal respecte la précision et l’échelle définies. Pour les données dont le nombre de décimales dépasse l’échelle définie, leur valeur est arrondie dans les données d’aperçu et la copie. Pour éviter une telle perte de précision dans les pipelines Azure Data Factory et Azure Synapse, envisagez d’augmenter le nombre de décimales à une valeur raisonnablement importante dans la page Modification de la définition de champ personnalisé de Salesforce.
Propriétés de l’activité Lookup
Pour en savoir plus sur les propriétés, consultez Activité Lookup.
Mettre à jour le service lié Salesforce
Voici les étapes qui vous aideront à mettre à jour votre service associé et les requêtes associées :
Configurez les applications connectées dans le portail Salesforce en vous référant à Prérequis.
Créez un service lié Salesforce et configurez-le en vous référant à Propriétés du service lié. Vous devez également mettre à jour manuellement les jeux de données existants qui reposent sur l’ancien service lié, en modifiant chaque jeu de données pour utiliser le nouveau service lié à la place.
Si vous utilisez une requête SQL dans la source d’activité de copie ou l’activité de recherche qui fait référence au service lié hérité, vous devez la convertir en requête SOQL. Apprenez-en davantage sur les requêtes SOQL dans Salesforce en tant que type de source et Salesforce Object Query Language (SOQL).
readBehavior est remplacé par includeDeletedObjects dans la source de l’activité de copie ou l’activité de recherche. Pour obtenir la configuration détaillée, consultez Salesforce comme type de source.
Différences entre Salesforce et Salesforce (hérité)
Le connecteur Salesforce offre de nouvelles fonctionnalités et est compatible avec la plupart des fonctionnalités du connecteur Salesforce (hérité). Le tableau ci-dessous présente les différences de fonctionnalités entre Salesforce et Salesforce (hérité).
Salesforce | Salesforce (hérité) |
---|---|
Prendre en charge SOQL dans API en bloc Salesforce 2.0. Pour les requêtes SOQL : • Les clauses GROUP BY, LIMIT, ORDER BY, OFFSET et TYPEOF ne sont pas prises en charge. • Les fonctions d’agrégation telles que COUNT() ne sont pas prises en charge. Vous pouvez utiliser des rapports Salesforce pour les implémenter. • Les fonctions de date dans les clauses GROUP BY ne sont pas prises en charge, mais elles le sont dans la clause WHERE. • Les champs d’adresse composés ou les champs de géolocalisation composés ne sont pas pris en charge. En guise d’alternative, interrogez les composants individuels des champs composés. • Les requêtes de relation parent-enfant ne sont pas prises en charge, tandis que les requêtes de relation enfant-parent le sont. |
Prise en charge de la syntaxe SQL et SOQL. |
Les objets qui contiennent des champs binaires ne sont pas pris en charge lors de la spécification de la requête. | Les objets qui contiennent des champs binaires sont pris en charge lors de la spécification de la requête. |
Prise en charge des objets dans l’API Bulk lors de la spécification d’une requête. | Prennent en charge des objets qui ne sont pas pris en charge avec l’API Bulk lors de la spécification d’une requête. |
Prendre en charge le rapport en sélectionnant un ID de rapport. | Prise en charge de la syntaxe de requête de rapport, par exemple {call "<report name>"} . |
Contenu connexe
Consultez les magasins de données pris en charge pour obtenir la liste des sources et magasins de données pris en charge en tant que récepteurs par l’activité de copie.