Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.
Durée estimée

Environ 25 min

Thèmes

Besoin d'aide ?

Synchronisation des changements hors connexion avec Mobile Sync

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

  • Comprendre les concepts de base de Mobile Sync.
  • Utiliser la bibliothèque Mobile Sync pour synchroniser des données entre l'appareil de l'utilisateur et le serveur Salesforce.

Utilisation de Mobile Sync pour synchroniser les modifications hors connexion

Mobile Sync est une bibliothèque du kit de développement mobile qui fonctionne avec SmartStore pour garantir l’intégrité et la cohérence des enregistrements Salesforce. Mobile Sync permet aux clients utilisant les applications issues du kit de développement mobile de continuer à modifier des enregistrements Salesforce localement lorsque leur appareil mobile n’a plus accès au réseau. Une fois la connectivité rétablie, l’application issue du kit de développement mobile utilise le framework pour synchroniser les modifications locales dans SmartStore avec les enregistrements correspondants sur le serveur Salesforce.

À propos des requêtes réseau

Toutes les requêtes relatives aux données dans les applications Mobile Sync sont asynchrones. Les méthodes de synchronisation formattent la requête et l’envoient vers le cloud Salesforce. Votre application reçoit la réponse du serveur dans une méthode de rappel, un bloc de mise à jour ou une promesse, selon la plate-forme. Les réponses incluent un objet d’état de synchronisation qui décrit les paramètres et le statut de l’opération de synchronisation.

Les méthodes Mobile Sync automatisent les tâches réseau les plus communes, telles que la récupération de métadonnées sObject, la récupération d’une liste des derniers objets utilisés et l’émission de requêtes SOQL et SOSL. Votre application peut appeler des méthodes du gestionnaire de synchronisation à tout moment, mais cela ne fonctionnera évidemment que si l’appareil hôte est connecté à Internet. C’est à votre application de déterminer le statut de connexion de l’appareil.

Configuration d’applications de sorte qu’elles utilisent Mobile Sync

Les applications issues du kit de développement mobile utilisent un objet gestionnaire centralisé du kit de développement pour garantir leur bon démarrage et l’utilisation des bons protocoles d’authentification. Le gestionnaire utilisé par votre application détermine également l’étendue des fonctionnalités du kit de développement incluses dans l’application. Les applications initialisent l'objet MobileSyncSDKManager pendant l’initialisation de l’amorçage.

Les kits de développement natifs Android et iOS implémentent trois objets de gestion.

SalesforceSDKManager

Pour les applications les plus simples. Ces applications n’utilisent pas les fonctionnalités hors ligne du kit de développement mobile.

SmartStoreSDKManager

Pour les applications qui utilisent SmartStore, mais pas Mobile Sync.

MobileSyncSDKManager

Pour les applications qui utilisent SmartStore et Mobile Sync.

Lorsque vous créez une application native avec forcedroid ou forceios, votre nouvelle application est automatiquement configurée de manière à utiliser MobileSyncSDKManager. Ce gestionnaire importe SmartStore, Mobile Sync, et toutes les autres bibliothèques du kit de développement mobile. 

Configuration de la synchronisation

Que vous réalisiez une synchronisation depuis SmartStore vers Salesforce, ou vers SmartStore depuis Salesforce, vous devez fournir les détails de configuration de la synchronisation. Vous pouvez configurer une opération de synchronisation soit dans le code, soit dans un fichier de configuration JSON. Dans les deux cas, au moment de l’exécution, le kit de développement mobile retourne votre configuration à votre application dans un objet d’état de synchronisation.

Au niveau le plus simple, vous devrez fournir :

  • store : indique si le magasin que vous utilisez est un magasin global ou utilisateur. Si vous utilisez un magasin nommé, spécifiez également son nom.
  • soup name : le nom de la soupe qui sert de source dans le cas d’une opération de synchronisation vers le serveur, ou qui reçoit les données dans le cas d’une synchronisation vers l’appareil. Cette soupe doit prendre en charge un champ de chaîne indexée nommé __local__.

Deux autres paramètres supplémentaires définissent l’action de l’opération de synchronisation :

  • target : décrit les enregistrements synchronisés. La cible est la valeur de configuration centrale de toute opération de synchronisation. Vous pouvez voir la cible comme la définition du périmètre de données exigé par votre opération.
  • options : détermine la manière dont l’opération fusionne les données. Dans certains cas, vous pouvez utiliser des options au lieu d’une cible pour donner une liste de noms de champs à synchroniser.

L’utilisation des paramètres target et options diffère entre les opérations de synchronisation vers le serveur et vers l’appareil, comme expliqué dans les sections suivantes. Dans certains cas, l’un ou l’autre de ces paramètres peut être optionnel. Si vous omettez les paramètres facultatifs target ou options, Mobile Sync utilisera une valeur par défaut.

Une fois l’opération de synchronisation terminée, votre application reçoit des notifications asynchrones qui lui permettent de réaliser des tâches de suivi. Ces tâches peuvent inclure l’envoi de notifications d’événements, la consignation des réussites ou l’utilisation des données d’autres manières qui améliorent votre application.

Options et cible de synchronisation vers l’appareil

  • target : spécifie le type du sObject source et les champs à télécharger vers la soupe. Vous pouvez utiliser l’une des chaînes suivantes :
    • Pour les requêtes SOQL : {type:"soql", query:"<soql_query>"}
      Télécharge les sObjects renvoyés par la requête SOQL donnée.
    • Pour les requêtes SOSL : {type:"sosl", query:"<sosl_query>"}
      Télécharge les sObjects renvoyés par la requête SOSL donnée.
    • Pour les requêtes MRU : {type:"mru", sobjectType:"<sobject_type>", fieldlist:"<fields_to_fetch>"}
      Télécharge les champs spécifiés des derniers sObjects utilisés du type de sObject indiqué. Le kit de développement mobile envoie la requête à Salesforce, reçoit la réponse et utilise votre configuration pour remplir votre soupe.
  • options : (facultatif) réalise un mappage avec la clé suivante :
    • mergeMode : pour contrôler la façon dont Mobile Sync fusionne les données avec les soupes locales, définissez cette clé sur l’un des modes suivants :
      Écraser
      (par défaut) Écrase les enregistrements qui ont été modifiés. Si vous ne spécifiez pas de mode de fusion, Mobile Sync écrase les données locales.
      Conserver les modifications
      Préserve les enregistrements ayant été modifiés. Ce mode exige plus d’échanges avec le serveur. Utilisez-le avec prudence.

