Developer Fundamentals Part 1 - PD1

- Chaque objet a un Sharing Object.

Objet standard on l’ecrit : AccountShare, ContactShare.
Object Custom on l’ecrit : MyCustomObject_Share.
Bien evidement dans le master-detail detail n’as pas de sharing object. Car il herite
des sharing rules du master.

- AppExchange est un appStore app may include support & maintenance, et aussi
reviewing & solution for customer.

- Pour afficher, des valeur de different objet il faut utiliser une VF page.
Page Layout connot diplay fiel from unrelated object.

- Les limite du server Salesforce :

CPU time per transaction.
Time Excuting a SOQL
Total Number of record retrived by SOQL
Mais pas de limite pour time de DML.

- Plateform Event :
“enable developers to delive secure, scalable, and customizable event notifications
within the Salesforce platform or from external sources.”
Cela peut etre pour envoyer des information sur une application externe.
Mais on peut en recevoir aussi.
CometD est une societe externe.
Exemple :
on veux savoir quand une opportinite est close en win ou pas.
On cree un custom field dans la plateform event qui va retrive la data de lopportinite
qui est updater et lafficher:
 Dans ce code le Opportinity_Event_e est le nom officiel du platteform event et dedans
on lui a cree un Custom Field qui sappelle Stage_c.

Ici par exemple le nom du plateform event cest : Test Plateform Event 1,
et il na pas de custom event field cependant il a des standard fiel.

- Process Builder connot be used to query record.

Flow can send email automatically when a record is created or updated.

- MVC = Field, Objects, Relationships. Model View Controlller.

- Si un component is not showing in Lightning App Builder cest que le domaine has not
been defined and deployed to the org.

- Indirect Lookup : child external.

External Lookup : parent external.

- RecordType :
Account peut etre plein de type par exemple personne ou hotel etc…
Exemple : Object Vehicule, et le record type cela pourait etre : voiture, moto etc.
- On ne peux pas acceder a la Geoloction de manier direct. et il faut enlever le __c.

- Process Builder connot be used to invoke autolamched flow in scheduled interval or

timing.

- Comment cree un publish-subscribe entre deux component, en utilisant un

application event : Application events follow a traditional publish-subscribe model. An
application event is fired from an instance of a component. All components that provide a
handler for the event are notified.

- The total API request per 24-hour period is limited for an org.

- Une declarative customization est une action sur salesforce qui ne nessesite pas de
code un batch nest pas une declarative customization.
Et on ne peux pas mettre de roll up sumary field sur une cross objet formula field.

- Un process builder, trigger ne peux pas etre configurer pour runer de manier
periodique a une heure presice seul le batch peut le faire.
On peux faire un Flow mais si la logique est trop complexe il faut runer un batch.
- Lightning App Builder :
Outil de Salesforce qui permet de créer et de personnaliser des interfaces utilisateur
via une méthode glisser-déposer, sans nécessiter de code. Il est utilisé pour construire
des Lighning App page pour les applications Salesforce, optimisées pour le mobile et
personnalisables selon les besoins spécifiques des utilisateurs.
On peux y ajouter des Standar Component et des Global Action.

- Lightning Record Page :

une Record page cest un truc simple ou jai des donne comme la page client classique
- Ne pas confondre Validation Rule avec Formula Field, la formuala fiel doit juste affiche
une valeurs. Cependant la validation rule nous permet de voir si une regles est
respecter.

Cependant le validation rule contient en effet une formul. mais ce nest pas une
formula field.

-
- Le Lightning App Builder peut cree : App page, Home Page, Record Page, Email app.
mais ne peux pas cree de Tabs ou bien de Custom page Layout.

Fonction :

- getSObjectType() : pour avoir le type dun objet.

- Pour avoir les valeurs dune pickList : F.getPicklistValues();
- Pour voir si un user a un acces a un field : isAccessible();
- Database.quey(string); //pour avoir une SOQL dynamic created from an end user.

- getDigit() methode return the maximum number of digit specified field.

