Implémentation de Google Drive dans Salesforce

10 min read

Vous ici ? Becky, je suis tellement ravi de vous revoir… Comment ? Vous dites avoir déjà oublié mon précédent article sur la création d’une suite de données via les rudiments de l’utilisation de l’interface de commande Salesforce — plus communément référée par le doux sobriquet de « Salesforce CLI » ? Dans ce cas, rafraîchissez-vous la mémoire en cliquant ICI !

Car oui, aujourd’hui nous voyons plus grand Becky, nous voyons sans limites — ou presque. Aujourd’hui, nous voulons allez plus loin dans l’intégration des données dans Salesforce : aujourd’hui, nous parlons documents. Ah je reconnais bien là votre esprit affûté ! Il est vrai qu’il existe déjà une possibilité standard dans Salesforce d’intégrer des fichiers sur un enregistrement : et vous avez raison. Mais comme je vous le mentionnais, Becky : voyez plus grand ! Et si je vous disais qu’il était possible de rattacher ces mêmes documents, à ces mêmes enregistrements, mais sans pour autant être contraint.e.s aux limitations en taille et partage de fichiers imposées ? Absolument : nous passerons par un stockage tiers, et oui sans aucun suspense il sera question d’implémenter Google Drive dans notre environnement Salesforce.

Quick disclaimer : non il ne sera pas question de l’application Files Connect ici — again, think bigger !

Dans Salesforce, création d’un Auth. Provider

De grandes responsabilités impliquent un petit paramétrage préalable… Aussi, rendez-vous dans votre Setup d’organisation, puis dans l’encadré de recherche, saisissez « AUTH » pour ensuite pouvoir sélectionner le chemin suivant :
Identity > Auth. Providers

Avec la plus grande des assurances, créons un nouveau fournisseur d’authentification :
Provider Type = Open ID Connect
– Le Name sera celui de votre fournisseur, et l’URL Suffix sera généré en fonction
Consumer Key & Consumer Secret = sans importance pour le moment (« foo » fera l’affaire)
– Authorize Endpoint URL = https://accounts.google.com/o/oauth2/auth?access_type=offline&approval_prompt=force
Token Endpoint URL = https://accounts.google.com/o/oauth2/token
User Info Endpoint URL = https://www.googleapis.com/oauth2/v3/userinfo
Default Scopes = openid email profile https://www.googleapis.com/auth/drive

Vous devriez obtenir quelque chose ressemblant à cette capture d’écran :

image fonctionnelle

Bravo Becky, vous pouvez sauvegarder ; notez de nouvelles informations sur votre fournisseur, notamment une dont vous aurez besoin pour l’étape à suivre : Callback URL.

 

Dans la Google Console, configuration de Google Drive

Si vous êtes encore avec moi, nous allons maintenant configurer Google Drive dans la Google Console (encore de grandes responsabilités…) ; courage Becky ! Pour ce faire, rendez-vous directement sur cette dernière via CE LIEN.

Dans un premier temps, il faudra générer un projet — son nom importera peu, il faut qu’il soit compréhensible pour vous. Le plus crucial reste la suite des opérations ; d’abord sélectionnez ce nouveau projet dans votre console (en passant par les paramètres de la liste du projet par exemple, cf. image ci-dessous), puis en vous aidant du « sandwich menu » en haut à gauche de votre écran, sélectionnez « API et services » afin de pouvoir autoriser l’API « Google Drive API » (vous la trouverez simplement avec la barre de recherche de la « Bibliothèque », mise à votre disposition).

Ensuite — on reste focus — dans cette même section nous allons générer un produit dans « Écran d’autorisation OAuth ». Dans cette partie, il suffira de suivre les indications présentes pour aller au bout du processus. Ce que vous saisirez sera plus tard résumé dans l’accueil de connexion lors de la tentative d’accès à Google Drive via Salesforce par le fournisseur d’accès. En somme, comme sur l’image ci-après :

image fonctionnelle

Enfin dernière étape, Becky — on se réveille — nous allons procéder à la création de notre client ID dans la catégorie « Identifiants » ; il faudra sélectionner « ID client OAuth » et indiquer « Application Web ». Dans cette catégorie, la seule partie importante est de bien renseigner votre Callback URL précédemment obtenu dans la section « URI de redirection autorisés ». Une fois ces informations renseignées, vous obtenez votre Consumer Key & Consumer Secret, que vous pouvez maintenant enregistrer dans le fournisseur d’accès précédemment créé dans Salesforce.

Dans Salesforce, le retour…

C’est le bout du bout Becky, et nous avons terminé le paramétrage le plus ésotérique qui soit. Comme annoncé avec le disclaimer, il ne s’agira pas ici de mettre en place la solution standard Salesforce Files Connect (again, think bigger). Non, non ! Nous allons réaliser un développement custom pour notre implémentation.

Pour une utilisation pérenne, nous allons créer des identifiants nommés ; de nouveau dans le Setup, saisissez « CRED » dans la barre de recherche pour pouvoir sélectionner le chemin suivant :
Security > Named Credentials

Pour ce nouvel identifiant nommé :
Label = idéalement le même que l’Auth. Provider pour s’y retrouver, le Name sera généré en fonction
URL = https://www.googleapis.com
Identity Type = cela dépendra de la stratégie de connexion de l’organisation, mais pour assurer un suivi nominatif et différent pour chaque utilisateur, le choix « Per User » est recommandé
Authentication Protocol = OAuth 2.0
Authentication Provider = celui que vous venez de créer
Scope = openid email profile https://www.googleapis.com/auth/drive
Start Authentication Flow on Save = true

