Matthew Grumbach, Lead du staff technique de Salesforce et Jeremy Westerman, Directeur de la gestion produit, animaient une session Dreamforce bien technique comme on les aime, sur les évolutions liées au SOQL.
Alors, pour ceux qui ne sont pas familiers avec le développement, c’est sûr que cet article risque d'être un peu plus compliqué à suivre. Mais on essaiera quand même de vulgariser au maximum.
L'article retrace les 3 parties de la session, à savoir :
Désolés par avance pour le franglais utilisé dans cet article, mais les termes techniques sont sûrement plus connus en anglais que dans une traduction française approximative.
Evolutions SOQL des dernières releases
On commence la session avec un petit rappel d'évolutions qui sont passées dans les releases précédentes. Un bon moyen de se rafraichir la mémoire 💡pour ceux qui les auraient laissé passer.
Passage de 35 à 55 relations « child-to-parent » dans les requêtes (Spring '20🌷)
Ici on parle donc de récupérer les informations du parent (par exemple d’Account) depuis l’enfant (par exemple Contact).
Sur les objets standard, on a à présent la possibilité de spécifier jusqu’à 55 relations «child-to-parent» et 40 pour les objets Custom. Donc 20 de plus pour les fana des relations!
Passage de 20k à 100k caractères max pour les requêtes (Spring '20🌷)
Ce qu’il faut savoir, c’est que les requêtes SOQL longues et complexes, telles que celles contenant de nombreux champs de formule, peuvent entraîner une erreur de type «QUERY_TOO_COMPLICATED».
Alors évidemment on peut se demander qui se lance dans l’écritures de requêtes de plus de 20.000 caractères ?!
En fait ça peut arriver assez vite parce que la requête est interprétée avant d’être exécutée. Ce qui veut dire que si vous appelez des champs de formules, leur expression fera partie de la requête. On peut donc facilement atteindre cette limite, même si la requête de départ fait moins de 10.000 caractères.
Equivalent du « SELECT * » (Spring '21🌷)
Un petit rappel sur la fonction Fields() qui permet de simuler le « select * from Object » que l’on retrouve en SQL.
Cette fonction permet de récupérer l’ensemble des champs sans en connaitre le nom.
3 types sont disponibles
Select FIELDS(ALL) from OBJECT : récupère tous les champs de l’objet
Select FIELDS(STANDARD) from OBJECT : récupère tous les champs standard de l’objet
Select FIELDS(CUSTOM) from OBJECT : récupère tous les champs custom de l’objet
Un raccourci d’écriture qui facilite la vie ! Et qui évite de se retrouver confronté aux limitations des 100.000 caractères maximum dans l’écriture des requêtes.
Ces fonctions respectent également la visibilité des champs. Vous ne verrez que les champs auxquels vous avez accès.
Et puisqu’on en est à parler des limitations, gardez en tête que :
· Seul FIELDS(STANDARD) est disponible en Apex et en Bulk V2.
· Il n’est pas possible de coupler les fonctions FIELDS() avec des agrégations
· Les résultats sont limités à 200 records. Mais il est possible d’utiliser les systèmes de pagination pour en récupérer plus.
· Si vous utilisez FIELDS(CUSTOM) et qu’aucun champ custom n’est disponible, vous aurez une erreur. Pensez à ajouter par exemple l’ID pour éviter ce cas. Ex : select ID, FIELDS(CUSTOM) from Object
Suppression de la limite des « 10 Concurrent Cursors » (GA Winter '23 ❄️)
Lorsque l'on a des systèmes externes qui interrogent les données Salesforce en SOAP ou en REST, il n'est possible de récupérer que 2000 enregistrements à la fois.
Si le nombre de résultats est plus élevé, la réponse de l'appel contiendra un premier ensemble d'enregistrements (2000) ainsi que le Query Locator dans un Cursor côté serveur.
Donc pour faire simple, ça récupère les premiers enregistrement 📱et ça crée un marque-page côté serveur 📲 pour indiquer où on en est dans la récupération des résultats. Jusqu'à présent, il était possible d'avoir jusqu'à 10 curseurs simultanés. Cette limitation a été levée. Avant cela, il était tout simplement impossible de savoir si celle-ci allait être atteinte avant qu’elle le soit (et cause des erreurs sur la plateforme).
Les curseurs étaient accessibles pendant 15 minutes maximum. Aujourd’hui les résultats resteront disponibles jusqu’à deux jours.
Evolutions planifiées pour les prochaines releases
Après le rappel des dernières évolutions disponibles, on fait le tour de celles planifiées pour les prochaines releases. Elles devraient donc arriver sous peu.
Query Explain Parameter (BETA) 🔎
Salesforce met à disposition (en BETA pour le moment sur la REST), le paramètre de requête « Explain » qui permet d’obtenir des informations sur la façon dont Salesforce exécute votre requête, rapport ou vue de liste.
Ceux qui ont déjà utilisé l’option « Query Plan » dans la dev console, retrouveront leur petits, puisque c’est ce que propose « Explain »
Query Plan sur la DEV Console
Explain en REST
Par contre, ce qui est pas mal, c’est d’avoir la même chose au niveau des vues de liste et des rapports, ce qui permettra de travailler les filtres et les champs indexés pour une meilleure optimisation.
Pour l’analyse des requêtes SOQL, exécutez : /services/data/vXX.X/query/?explain=VOTRE_REQUETE
Pour l’analyse des rapports ou vue de liste, executez /services/data/vXX.X/query/?explain=ID_LISTVIEW_OU_RAPPORT
N’hésitez pas à faire un retours au PM sur cette fonctionnalité : https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_query_explain.htm
Requêtes sur les enfants (et petits enfants, et toute la lignée…ou presque) 👨👧👦
Aujourd’hui, lorsque l’on effectue une requête, il n’est possible de récupérer qu’un seul niveau d’enfant. Par exemple, si l’on requête sur Account (parent), on peut récupérer les Opportunités (enfant) mais pas les Opportunity Line Items (enfant d’enfant).
Cette limitation devrait sauter dans les prochaines releases puisque Salesforce permettra d’interroger jusqu’à 5 niveaux d’enfants.
Au niveau de la structure, voici ce qui est prévu :
Refactoring du Parser SOQL 🛠
Pour commencer, un parseur est ce qui va convertir vos requêtes SOQL en objet Java. C’est la première étape : l’interprétation avant l’exécution.
Salesforce souhaite refondre le parseur actuel pour plus de performance et plus de réutilisabilité. Et puis surtout parce que la technologie évolue, qu’il faut suivre son temps et que « Innovation » fait partie des valeurs de Salesforce.
C’est un investissement qui ne sera évidemment pas directement visible par les utilisateurs (ni par les dev), mais qui permettra à Salesforce de développer plus rapidement de nouvelles fonctionnalités dans le futur ainsi que la prise en charge de la validation/interprétation offline de la syntaxe.
Ce focus fait également écho à la volonté de développement d’Hyperforce qui regroupe un ensemble de technologies visant à unifier les différents Cloud, et qui demande donc d’être alignés sur les derniers standards.
Roadmap : évolutions prises en considération pour le futur
Pour finir voici la liste des évolutions à plus long termes que les PM ont dans le viseur mais qui ne sont pas encore planifiées dans les prochaines releases. Et donc pas de date prévue.
En vrac, devraient arriver (tôt ou tard, et espérons plutôt tôt que tard 🤓):
La possibilité d’utiliser l’expression COUNT dans les requêtes relationnelles
L'affichage des erreurs de niveau « Champs » (Field Level errors) dans le SOQL
Le support de l’expression « typeof » dans les sous-requêtes (nested) – Utile lorsque l’on souhaite requêter sur des relations polymorphiques
Le support des fonctions format() – pour les formats de type number, date, time, et currency - et toLabel() – pour la récupération des libellés des picklists - dans les expressions de type « typeof »
L'augmentation des limites des sous-requêtes pour les aggrégation et/ou les jointures
L'ajout de nouveaux paramètres au Scope ([USING SCOPE filterScope])
La prise en charge de la fonction de date MINUTE_IN_HOUR
Le développement de nouveaux paramètres pour la fonction FIELDS (prise en compte des fields sets ou groupement de fields)
Voilà pour le contenu de cette session qui présentait des évolutions non négligeables dans l'écriture des requêtes.
Et un tout grand merci aux Speakers pour toutes ces informations :
Matthew Grumbach, Lead du staff technique de Salesforce
Jeremy Westerman, Directeur de la gestion produit