Standardisation du langage Power Platform avec Power FX #msignite

En marge de l'événement Microsoft Ignite d'aujourd'hui, il a été annoncé que le prochain chapitre du développement low-code au cours des 24 prochains mois positionnera Power FX comme le langage standard de Power Platform. Rationalisant ainsi la plate-forme pour utiliser une syntaxe unique pour le développement basé sur l'application Canvas. La standardisation du langage «code» de Power Platform permet non seulement aux individus de passer facilement des gourous d'Excel aux développeurs Power Platform, ce qui réduit la charge initiale lors de la plongée dans ses applications et offre un retour sur investissement plus rapide pour les organisations. L'inclusion de Power FX dans la Power Platform ne remplacera pas les langages M ou DAX mais servira d'outil complémentaire où chacun aura sa place dans l'architecture. Comme Microsoft l'a déclaré dans son annonce, «M et DAX se concentrent sur la lecture, la mise en forme, la jonction et la synthèse de grandes quantités de données, tandis que Power Fx se concentre sur la lecture et l'écriture de petits ensembles de données relationnelles.»

Le tableau ci-dessous fournit quelques un aperçu des fonctions existantes de Power Fx, un certain nombre d'entre elles ayant une syntaxe presque identique à celle de la formule Excel existante.

Les avantages fournis par Microsoft ont été ventilés ci-dessous:

• Toutes les opérations de données dans Power Fx sont asynchrones. Le créateur n’a pas besoin de le spécifier, ni de se synchroniser une fois l’appel terminé. Plus important encore, le fabricant n'a pas du tout besoin d'être conscient de ce concept, il n'a pas besoin de savoir ce qu'est une promesse ou une fonction lambda.
• Local et distant. Power Fx utilise la même syntaxe et les mêmes fonctions pour les données locales en mémoire et distantes dans une base de données ou un service. L'utilisateur n'a pas besoin de penser à cette distinction. Power Fx délègue automatiquement ce qu'il peut au serveur pour traiter les filtres et les trier plus efficacement.
• Données relationnelles. Les commandes et les clients sont deux tables différentes, liées par une relation plusieurs-à-un. La requête OData nécessite un «$ expand» avec la connaissance de la clé étrangère, similaire à une jointure en SQL. La formule n'a rien de tout cela, en fait les clés de base de données sont un autre concept que le créateur n'a pas besoin de connaître. Le créateur peut utiliser une simple notation par points pour accéder à l'intégralité du graphique des relations à partir d'un enregistrement.
• Récupérer uniquement ce qui est nécessaire. Dans cet exemple, la fonction LookUp implique qu'un seul enregistrement doit être récupéré et c'est tout ce qui est ramené. Si plus d'enregistrements sont demandés à l'aide de la fonction Filtre pour laquelle des milliers d'enregistrements peuvent se qualifier, une seule page de données est ramenée à la fois, de l'ordre d'une centaine d'enregistrements. L'utilisateur doit parcourir une galerie ou une table de données pour voir les données supplémentaires, et elles sont automatiquement importées pour eux. Le fabricant peut raisonner sur de grands ensembles de données sans avoir à penser à limiter les demandes de données à des blocs raisonnables.
• S'exécute uniquement lorsque cela est nécessaire. Nous avons défini une formule pour la propriété Text du contrôle d'étiquette. Lorsque la variable Sélectionné change, la Recherche est automatiquement recalculée et l'étiquette mise à jour. Le créateur n'a pas besoin d'écrire un gestionnaire OnChange pour la sélection, il doit se souvenir que cette étiquette en dépend.
• Traduction de la syntaxe Excel. Excel est utilisé par des centaines de millions d'utilisateurs, dont la plupart savent que «&» est utilisé pour la concaténation de chaînes

Matériel de référence:

GitHub [19659002] Introduction et vue d'ensemble