Préparation à la création d’une application

Avant de pouvoir créer votre première application, il vous faut créer un projet et l’associer à votre référentiel de contrôle source.

Vous n’aurez pas besoin de votre organisation Trailhead Playground pour créer cette application. À la place, vous utiliserez des organisations test. Nous avons présenté ces environnements puissants et temporaires dans l’unité précédente. Dans la dernière unité, vous aurez la possibilité de déployer un package dans votre Trailhead Playground.

Un projet Salesforce DX est une copie locale des métadonnées de votre package : il regroupe du code et des personnalisations associés. Il contient également les ressources de base requises pour synchroniser la source et les métadonnées du projet local avec vos organisations test. Créez le projet sur la même machine sur laquelle vous avez installé Salesforce CLI, puis synchronisez ce projet avec votre référentiel VCS.

Dans ce module, nous créons une application de géolocalisation simple avec des composants Aura.

À compter de la version Spring ’19 (version d’API 45.0), vous pouvez créer des composants Lightning à l’aide de deux modèles de programmation : le modèle Composants Web Lightning et le modèle Composants Aura d’origine. Les composants Web Lightning et les composants Aura peuvent coexister et interagir sur une page. Ce contenu aborde les composants Aura. Pour plus d’informations sur les composants Web Lightning, consultez l’article Présentation des composants Web Lightning.

Commençons sans attendre. Créez un projet appelé geolocation (géolocalisation).

1. Dans une fenêtre de terminal ou de commande, accédez à l’emplacement où vous souhaitez que votre projet se trouve.
2. Créez le projet :

   sf project generate --name geolocation

   Cette commande crée un dossier appelé geolocation (géolocalisation), ainsi qu’un projet comportant l’ensemble des actifs dans la structure de dossiers appropriée. Voici un exemple de projet local. Vous pouvez voir comment un projet évolue une fois que vous commencez à ajouter du code source, des composants Lightning et des classes, entre autres.
   
   
   

    

   
   
   

   Ressource	Description
   sfdx-project.json	Ce fichier indique que le répertoire est un projet Salesforce DX. Il contient des informations sur le projet et facilite l’authentification des organisations. Il indique également à Salesforce CLI où placer les fichiers lors de la synchronisation entre le projet et l’organisation. Dans ce fichier, vous précisez les aspects suivants : Les chemins d’accès à votre code source, vos classes et vos métadonnées, tels qu’ils se trouvent dans un ou plusieurs répertoires de packages. Ici, ils figurent dans force-app. L’espace de noms, si nécessaire. La version d’API de votre source. Les commandes Salesforce CLI utilisent ces informations pour savoir quelle source suivre entre le projet et l’organisation associée.
   config/project-scratch-def.json	Détermine la configuration d’une organisation test, y compris les fonctionnalités et paramètres qui définissent sa forme d’organisation. Vous pouvez créer un fichier de configuration que l’ensemble de votre équipe de développement peut partager.
   force-app	Le dossier contenant la source de votre projet.

Configuration d’un fichier de définition d’organisation test

Les fichiers de définition d’organisation test vous permettent de créer facilement des organisations test avec différentes fonctionnalités ou préférences à des fins de test. Par exemple, vous pouvez activer ou désactiver la mise en cache Web de Salesforce mobile en définissant la préférence d’organisation enables1EncryptedStoragePref2. Pendant le développement, la désactivation de la mise en cache vous permet d’éviter d’actualiser la page à plusieurs reprises en attendant que les modifications apportées au code de votre composant prennent effet.

Mettez éventuellement à jour le contenu du fichier config/project-scratch-def.json pour le rendre plus personnel, par exemple en modifiant la propriété orgName.

{
  "orgName": "Account Geolocation App",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": false
    }
  }
}

La désactivation de la mise en cache sécurisée et permanente du navigateur a un impact négatif important sur les performances. Activez toujours ce paramètre en production.

Maintenant que vous comprenez quelle est la puissance des organisations test, voici le flux de travail de base que vous pouvez utiliser dans le modèle de développement de packages.

1. Transférez votre source et vos métadonnées locales vers une organisation test.
2. Reprenez dans votre projet local toutes les modifications apportées dans l’organisation test.
3. Synchronisez ce projet avec votre référentiel de contrôle source.