Options et cible de synchronisation vers le serveur

  • target : réalise un mappage avec l’une des clés suivantes (ou les deux) :
    • createFieldlist : liste des noms, séparés par des virgules, des champs de la soupe dont les valeurs doivent être insérées dans les enregistrements Salesforce venant d’être créés. Peut contenir des champs verrouillés (en lecture seule).
    • updateFieldlist : liste des noms, séparés par des virgules, des champs de la soupe à utiliser pour mettre à jour des champs non verrouillés d’enregistrements Salesforce existants. Ne peut pas contenir de champs verrouillés (en lecture seule).
  • Le paramètre target n’est pas nécessaire pour certaines méthodes de synchronisation. Dans ces cas, vous utilisez la clé fieldlist dans options pour spécifier les champs à synchroniser.
  • options : (facultatif) réalise un mappage avec une ou plusieurs des clés suivantes :
    • fieldlist : liste des noms, séparés par des virgules, des champs de la soupe que vous envoyez vers le serveur. Vous pouvez utiliser cette clé à la place des listes de champs target, ou avec createFieldList dans votre cible. Assurez-vous que votre opération de synchronisation n’essaie pas de mettre à jour des champs en lecture seule sur le serveur.
    • mergeMode : pour contrôler la façon dont Mobile Sync fusionne les données locales avec l’organisation Salesforce, définissez cette clé sur l’un des modes suivants :
      Écraser
      (Paramètre par défaut) Écrase les enregistrements de serveur qui ont été modifiés.
      Conserver les modifications
      Préserve les enregistrements du serveur ayant été modifiés. Ce mode exige plus d’échanges avec le serveur. Utilisez-le avec prudence.

Paramètre de magasin

Les applications hybrides et React Native indiquent quel magasin elles utilisent dans un paramètre storeConfig optionnel. Ce paramètre s’applique aux opérations de synchronisation vers le serveur et vers l’appareil. Vous pouvez le spécifier de deux manières différentes.

Sous forme de map contenant les paires clé-valeur suivantes :

  • isGlobalStore (facultatif) : valeur booléenne indiquant si vous utilisez un magasin global (true) ou un magasin utilisateur (false). La valeur par défaut est false.
  • storeName (facultatif) : nom du magasin. La valeur par défaut est le nom du magasin par défaut.

Par exemple :

{"isGlobalStore" : false, "storeName" : "MyStore"}

Sous forme de booléen :

Vous pouvez également passer une simple valeur booléenne. Dans ce cas, le kit de développement mobile attribue la valeur à la clé isGlobalStore.

Si vous omettez le paramètre store, Mobile Sync effectue l’opération sur le magasin de l’utilisateur actuel.

Utilisation des synchronisations nommées et des fichiers de configuration de synchronisation

Les méthodes standard de synchronisation vers le serveur et vers l’appareil exigent que vous passiez chaque paramètre de synchronisation sous forme d’argument séparé. Le kit de développement mobile propose deux fonctionnalités qui vous aident à organiser et simplifier les efforts de synchronisation. Ces fonctionnalités sont les noms de synchronisation et les fichiers de configuration de synchronisation. Elles vous apportent beaucoup de confort en échange de peu d’efforts. Bien qu’il ne soit pas obligatoire d’utiliser des fichiers de configuration, nous les utiliserons fréquemment dans ce parcours.

Pour exécuter à nouveau une synchronisation, vous devez utiliser la méthode reSync de la plate-forme. Les méthodes de resynchronisation utilisent l’un des identifiants suivants pour chercher votre configuration :

  • Identifiant de synchronisation : chaque méthode de synchronisation renvoie un identifiant d’exécution dans un objet d’état. Vous pouvez transmettre cet identifiant à reSync pour exécuter à nouveau une synchronisation que vous avez déjà utilisée dans la session en cours.
  • Nom de synchronisation (facultatif) : vous pouvez nommer une configuration de synchronisation et la garder en mémoire lorsque vous l’exécutez pour la première fois ou bien vous pouvez importer le nom et sa configuration de synchronisation depuis un fichier JSON externe.

Noms de synchronisation

Les opérations de synchronisation peuvent être compliquées à configurer, et il est fréquent qu’elles soient réutilisées. Les noms de synchronisation vous permettent de réexécuter vos synchronisations sans avoir à les coder à nouveau. Par exemple, vous pouvez utiliser les noms de synchronisation aux fins suivantes :

  • Configurer des opérations de synchronisation dans un fichier JSON externe plutôt que dans le code
  • Exécuter à nouveau une opération de synchronisation précédemment utilisée sans la configurer à nouveau
  • Obtenir le statut d’une opération de synchronisation en cours
  • Vérifier l’existence d’une configuration de synchronisation
  • Supprimer une configuration de synchronisation

Vous pouvez créer des synchronisations nommées soit avec l’API, soit dans des fichiers de configuration de synchronisation. Le kit de développement mobile prend en charge les synchronisations nommées sur toutes les plates-formes et pour tous les types d’application.

Fichiers de configuration de synchronisation

Avec les fichiers de configuration de synchronisation, vous pouvez écrire des définitions de synchronisation statique vers le serveur et vers l’appareil une seule fois dans un fichier JSON, puis les importer dans toutes les versions de vos applications. Mobile SDK prend en charge les fichiers de configuration de synchronisation dans les applications natives et hybrides. Étudions la structure et les règles de ces fichiers.

Noms des fichiers

Le kit de développement mobile prend en charge les fichiers de configuration uniquement pour le magasin global par défaut et le magasin utilisateur par défaut.

  • Pour le magasin global par défaut, vous devez fournir un fichier appelé globalsyncs.json.
  • Pour le magasin utilisateur par défaut, vous devez fournir un fichier appelé usersyncs.json.

Emplacement des fichiers

Placez vos fichiers de configuration aux emplacements suivants.
iOS :

  • Applications natives et React Native : / dans le paquet Ressources
  • Applications hybrides : /www dans le paquet Ressources

Android :

  • Applications natives et React Native : /res/raw
  • Applications hybrides : /assets/www

Format de fichier

Le format de fichier est identique quel que soit le type d’application ou la plate-forme cible. Une définition de synchronisation a besoin de cinq champs :

  • Nom de synchronisation
  • Type de synchronisation
  • Nom de la soupe
  • Cible
  • Options

Le fichier de configuration suivant définit les opérations de synchronisation vers le serveur et vers l’appareil. Les deux fichiers de configuration utilisent les mêmes champs : Id, Name, et LastModifiedDate. Cependant, notez ces deux règles importantes de positionnement des valeurs :

  • La configuration de synchronisation vers l’appareil spécifie les champs dans la partie « cible », au moyen d’une requête SOQL, tandis que la synchronisation vers le serveur les spécifie dans les « options » sous forme de liste.
  • L’opération de synchronisation vers l’appareil spécifie son mode de fusion dans les « options », tandis que la synchronisation vers le serveur le fait dans « merge_mode ».

Des modes de fusion opposés (par exemple « OVERWRITE » pour la synchronisation vers l’appareil et « LEAVE_IF_CHANGED » pour la synchronisation vers le serveur) garantissent l’existence d’une source unique de vérité. Dans ce cas, ils permettent aux données du serveur d’écraser les données de la soupe, mais pas l’inverse.