- getScale() method return the number of digits to the right of the decimal point of
Double field.
- getLenght() method return the maximum size of the field in unicode characters.
- isDeletable() methode of the DescribeObjectresult to check if the current user is able
to delete the current object.
- isAccessible() Schema.DescribeFieldResult methode do check if a user hase read
access to a fiel and if the field can be displayed on vf page.
- getGlobalDescribe() method return a map of all sObject name & tokens.
- geLabel() return the object’s label, which may or may not match the object name.
 Question a Approfondire:

- Question AuraComponent.
https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/compon
ents_lifecycle.htm

- Question Api
Publish Event Messages with Salesforce APIs :
https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_
events/platform_events_publish_api.htm
DIFFERENCE BETWEEN SOAP AND REST API?
https://www.linkedin.com/pulse/difference-between-rest-soap-api-sfmc-rajeshwar
-rao/
https://trailhead.salesforce.com/fr/trailblazer-community/feed/0D54V00007T4QkgS
AF
Which API Do I Use?
https://help.salesforce.com/s/articleView?id=sf.integrate_what_is_api.htm&type=5
Synthèse des APIs Salesforce
Différences entre REST et SOAP:
● Communication et Format de Données: REST utilise des requêtes HTTP avec des
données en format JSON, tandis que SOAP utilise des messages XML.

● Simplicité d'Utilisation: REST est généralement plus simple à utiliser et à lire

grâce au JSON. SOAP, avec XML, est plus complexe et nécessite une structure et
une enveloppe spécifiques.

● Flexibilité et Extensibilité: REST offre plus de flexibilité dans les formats de

données et est facilement adaptable aux technologies clients. SOAP, en revanche,
fournit une extensibilité via des fonctionnalités comme WS-Security.

● Performance: REST est plus performant pour les grandes quantités de données
en raison de sa légèreté. SOAP peut être plus lent à cause du traitement XML.

Choix d'API Salesforce:

● REST API: Idéale pour l'intégration et le développement faciles, surtout avec les
applications mobiles et les projets web. Utilisez REST API pour CRUD (Create,
Read, Update, Delete) sur les enregistrements.

● SOAP API: Utilisez SOAP pour intégrer Salesforce avec des systèmes d'entreprise
comme les ERP. Convient aux langages supportant les services web.
 ● Connect REST API: Pour accéder à B2B Commerce sur Lightning, CMS,
Experience Cloud, etc. Idéal pour afficher les flux Chatter dans les applications
mobiles.

● Apex REST API: Exposez vos classes et méthodes Apex pour un accès externe via
REST. Supporte OAuth 2.0 et l'ID de session.

● Apex SOAP API: Exposez les méthodes Apex comme services web SOAP pour un
accès externe.

● Analytics REST API: Accès programmable aux actifs CRM Analytics tels que les
ensembles de données, les objectifs et les tableaux de bord.

● User Interface API: Construisez des interfaces utilisateur Salesforce pour les
applications mobiles natives et les applications web personnalisées.

● GraphQL API: Permet de créer des applications hautement réactives et évolutives

en retournant seulement les données nécessaires en une seule requête.
● Tooling API: Intégrez les métadonnées Salesforce avec d'autres systèmes. Idéal
pour le développement d'outils personnalisés pour les applications Force.com.

● Bulk API 2.0: Pour traiter un grand nombre d'enregistrements de manière

asynchrone. Optimisé pour les grands ensembles de données.

● Metadata API: Pour récupérer, déployer, créer, mettre à jour ou supprimer des
personnalisations de votre org. Utilisé couramment pour migrer des
modifications entre environnements.

● Pub/Sub API: Intégration d'événements bidirectionnels à grande échelle avec

Salesforce, utilisant le format Avro via gRPC et HTTP/2.

Résumé:

Choisir entre REST et SOAP dépend de vos besoins spécifiques, avec REST favorisé pour sa
simplicité et sa performance et SOAP pour sa sécurité et extensibilité. Salesforce offre une
variété d'APIs pour différents usages, depuis l'intégration d'applications d'entreprise
jusqu'au développement d'interfaces utilisateur et la manipulation de métadonnées. Les
décisions sur quelle API utiliser doivent considérer les exigences du projet, les volumes de
données et les préférences en matière de technologie.