Votre édition de l’organisation Dev Hub détermine le nombre d’organisations tests que vous pouvez créer quotidiennement et le nombre d’entre elles pouvant être actives à un moment donné. Les Trailhead Playgrounds sont des organisations Developer Edition. Vous pouvez supprimer une organisation test existante pour libérer une allocation à l’aide de la commande org delete scratch.

Toutefois, avant de pouvoir travailler avec le flux de travail, nous devons d’abord créer une organisation test. Allons-y.

1. Dans la fenêtre de commande, passez au répertoire du projet geolocation (géolocalisation).

   cd geolocation

2. Créez une organisation test ayant pour alias GeoAppScratch.

   sf org create scratch --set-default --definition-file config/project-scratch-def.json --alias GeoAppScratch

Ce processus peut parfois prendre quelques instants. Nous avons utilisé les indicateurs suivants lors du lancement de la commande :

• L’indicateur --set-default signifie que vous souhaitez que cette organisation test soit l’organisation par défaut pour ce projet lors de l’exécution de commandes Salesforce CLI. Pour utiliser une organisation différente par commande, vous pouvez spécifier l’indicateur --target-org et indiquer un autre alias.
• L’indicateur --definition-file est le chemin d’accès au fichier de configuration de l’organisation test du projet.
• Vous souvenez-vous de l’indicateur --alias de l’unité précédente ? Il vous permet de faire référence à l’organisation en utilisant son alias, GeoAppScratch, dans les prochaines commandes qui acceptent l’indicateur --target-org.

Les organisations test sont fournies avec des données standard fondées sur l’édition que vous choisissez. Cependant, il est important d’ajouter des exemples de données plus pertinents pour l’application ou le package que vous créez. Utilisons donc Salesforce CLI pour créer des exemples de comptes à tester avec notre application de géolocalisation.

1. Créez le compte Marriott Marquis.

   sf data create record --sobject Account --values "Name='Marriott Marquis' BillingStreet='780 Mission St' BillingCity='San Francisco' BillingState='CA' BillingPostalCode='94103' Phone='(415) 896-1600' Website='www.marriott.com'"

2. Créez le compte Hilton Union Square.

   sf data create record --sobject Account --values "Name='Hilton Union Square' BillingStreet='333 O Farrell St' BillingCity='San Francisco' BillingState='CA' BillingPostalCode='94102' Phone='(415) 771-1400' Website='www.hilton.com'"

3. Créez le compte Hyatt.

   sf data create record --sobject Account --values "Name='Hyatt' BillingStreet='5 Embarcadero Center' BillingCity='San Francisco' BillingState='CA' BillingPostalCode='94111' Phone='(415) 788-1234' Website='www.hyatt.com'"

   Pour continuer à faire évoluer les possibilités qui s’offrent à vous en tant que développeur, nous fournissons des commandes permettant de récupérer facilement les données de votre organisation test et de les intégrer à votre projet. Vous pouvez ensuite valider ces données dans votre référentiel de contrôle source afin de pouvoir les recharger si vous, ou un autre développeur, lancez une nouvelle organisation test.
   
   Quel que soit le système de contrôle source que vous utilisez, nous vous recommandons de le configurer de sorte que le dossier .sf ne puisse pas être ajouté au référentiel. Ce dossier contient des informations temporaires sur vos organisations test, vous n’avez donc pas besoin de les enregistrer à des fins ultérieures. Dans Git, vous l’ajouteriez au fichier .gitignore.
   
   
4. Dans votre projet de géolocalisation Salesforce DX, créez un répertoire appelé data (données).

   mkdir data

5. Exportez quelques exemples de données.

   sf data export tree --query "SELECT Name, BillingStreet, BillingCity, BillingState, BillingPostalCode, Phone, Website FROM Account WHERE BillingStreet != NULL AND BillingCity != NULL and BillingState != NULL" --output-dir ./data

   Vous disposez désormais d’exemples de données que vous pourrez importer ultérieurement avec cette commande. Toutefois, ne le faites pas maintenant : nous importerons les données dans une autre organisation test ultérieurement.

   sf data import tree --files data/Account.json

   Jusqu’à présent, nous avons synchronisé des données classiques. Nous allons maintenant nous tourner vers la partie la plus intéressante : le code.

• Documentation Salesforce : Guide de configuration Salesforce CLI
• Documentation Salesforce : Référence de commande de la Salesforce CLI
• Documentation Salesforce : Guide du développeur Salesforce DX
• Place de marché Visual Studio : Extensions Salesforce pour VS Code