{
  "syncs": [
    {
      "syncName": "sync1",
      "syncType": "syncDown",
      "soupName": "accounts",
      "target": {"type":"soql", "query":"SELECT Id, Name, LastModifiedDate 
        FROM Account"},
      "options": {"mergeMode":"OVERWRITE"} 
    },
    {
      "syncName": "sync2",
      "syncType": "syncUp",
      "soupName": "accounts",
      "target": {"createFieldlist":["Name"]},
      "options": {"fieldlist":["Id", "Name", "LastModifiedDate"],
      "mergeMode":"LEAVE_IF_CHANGED"}
    }
  ]
 }

Utilisation de Mobile Sync avec un porte-documents

Un porte-documents est un ensemble de requêtes qui sélectionnent un ensemble cohérent d’enregistrements associés, optimisé pour répondre à vos besoins. Vous pouvez utiliser des porte-documents afin de sélectionner des enregistrements pour la préparation des données avant la mise hors ligne et à d’autres fins générales de chargement de données.

Configuration de la synchronisation

Dans l’application modèle MobileSyncExplorer, vous pouvez mettre à jour le fichier JSON de la synchronisation utilisateur pour configurer vos opérations de synchronisation vers le serveur et vers l’appareil. 

Pour la propriété "target", spécifiez les valeurs suivantes.

Propriétés de target

"type":"briefcase"

"infos": tableau d’éléments <BriefcaseObjectInfo>

Tableau d’objets décrivant les sObjects et les champs spécifiques à extraire, ainsi que la soupe dans laquelle les placer.

Propriétés de BriefcaseObjectInfo

"soupName": <string>

Nom de la soupe ou de la table dans laquelle stocker les enregistrements de ce type d’objet pendant la synchronisation.

"sobjectType": <string>

Nom d’un objet Salesforce à synchroniser.

"fieldlist": tableau de <chaînes>

Liste des champs à synchroniser pour cet objet.

"idFieldName": <string>

(Facultatif) Nom d’un champ d’ID personnalisé. Si vous fournissez "idFieldName", Mobile Sync utilise le champ avec le nom donné pour obtenir l’ID de l’enregistrement. Par exemple, si vous spécifiez "idFieldName":"AcmeId", Mobile Sync obtient l’ID de l’enregistrement à partir du champ AcmeId plutôt qu’à partir du champ Id par défaut.

"modificationDateFieldName": <string>

(Facultatif) Nom du champ contenant la date de dernière modification de l’enregistrement. Si vous fournissez modificationDateFieldName, Mobile Sync utilise le champ portant ce nom pour calculer la valeur maxTimestamp que startFetch utilise pour resynchroniser les enregistrements. Le nom de champ par défaut est lastModifiedDate.

Obligatoire : "soupName", "sobjectType", "fieldlist"

Synchronisation serveur-appareil

Remarque

Si votre organisation utilise des porte-documents pour vos utilisateurs mobiles, la cible de synchronisation de porte-documents vers l’appareil a été introduite dans Mobile SDK 10.1.

Examinons un exemple de fichier de porte-documents configuré pour la synchronisation vers l’appareil. 

{
  "syncs": [
    {
      "syncName": "syncDownContacts", 
      "syncType": "syncDown",
      "soupName": "contacts",
      "target": {
        "type": "briefcase",      
        "infos": [
          {
            "sobjectType": "Account",
            "fieldlist": [
              "Name",
              "Description"
            ],
            "soupName": "accounts"
          },
          {
            "sobjectType": "Contact",
            "fieldlist": [
              “FistName”, "LastName", “Title”, “Email”
            ],
            "soupName": "contacts"
          }
        ]
      },
      "options": {
        "mergeMode": "OVERWRITE"
      }
    }
  ]
}

Pour effectuer une synchronisation vers l’appareil, définissez "syncType" sur "syncDown". Cette opération active l’opération de synchronisation vers l’appareil, qui synchronise les données du serveur vers le client. Vous pouvez nommer l’opération de synchronisation vers l’appareil à côté de "syncName". Dans ce cas, il a été nommé "syncDownContacts". 

À côté de "soupName", définissez la table ou la soupe que vous souhaitez mettre à jour lors de l’exécution de l’opération de synchronisation vers l’appareil. Dans ce cas, la soupe à mettre à jour s’appelle "contacts".

Sous "target", définissez le type de cible sur "briefcase". Sous l’objet JSON "infos", vous pouvez définir les entités que vous souhaitez synchroniser, dans ce cas : "Account" et "Contact". Pour chaque entité, indiquez les champs que vous souhaitez synchroniser dans "fieldlist". 

Pour chaque entité, indiquez la table correspondante que vous souhaitez mettre à jour sur le client à côté de "soupName".  

Sous "options", vous pouvez définir l’option "mergeMode", qui dans ce cas est définie sur "OVERWRITE". Si deux utilisateurs tentent de mettre à jour le même enregistrement, cette option donne la priorité au dernier utilisateur qui l’a mis à jour.

Synchronisation appareil-serveur

Examinons maintenant la configuration pour la synchronisation.

{
“syncName: “syncUpContacts”,
“syncType”: “syncUp”,
“soupÑame”: “contacts”,
“target”: {
	“createFieldlist”: [
		“FirstName”, “LastName”, “Title”, “Email”
	]
},
“options”: {
	“fieldlist”: [
		“FirstName”, “LastName”, “Title”, “Email”
	],
	“mergeMode”: “LEAVE_IF_CHANGED”
}
}

Pour utiliser l’opération de synchronisation vers le serveur, configurez la table souhaitée via "soupName", qui dans ce cas s’appelle "contacts". Utilisez "target" et "options" pour désigner les champs que vous souhaitez synchroniser. Dans ce cas, "mergeMode" est défini sur "LEAVE_IF_CHANGED". Si un enregistrement de serveur a été modifié depuis sa synchronisation vers l’appareil de ce client, les enregistrements de serveur et de client restent leur état actuel.

Utilisation de Mobile Sync dans les applications iOS natives

Synchronisation serveur-appareil

Pour télécharger des enregistrements Salesforce vers votre soupe SmartStore, Mobile Sync vous offre plusieurs options.

Vous pouvez créer une configuration de synchronisation vers l’appareil sans l’exécuter :

var syncState = syncManager.createSyncDown(target: target, options: options, 
    soupName: CONTACTS_SOUP, syncName: syncState.syncName)

Ou vous pouvez créer et exécuter une opération non nommée de synchronisation vers l’appareil sans option, mais soyez conscient qu’elle écrasera tous les changements locaux :

var syncState = syncManager.syncDown(target: target, soupName: CONTACTS_SOUP, onUpdate:updateFunc)

Pour plus de contrôle, vous pouvez créer et exécuter une configuration non nommée de synchronisation vers l’appareil en définissant vos propres options :

var syncState = syncManager.syncDown(target: target, options: options, 
    soupName: CONTACTS_SOUP, onUpdate:updateFunc)

Ou vous pouvez créer, nommer et exécuter une configuration de synchronisation vers l’appareil :

var syncState = try syncManager.syncDown(target: target, options: options, 
    soupName: CONTACTS_SOUP, syncName: syncState.syncName, onUpdate:updateFunc)

La classe SyncTarget propose des méthodes de fabrique permettant la création d’objets cibles à partir d’une chaîne de requête SOQL, SOSL ou MRU. Vous spécifiez les objets à télécharger avec une chaîne de requête SOQL ou SOSL. Si vous utilisez une cible de requête MRU, vous spécifiez seulement une liste de noms de champs. Le kit de développement mobile transmet la progression de l’opération de synchronisation au moyen de la méthode de rappel ou du bloc de mise à jour que vous implémentez.

Pour les applications iOS natives, l’option mergeMode peut avoir l’une des valeurs suivantes :

  • SFSyncStateMergeModeOverwrite : écraser les enregistrements modifiés en local et perdre toutes ces modifications.
  • SFSyncStateMergeModeLeaveIfChanged : conserver tous les changements effectués en local, ainsi que les enregistrements modifiés.
Remarque

La méthode syncDown(target:soupName:onUpdate:), qui n’accepte pas de paramètres d’option, peut remplacer les sObjects existants dans la mémoire cache. Dans ce cas, pour conserver les changements effectués en local, synchronisez toujours depuis l'appareil vers le serveur avant de synchroniser du serveur vers l'appareil.

Synchronisation appareil-serveur

Au cours de la synchronisation vers le serveur, Mobile Sync réplique sur le serveur les créations, mises à jour et suppressions d’enregistrements ayant eu dans la soupe. Le kit de développement mobile offre une cible par défaut que vous pouvez utiliser au lieu de définir la vôtre. La cible par défaut est simple et directe : grâce à l’API Salesforce, elle synchronise simplement tous les enregistrements modifiés de la soupe vers le serveur.

Si vous avez une cible, vous pouvez créer une opération de synchronisation sans l’exécuter :

let syncState = syncManager.createSyncUp(target: target, options: options, 
    soupName: CONTACTS_SOUP, syncName: syncState.syncName)

Vous pouvez utiliser la cible par défaut avec la méthode MobileSyncManager suivante :

let syncState = syncManager.syncUp(options: options, soupName: CONTACTS_SOUP, 
    onUpdate: updateFunc)

Si vous disposez d’une cible de synchronisation vers le serveur personnalisée, vous pouvez l’exécuter en appelant la méthode suivante :

let syncState = syncManager.syncUp(target: target, options: options, 
    soupName: CONTACTS_SOUP, onUpdate: updateFunc)

Ou vous pouvez créer, nommer et exécuter une opération de synchronisation :

let syncState = 
    try syncManager.syncUp(target: target, options: options, 
        soupName: CONTACTS_SOUP, syncName: syncState.syncName, 
        onUpdate: updateFunc)

Resynchronisation

Les méthodes de resynchronisation, polyvalentes et faciles à utiliser, sont parfois négligées alors qu’elles jouent un rôle important. Ces méthodes exécutent des configuration de synchronisation définies auparavant. En dépit de leur nom, il est possible d’utiliser ces méthodes pour exécuter une synchronisation nommée pour la première fois. Les méthodes de resynchronisation ne synchronisent que les enregistrements qui ont été créés ou mis à jour depuis la dernière synchronisation. Si la synchronisation n’a jamais été exécutée, resync copie tous les enregistrements nouveaux ou modifiés. Sinon, il procède à une synchronisation incrémentale.

Pour utiliser les méthodes de resynchronisation, donnez soit l’identifiant d’une synchronisation précédente, soit un nom de synchronisation prédéfini. Pour exécuter une synchronisation nommée existante :

var syncState = 
    try syncManager.reSync(named: syncState.syncName, onUpdate: updateFunc)

Si vous avez mis en cache la valeur SFSyncState.syncId renvoyée par une opération de synchronisation antérieure sans nom, vous pouvez l’utiliser pour exécuter à nouveau cette synchronisation :

var syncState = 
    try syncManager.reSync(id: syncState.syncId, onUpdate: updateFunc)

Les méthodes reSync prennent en charge les configurations vers le serveur et vers l’appareil.

Exemple

Les applications Swift natives créées par forceios emploient un modèle qui dispose des fonctionnalités de base de SmartStore et de Mobile Sync. Ce modèle utilise les éditeurs Combine pour SmartStore et Mobile Sync afin de simplifier son code. Ces éditeurs sont disponibles dans le kit de développement mobile en tant qu’extensions des classes SmartStore et MobileSync. Examinons cette implémentation telle que réalisée dans le projet iOSNativeSwiftTemplate. 

Tout d’abord, créez une application que vous utiliserez à des fins d’exploration.

  1. Dans une fenêtre de terminal, créez une application avec forceios.
    • Utilisez le type d’application native_swift.
    • Pour plus de facilité, nommez l’application offlineSwift.
  2. Une fois que forceios a terminé, ouvrez le nouvel espace de travail dans Xcode.

Dans Xcode, vérifiez la configuration des fonctionnalités hors ligne.

  1. Dans le navigateur de projet (⌘1), développez offlineSwift > offlineSwift > Fichiers de support. Vous y trouvez les fichiers userstore.json et usersyncs.json. Si vous les ouvrez dans l’éditeur, vous pouvez voir qu’ils définissent des configurations de base relatives à l’accès et à la synchronisation des enregistrements de compte.
  2. Le modèle ajoute userstore.json et usersyncs.json au paquet de l’application dans les paramètres Phases de création du projet. 
    1. Dans le navigateur de projet Xcode, sélectionnez le nœud du projet.
    2. Dans la fenêtre de l’éditeur, sélectionnez Build Phases.
    3. Agrandissez Copy Bundle Resources. Notez que userstore.json et usersyncs.json sont répertoriés, ce qui signifie qu’ils sont ajoutés au paquet de l’application lors de la création de l’application.

Maintenant, examinons le code.

  1. Dans le navigateur de projet, développez offlineSwift > offlineSwift > Classes > SwiftUI.
  2. Dans SceneDelegate.swift, le modèle ajoute une fonction setupRootViewController() qui charge les configurations hors ligne en mémoire. Cette fonction est appelée de manière intentionnelle une seule fois par session utilisateur. Vous ne devez pas oublier que vous ne pouvez ni appeler ces méthodes de configuration plus d’une fois par session, ni les utiliser pour charger un ensemble différent de configurations. 
    // Set up store based on config userstore.json
MobileSyncSDKManager.shared.setupUserStoreFromDefaultConfig()
// Set up syncs based on config usersyncs.json
MobileSyncSDKManager.shared.setupUserSyncsFromDefaultConfig()
  3. Dans le navigateur de projet, développez offlineSwift > offlineSwift > Classes > Modèles.
  4. Dans AccountsListModel.swift, prêtez attention à la première ligne de la classe AccountsListModel. Cette ligne définit un tableau publié vide d’objets de compte. Les objets SwiftUI dans l’application s’abonnent à AccountsListModel pour recevoir des mises à jour lorsque le tableau publié est sujet à des modifications.
    /**
ViewModel for Account List
*/
class AccountsListModel: ObservableObject {
  @Published var accounts: [Account] = []
  ...
  5. Cherchez la fonction fetchAccounts().
    func fetchAccounts(){
  syncTaskCancellable = syncManager?.publisher(for: "syncDownAccounts")
    .receive(on: RunLoop.main)
    .sink(receiveCompletion: { _ in }, receiveValue: { _ in
      self.loadFromSmartStore()
  })
  self.loadFromSmartStore()
}
    Dans notre cas, l’éditeur Mobile Sync traite une opération de synchronisation nommée (« syncDownAccounts », définie dans usersyncs.json) et la synchronise à nouveau. L’éditeur copie ensuite les données renvoyées dans les soupes du magasin SmartStore par défaut. Lorsque fetchAccounts() reçoit la réponse de l’éditeur, il appelle loadFromSmartStore() pour copier de manière asynchrone les données actualisées issues de SmartStore dans le tableau publié accounts. En attendant la réponse, fetchAccounts() appelle aussi loadFromSmartStore() pour s’assurer que le tableau accounts est à jour et comporte toutes les modifications locales. Voyons comment loadFromSmartStore() effectue ces mises à jour.
  6. La fonction loadFromSmartStore() utilise l’éditeur SmartStore pour émettre une requête Smart SQL et recevoir la réponse asynchrone. Si la réponse indique une réussite, la fonction publie l’ensemble de données résultant auprès de l’appelant. L’appelant copie alors la réponse analysée dans le tableau accounts sur l’objet AccountsListModel.  
    import MobileSync
...
private func loadFromSmartStore() {
  storeTaskCancellable = self.store?.publisher(for: "select {Account:Name}, {Account:Industry}, {Account:Id} from {Account}")
  .receive(on: RunLoop.main)
  .tryMap {
    $0.map { (row) -> Account in
      let r = row as! [String?]
      return Account(id: r[2] ?? "", name: r[0] ?? "", industry: r[1] ?? "Unknown Industry" )
    }
  }
  .catch { error -> Just<[Account]> in
    print(error)
    return Just([Account]())
  }
  .assign(to: \AccountsListModel.accounts, on:self)
} 

Lorsque le tableau accounts est renseigné, l’application peut poursuivre sa logique principale, qui, dans ce cas, consiste à : 

  • afficher les comptes interrogés et leurs détails ;
  • pour tout compte sélectionné par le client, interroger puis afficher les contacts et leurs détails.

Utilisation de Mobile Sync dans les applications Android natives

Synchronisation serveur-appareil

Pour télécharger des sObjects depuis le serveur vers votre soupe Mobile Sync locale, utilisez l’une des méthodes SyncManager suivantes :

Vous pouvez créer une configuration de synchronisation vers l’appareil sans l’exécuter :

public SyncState createSyncDown(SyncDownTarget target, 
    SyncOptions options, String soupName, String syncName) 
    throws JSONException;

Ou vous pouvez créer et exécuter une opération non nommée de synchronisation vers l’appareil sans option, mais soyez conscient qu’elle écrasera tous les changements locaux :

public SyncState syncDown(SyncDownTarget target, String soupName, 
    SyncUpdateCallback callback) throws JSONException;

Pour plus de contrôle, vous pouvez créer et exécuter une opération non nommée de synchronisation vers l’appareil en définissant vos propres options de fusion :

public SyncState syncDown(SyncDownTarget target, SyncOptions options,
    String soupName, SyncUpdateCallback callback) 
    throws JSONException;

Ou vous pouvez nommer la configuration de synchronisation vers l’appareil lors de la création, puis l’exécuter :

public SyncState syncDown(SyncDownTarget target, SyncOptions options, 
    String soupName, SyncUpdateCallback callback) 
    throws JSONException;

Synchronisation appareil-serveur

Pour appliquer au serveur des changements effectués en local, utilisez l’une des méthodes SyncManager suivantes :

  • Vous pouvez créer une configuration nommée de synchronisation vers le serveur sans l’exécuter :
    public SyncState createSyncUp(SyncUpTarget target, 
    SyncOptions options, 
    String soupName, 
    String syncName) 
    throws JSONException;
  • Vous pouvez créer et exécuter une configuration non nommée de synchronisation d’un seul appel :
    public SyncState syncUp(SyncUpTarget target, 
    SyncOptions options, 
    String soupName, 
    SyncUpdateCallback callback) 
    throws JSONException;
  • Ou vous pouvez créer et exécuter une configuration nommée de synchronisation vers le serveur d’un seul appel :
    public SyncState syncUp(SyncUpTarget target, 
    SyncOptions options, 
    String soupName, 
    String syncName, 
    SyncUpdateCallback callback) 
    throws JSONException;

Les méthodes syncUp permettent de mettre à jour le serveur avec les données d’une soupe SmartStore spécifique. Elles recherchent les enregistrements créés, mis à jour ou supprimés dans la soupe et répercutent ces changements sur le serveur. C’est le paramètre target ou options, ou les deux, qui spécifie la liste des champs à télécharger. Une cible vous permet de distinguer entre createFieldlist pour créer des enregistrements et updateFieldlist pour mettre à jour des enregistrements existants. Ces réglages vous permettent de synchroniser de nouveaux enregistrements tout en évitant d’essayer de mettre à jour des champs en lecture seule dans les enregistrements existants. Si vous définissez des listes de champs dans target et dans options, le paramètre options est ignoré.

Resynchronisation

Le couple de méthodes de resynchronisation est important et parfois négligé, alors qu’elles sont polyvalentes et faciles à utiliser. Ces méthodes exécutent des configuration de synchronisation définies auparavant. En dépit de leur nom, il est également possible d’utiliser ces méthodes pour exécuter une synchronisation nommée pour la première fois. Lors des exécutions suivantes, les méthodes de resynchronisation ne synchroniseront que les enregistrements qui ont été créés ou mis à jour depuis la dernière synchronisation. Si la synchronisation n’a jamais été exécutée, resync copie tous les enregistrements nouveaux ou modifiés. Sinon, il procède à une synchronisation incrémentale.

Pour utiliser les méthodes de resynchronisation, donnez soit l’identifiant d’une synchronisation précédente, soit un nom de synchronisation prédéfini. Pour exécuter une synchronisation nommée :

public SyncState reSync(String syncName, SyncUpdateCallback callback) 
    throws JSONException;

Si vous avez mis en cache la valeur SFSyncState.syncId d’une opération de synchronisation préalable, vous pouvez exécuter à nouveau cette synchronisation avec reSync:updateBlock: :

public SyncState reSync(long syncId, SyncUpdateCallback callback) 
    throws JSONException;

Les méthodes reSync prennent en charge les configurations vers le serveur et vers l’appareil.

Exemple

Pour Android, l’exemple d’application native MobileSyncExplorer montre comment utiliser les synchronisations nommées et les fichiers de configuration avec les enregistrements de contact. Elle définit une classe ContactObject qui représente un enregistrement de contact Salesforce sous forme d’un objet Java. Pour synchroniser les données de contact vers la soupe SmartStore, la méthode syncDown() synchronise à nouveau une configuration nommée de synchronisation vers l’appareil qui définit une requête SOQL.

Cette application stocke les fichiers userstore.json et usersyncs.json dans le dossier de projet /res/raw. Voici userstore.json :

{
  "soups": [
    {
      "soupName": "contacts",
      "indexes": [
        { "path": "Id", "type": "string"},
        { "path": "FirstName", "type": "string"},
        { "path": "LastName", "type": "string"},
        { "path": "__local__", "type": "string"},
        { "path": "__locally_created__", "type": "string"},
        { "path": "__locally_updated__", "type": "string"},
        { "path": "__locally_deleted__", "type": "string"},
        { "path": "__sync_id__", "type": "integer"}
      ]
    }
  ]
}

Maintenant, voici usersyncs.json :

{
  "syncs": [
    {
      "syncName": "syncDownContacts",
      "syncType": "syncDown",
      "soupName": "contacts",
      "target": {"type":"soql", "query":"SELECT FirstName, LastName, Title, MobilePhone, Email, Department, HomePhone FROM Contact LIMIT 10000"},
      "options": {"mergeMode":"OVERWRITE"}
    },
    {
      "syncName": "syncUpContacts",
      "syncType": "syncUp",
      "soupName": "contacts",
      "target": {"createFieldlist":["FirstName", "LastName", "Title", "MobilePhone", "Email", "Department", "HomePhone"]},
      "options": {"fieldlist":["Id", "FirstName", "LastName", "Title", "MobilePhone", "Email", "Department", "HomePhone"], "mergeMode":"LEAVE_IF_CHANGED"}
    }
  ]
 }

Cet exemple d’application charge ces fichiers en mémoire dans son constructeur ContactListLoader. 

public ContactListLoader(Context context, UserAccount account) {
  super(context);
  MobileSyncSDKManager sdkManager = MobileSyncSDKManager.getInstance();
  smartStore = sdkManager.getSmartStore(account);
  syncMgr = SyncManager.getInstance(account);
  // Setup schema if needed
  sdkManager.setupUserStoreFromDefaultConfig();
  // Setup syncs if needed
  sdkManager.setupUserSyncsFromDefaultConfig();
}

Dans la méthode suivante de la classe ContactListLoader, la méthode locale syncDown() exécute reSync() avec la configuration syncDownContacts :

public synchronized void syncDown() {
    
    try {
      syncMgr.reSync(SYNC_DOWN_NAME /* see usersyncs.json */, new SyncUpdateCallback() {
            @Override
            public void onUpdate(SyncState sync) {
                if (Status.DONE.equals(sync.getStatus())) {
                    fireLoadCompleteIntent();
                }
            }
        });
    } catch (JSONException e) {
        Log.e(TAG, "JSONException occurred while parsing", e);
    } catch (MobileSyncException e) {
        Log.e(TAG, "MobileSyncException occurred while attempting to sync down", e);
    }
 
}

Si l’opération de synchronisation vers l’appareil réussit, c’est-à-dire si sync.getStatus() renvoie Status.DONE, les données reçues sont enregistrées dans la soupe spécifiée. La méthode de rappel déclenche ensuite une intention qui recharge les données dans la liste Contact.

De même, la méthode locale syncUp() de ContactListLoader exécute reSync() avec la configuration syncUpContacts :

public synchronized void syncUp() {
       
    try {
        
        syncMgr.reSync(SYNC_UP_NAME /* see usersyncs.json */, new SyncUpdateCallback() { 
            new SyncUpdateCallback() {

            
                @Override
            
                public void onUpdate(SyncState sync) {
                
                    if (Status.DONE.equals(sync.getStatus())) {
                    
                        syncDown();
                
                    }
            
                }
        
            });
    
    } catch (JSONException e) {
           
        Log.e(TAG, "JSONException occurred while parsing", e);
    
    } catch (MobileSyncException e) {
           
        Log.e(TAG, "MobileSyncException occurred while attempting to sync up", e);
    
    }

 }

Lorsque la réponse asynchrone renvoie Status.DONE, l’implémentation SyncUpdateCallback ici présente effectue une action supplémentaire et appelle syncDown(). Cette étape, dont la réalisation est recommandée, garantit que la soupe SmartStore soit toujours à jour, ainsi que tout changement récemment apporté aux contacts sur le serveur soit pris en compte.

Utilisation de Mobile Sync dans les applications hybrides

Mobile Sync propose deux approches différentes pour les applications hybrides.

  • com.salesforce.plugin.mobilesync : ce plug-in Cordova offre un accès JavaScript aux fonctionnalités natives de synchronisation vers l’appareil et vers le serveur de Mobile Sync. Par conséquent, les opérations gourmandes en performances (négociations sur le réseau, analyse, gestion de SmartStore) sont exécutées sur des threads natifs qui n’ont aucun impact sur l’affichage des pages Internet. Utilisez le plug-in dans des scénarios plus simples, par exemple pour synchroniser rapidement un grand nombre d’enregistrements dans ce flux natif plutôt que dans une vue Web.
  • mobilesync.js : cette bibliothèque JavaScript propose une infrastructure de données Force SObject permettant des opérations de synchronisation plus complexes. La bibliothèque s’appuie sur Backbone.js, un système JavaScript de source ouverte qui définit un mécanisme extensible de modelage des données. Avec mobilesync.js, vous pouvez créer des modèles d’objets Salesforce et manipuler leurs enregistrements en changeant simplement les données du modèle. Si vous exécutez une requête SOQL ou SOSL, vous en recevrez les enregistrements sous la forme d'une collection modèle plutôt que d'une chaîne JSON.

Combiner ces approches dans une même application donne d’excellents résultats. Par exemple, le plug-in expose deux méthodes : syncDown() et syncUp(). Lorsque vous utilisez ces méthodes, les recommandations suivantes peuvent vous simplifier la vie :

  • Pour créer, mettre à jour ou supprimer des enregistrements dans des soupes SmartStore, exécutez Force.SObject à partir de mobilesync.js. La bibliothèque mobilesync.js crée automatiquement des champs spéciaux dans les enregistrements issus de soupes attendus par le plug-in. Vous pouvez ensuite appeler syncUp() sur le plug-in pour mettre à jour le serveur.
  • De la même manière, pour créer la soupe qui sera utilisée dans le cadre de vos opérations de synchronisation, exécutez Force.StoreCache à partir de mobilesync.js.
  • Dans le cas où vous auriez modifié des objets dans la soupe, appelez toujours syncUp() avant syncDown().

Les applications hybrides créées avec forcehybrid comprennent automatiquement le plug-in Mobile Sync.

Synchronisation serveur-appareil

Voici la méthode du plug-in Mobile Sync syncDown().

cordova.require("com.salesforce.plugin.mobilesync").syncDown
    ([storeConfig,] target, soupName, options, [syncName,] success, error);

Si vous avez défini un nom de synchronisation pour cette configuration, vous pouvez l’indiquer. Vous pouvez définir des noms de synchronisation dans un fichier de configuration usersyncs.json que vous intégrez au niveau supérieur de votre application Web.

Pour l’option de fusion par défaut, les applications hybrides doivent utiliser ces identifiants.

  • {mergeMode:Force.MERGE_MODE_DOWNLOAD.OVERWRITE} (par défaut)
  • {mergeMode:Force.MERGE_MODE_DOWNLOAD.LEAVE_IF_CHANGED}

La paramètre success spécifie une fonction de rappel qui est appelée plusieurs fois au cours de l’opération de synchronisation :

  • Au début de l'opération de synchronisation
  • Lorsque la requête REST interne est terminée
  • Après le téléchargement de chaque page de résultats et jusqu'à ce que tous les résultats aient été reçus

Au cours de l’exécution de l’opération de synchronisation, les mises à jour de statut sont envoyées via des événements du navigateur. Pour surveiller ces mises à jours, implémentez l’écouteur d’événement suivant :

document.addEventListener("sync",
   function(event)
      {
         // event.detail contains the status of the sync operation
      }
 );

Le membre event.detail vous apporte les métadonnées de synchronisation et, plus important, les informations sur la progression et l’état actuel de l’opération :

  • syncId : ID de cette opération de synchronisation
  • type : synchronisation serveur-appareil
  • target : cible que vous avez indiquée
  • soupName : nom de soupe que vous avez indiqué
  • options : tableau contenant les options que vous avez spécifiées
  • status : statut de synchronisation, qui peut correspondre à l’un des éléments suivants :
    1. NEW
    2. RUNNING
    3. DONE
    4. FAILED
  • progress : pourcentage du nombre total d’enregistrements traités jusqu’à présent (entier de 0 à 100)
  • totalSize : nombre d’enregistrements traités jusqu’à présent

Stocker l’identifiant de synchronisation est une bonne idée. Vous pourrez utiliser cette valeur ultérieurement pour réexécuter l’opération de synchronisation.

Synchronisation appareil-serveur

La méthode syncUp() du plug-in Mobile Sync réplique des enregistrements créés, supprimés ou mis à jour dans une soupe SmartStore, vers le serveur Salesforce.

cordova.require("com.salesforce.plugin.mobilesync").syncUp
   ([storeConfig,] [target,] soupName, options, [syncName,] successCb, errorCb);

C’est à vous de fournir les paramètres de configuration de l’opération, notamment

  • target : si vous avez défini une cible de synchronisation appareil-serveur native personnalisée, utilisez ce paramètre pour identifier sa classe.
  • syncName : si vous avez défini un nom de synchronisation pour cette configuration, vous pouvez l’indiquer. Vous pouvez définir des noms de synchronisation dans un fichier de configuration usersyncs.json que vous intégrez au niveau supérieur de votre application Web.
  • options : contient une carte avec la clé suivante :
    1. fieldlist : liste de champs envoyés au serveur.
  • successCb, errorCb : fonctions de rappel de succès ou d'erreur.

Les mises à jour du statut de l’opération de synchronisation arrivent par le même gestionnaire d’événement que vous avez implémenté pour syncDown.

document.addEventListener("sync",
   function(event)
      {
         // event.detail contains the status of the sync operation
      }
 );

Comme dans les opérations de synchronisation vers l’appareil, le membre event.detail vous donne des métadonnées et des rapports sur le statut et la progression actuelle de l’opération.

Resynchronisation

Comme dans les applications natives, la méthode reSync offre une plus grande flexibilité et de meilleures performances et elle facilite le codage. Si le nom de synchronisation que vous fournissez n’a pas déjà été synchronisé, reSync() effectue une synchronisation complète. Sinon, elle effectue seulement une synchronisation incrémentielle des enregistrements qui ont été créés, modifiés ou supprimés.

cordova.require("com.salesforce.plugin.mobilesync").reSync([storeConfig], syncIdOrName, successCB, errorCB)

C’est à vous de fournir les paramètres de configuration de l’opération, notamment

  • syncIdOrName : l’identifiant de cette opération de synchronisation ou un nom de synchronisation pour votre fichier usersyncs.json.
  • successCb, errorCb : fonctions de rappel de succès ou d'erreur.

Exemple

Cet exemple utilise les synchronisations nommées définies dans le fichier usersyncs.json suivant. Vous pouvez trouver le code source complet dans le dépôt GitHub SalesforceMobileSDK-Shared.

{
  "syncs": [
    {
      "syncName": "syncDownContacts",
      "syncType": "syncDown",
      "soupName": "contacts",
      "target": {"type":"soql", 
      "query":"SELECT FirstName, LastName, Title, MobilePhone, 
               Email, Department, HomePhone FROM Contact LIMIT 10000"},
      "options": {"mergeMode":"OVERWRITE"}
    },
    {
      "syncName": "syncUpContacts",
      "syncType": "syncUp",
      "soupName": "contacts",
      "target": {
         "createFieldlist":["FirstName", "LastName", "Title", "MobilePhone", 
                            "Email", "Department", "HomePhone"]},
      "options": {
         "fieldlist":["Id", "FirstName", "LastName", "Title", 
                      "MobilePhone", "Email", "Department", "HomePhone"], 
         "mergeMode":"LEAVE_IF_CHANGED"}
    }
  ]
}

Dans les exemples suivants, les deux opérations de synchronisation (vers le serveur et vers l’appareil) appellent reSync() depuis le plug-in Cordova de Mobile Sync, en lui transmettant un nom de synchronisation. Toutes les opérations de synchronisation utilisent la fonction handleSyncUpdate() comme fonction de rappel de réussite. Vous remarquerez que cette fonction appelle syncDown() après une exécution réussie de syncUp. Il est toujours judicieux d’appeler syncDown() après syncUp() pour s’assurer que vos soupes sont en adéquation avec les changements les plus récents sur le serveur. 

Dans sa forme actuelle, la fonction de rappel de réussite pour syncDown() réinitialise l’interface utilisateur et son contenu.

 handleSyncUpdate: function(sync) {
  // Called after sync operations succeed 
  if (sync.type === "syncDown") {
    // Reset UI buttons, then search (fetch) from SmartStore
    this.syncInFlight = false;
    $(".sync").disabled = false;
    this.search();
  }
  if (sync.type === "syncUp") {
      this.syncDown();
    }
  }
 },
 syncDown: function() {
   cordova.require("com.salesforce.plugin.mobilesync").
     reSync("syncDownContacts" /* see usersyncs.json */, 
     this.handleSyncUpdate.bind(this));
 },
 syncUp: function() {
   cordova.require("com.salesforce.plugin.mobilesync").
     reSync("syncUpContacts" /* see usersyncs.json */, 
     this.handleSyncUpdate.bind(this));
 }

Utilisation de Mobile Sync dans les applications React Native

Dans React Native, les fonctionnalités de Mobile Sync sont accessibles via un module mobilesync. Dans vos fichiers JavaScript, vous pouvez importer ce module et ses dépendances depuis la bibliothèque react-native-force comme suit :

import {oauth, net, smartstore, mobilesync} from 'react-native-force';

Les applications créées avec forcereact contiennent une déclaration import similaire, mais sans smartstore ou mobilesync. N’oubliez pas d’ajouter ces modules si vous voulez prendre en charge les fonctionnalités hors ligne du kit de développement Mobile SDK.

Configuration de la synchronisation

Comme vous vous en doutez certainement, vous donnez les mêmes métadonnées de configuration aux applications React Native qu’aux applications hybrides. Voici un exemple de déclaration de cible.

 const fieldlist = ["Id", "FirstName", "LastName", 
    "Title", "Email", "MobilePhone","Department",
    "HomePhone", "LastModifiedDate"];
 const target = {type:"soql", query:
    `SELECT ${fieldlist.join(",")} FROM Contact LIMIT 10000`};

Pour le mode de fusion dans les options, utilisez l’une des valeurs suivantes :

  • Pour écraser les enregistrements modifiés :
    {mergeMode:mobilesync.MERGE_MODE.OVERWRITE}
    Si vous ne définissez pas la clé mergeMode, Mobile Sync utilise ce mode par défaut.
  • Pour conserver les enregistrements modifiés au lieu de les écraser :
    {mergeMode:mobilesync.MERGE_MODE.LEAVE_IF_CHANGED}

Synchronisation serveur-appareil

La fonction syncDown() pour React Native est identique à la fonction hybride, sauf qu’elle est appelée depuis le module mobilesync. Elle télécharge les enregistrements Salesforce vers une soupe SmartStore.

mobilesync.syncDown
    ([storeConfig,] target, soupName, options, [syncName,] success, error);

Si des enregistrements existants dans la soupe ont le même identifiant que des enregistrements renvoyés par la requête, Mobile Sync écrase par défaut les enregistrements dupliqués de la soupe. Pour contrôler comment les données téléchargées sont fusionnées avec les enregistrements modifiés dans la soupe, spécifiez un mode de fusion dans le paramètre options.

Le paramètre success spécifie une fonction de rappel que le gestionnaire de synchronisation interne appelle lorsque l’opération de synchronisation réussit. Contrairement à l’implémentation hybride, la bibliothèque React Native appelle cette fonction une seule fois, lorsque l’opération se termine.

Le kit de développement Mobile SDK transmet un seul argument à la fonction de rappel de réussite. Cet argument retourne les métadonnées de synchronisation suivantes, qui incluent l’identifiant de synchronisation :

  • syncId : ID de cette opération de synchronisation
  • type : synchronisation serveur-appareil
  • target : cible que vous avez indiquée
  • options (facultatif) : tableau spécifiant le mode de fusion et/ou la liste des champs
  • soupName : nom de soupe que vous avez indiqué
  • syncName : nom de synchronisation que vous avez indiqué, le cas échéant

Même si vous n’avez pas d’autres actions pour lesquelles une fonction de rappel de réussite pourrait être utile, il est toujours judicieux d’en implémenter une afin de stocker l’identifiant de synchronisation. Vous pourrez utiliser cette valeur ultérieurement, si nécessaire, dans une opération de resynchronisation. Voici un exemple de synchronisation vers l’appareil.

const syncDown = forceUtil.promiserNoRejection(mobilesync.syncDown);
...
const fieldlist = ["Id", "FirstName", "LastName", 
    "Title", "Email", "MobilePhone","Department",
    "HomePhone", "LastModifiedDate"];
const target = {type:"soql", 
    query:`SELECT ${fieldlist.join(",")} 
           FROM Contact 
           LIMIT 10000`};
syncDown(false,
    target,
    "contacts",
    {mergeMode:mobilesync.MERGE_MODE.OVERWRITE},
    syncName,
    (sync) => {/* Do something meaningful or omit this member */},
    (error) => {/* Do something meaningful or omit this member */}
 );

Synchronisation appareil-serveur

La fonction syncUp() du plug-in Mobile Sync copie vers le serveur Salesforce des enregistrements qui ont été créés, mis à jour ou supprimés dans une soupe SmartStore.

mobilesync.syncUp
   ([storeConfig,] target, soupName, options, [syncName,] successCb, errorCb);

Comme dans les opérations de synchronisation vers l’appareil, l’argument d’entrée de la fonction de rappel de réussite vous fournit des métadonnées de synchronisation, y compris l’identifiant de synchronisation.

Voici un exemple de synchronisation vers le serveur.

const syncUp = forceUtil.promiserNoRejection(mobilesync.syncUp);
...
const fieldlist = ["FirstName", "LastName", "Title", "Email", 
  "MobilePhone","Department"];
syncUp(false,
  {},
  "contacts",
  {mergeMode:mobilesync.MERGE_MODE.OVERWRITE, fieldlist},
  (sync) => {/* Do something meaningful or omit this callback */},
  (error) => {/* Do something meaningful or omit this callback */}
);

Resynchronisation

Comme dans les applications natives, la méthode reSync() offre une plus grande flexibilité et de meilleures performances, en plus de faciliter le codage. Si le nom de synchronisation que vous fournissez n’a pas déjà été synchronisé, reSync() effectue une synchronisation complète. Sinon, elle effectue seulement une synchronisation incrémentielle des enregistrements qui ont été créés, modifiés ou supprimés.

mobilesync.reSync
   ([storeConfig,] syncIdOrName, successCB, errorCB);

C’est à vous de fournir les paramètres de configuration de l’opération, notamment

  • syncIdOrName : l’identifiant de cette opération de synchronisation ou un nom de synchronisation pour votre fichier usersyncs.json.
  • successCb, errorCb : fonctions de rappel de succès ou d'erreur.

Ressources

Partagez vos commentaires sur Trailhead dans l'aide Salesforce.

Nous aimerions connaître votre expérience avec Trailhead. Vous pouvez désormais accéder au nouveau formulaire de commentaires à tout moment depuis le site d'aide Salesforce.

En savoir plus Continuer à partager vos commentaires