Le résultat obtenu devra être similaire à celui de l’image suivante :

Mais que se passe-t-il, Becky ? Il semblerait que les informations précédemment établies dans l’écran d’autorisation OAuth soit reprises et demandent une confirmation de connexion avec Google ? C’est que le processus est pleinement abouti : bravo, Becky !

Il faut noter toutefois que dans notre exemple, nous avons choisi de garder le projet créé dans la Google Console à l’état de test (ce qui peut expliquer quelques différences avec l’écran de connexion) :

Pour aller plus loin dans la démarche, il faudrait effectuer à Google une demande de publication de l’application (processus pouvant aller de 4 à 6 semaines) ; tout en respectant un certain nombre de critères comme indiqués dans la capture ci-après :

Enfin, du développement…

Tout ce paramétrage est bien beau Becky, mais comment pouvoir l’utiliser de façon efficiente dans notre environnement, avec un écran chatoyant et intuitif comme le suivant ?

Puisqu’il n’est pas question de couper court à la créativité de tout un chacun dans cette partie, seules les grandes lignes du développement seront mentionnées dans cette partie. Dès lors, il sera possible de réaliser une interface de chargement de fichier, tout en assurant une connexion avec les enregistrements Salesforce.

1)     La documentation

Il est impossible de déroger à ce principe absolu du développement Becky, et encore plus lorsqu’il est question de l’utilisation d’API externe à son propre développement.

Aussi, voici toutes les références utiles pour faire les calls API. De plus, en ayant été bon élève, il sera possible d’invoquer directement dans votre code Apex le Named Credential précédemment créé en tant que préfixe d’endpoint comme suit :

endpoint : ‘callout :GoogleDrive/…’

2)     La structure d’un Drive

Pour bien organiser vos documents dans votre source de données externes, il est impératif de bien s’imprégner de la hiérarchie proposée dans Google Drive. Tout est un ensemble de files & folders (dans la documentation, il sera mention de child & parent pour les calls). Si bien que savoir ou placer un fichier devient plus aisé si on connait la référence externe du dossier dans lequel il est sensé aller !

3)     Le lien Google Drive & Salesforce

Quel était notre but ? Pouvoir charger des documents sur un enregistrement, dans une source de données externes, sans pour autant avoir la trace des documents dans Salesforce (du moins physiquement). Alors comment procéder Becky ? Afin de répondre à une telle demande, il a été nécessaire de créer un objet custom de paramétrage, capable de synthétiser toutes les informations nécessaires à un upload : nous l’appellerons ContainerDrive__c. Voici une liste exhaustive des champs nécessaires à la bonne marche des callouts futurs :

Content Drive : TEXT, faisant référence à l’ID externe du futur document dans Google Drive
Content MIME Type : TEXT, faisant référence au type de document chargé
Content Name : TEXT, nom du fichier chargé
Content Tag : TEXT, description du document chargé
Folder Drive : LOOKUP, référence au folder Drive associé dans lequel le fichier se trouve
Reference : LOOKUP, référence à l’enregistrement auquel le fichier est associé

Il est bien sûr possible d’étendre cette liste au besoin, selon si les informations que l’on veut faire porter sur l’écran doivent être poussées ; le reste sera du bonus.

4)     Principe de chargement côté client

Que cela soit via un Aura Component Bundle ou — plus populaire aujourd’hui — un Lightning Web Component, le principe de chargement est le même : l’utilisation de l’objet JavaScript FileReader est de mise. De cette façon, il sera possible de récupérer l’ensemble des informations nécessaires à transmettre à Google Drive pour que l’upload du document se passe sans encombre.

Il est notamment possible de gérer un chargement simultané de fichiers en procédant ainsi.

De plus, et ce pour contourner une limite de contenus cette fois-ci côté Google, je vous recommande de procéder au chargement de fichiers via des chunks (cf. documentation Google Drive API ; y compris pour les fichiers de petite taille). De cette façon, l’envoi de plusieurs parties du document — s’il était amené à être volumineux — est réalisable. Sans interruption de l’envoi, Google procède à la partition du document dans l’ordre indiqué et renvoie un message de succès à la réception de la dernière partie du document.

5)     Bonus

Forts de toutes ces informations, il est également possible d’envisager un écran de visualisation de notre beau travail Becky ! En effet, appelons cet écran explorer. Relativement au modèle de données de votre organisation, et aux informations portées par les enregistrements ContainerDrive__c, il est tout à fait possible de hiérarchiser ces résultats comme souhaité.
N.B. : n’ayez pas peur du front-end.

In a nutshell

C’est fait… Nous avons réussi Becky ! Paramétrer notre environnement Salesforce pour qu’il puisse communiquer avec notre application Google API ne fut pas aisé, cela étant, cette opération nous aura permis de laisser libre cours à notre imagination dans le développement personnalisé. Qui plus est, sans entamer de restrictions portant sur la volumétrie des documents dans Salesforce d’une part, et également en élargissant la capacité de chargement desdits documents à plusieurs Go si souhaité (votre seule limite, la taille de votre Google Drive) !

Comment ? Oui, j’entends que la partie portant sur le développement est peut-être la plus délicate à aborder dans cet article, Becky. C’est pourquoi nous avons fait le choix de ne faire mention que des grandes directions à prendre pour que l’ensemble soit cohérent. Le niveau de complexité à apporter dépendra du besoin ! Et bien sûr nous restons à votre disposition pour toute demande complémentaire portant spécifiquement sur cette partie.

Article rédigé par Gabriel De Sousa, Développeur Salesforce. 

Contactez-nous !

Thank you!
We got your message
We will answer in the next 24h