API personnalisées dans la Power Platform & D365 CE

Méthodes de création d’une API personnalisée

La Power Platform offre plusieurs approches pour créer une API personnalisée (Custom API) selon le niveau de maîtrise technique et le contexte ALM. Chaque méthode présente un compromis entre simplicité, contrôle et intégration continue.

Vue d’ensemble comparative

Méthode	Outil principal	Description	Usage recommandé
Maker Portal	Interface Power Apps	Création directe depuis Dataverse. Paramétrage visuel des entrées, sorties et autorisations.	Idéal pour les tests et prototypes low-code.
Plugin Registration Tool	SDK Dynamics 365	Enregistrement manuel de l’API et des plug-ins handlers.	Pour les développeurs souhaitant un contrôle complet.
Solution Dataverse (XML)	Visual Studio / Export de solution	Création d’API via fichiers de métadonnées intégrés dans une solution.	Recommandé pour les environnements CI/CD.
Code C# (CustomAPI class)	Visual Studio + SDK	Définition complète de l’API, de ses paramètres et handlers par code.	Scénarios avancés, industrialisation DevOps.

Création via le Maker Portal

1. Accéder à Power Apps (https://make.powerapps.com) > Tables > API personnalisées.
2. Cliquer sur Nouvelle API personnalisée (Custom API)

La page suivante (Custom API) affiche le formulaire permettant la saisie de près d’une douzaine de propriétés.

Après enregistrement des propriétés du plugins, certaines d’entres elle notamment celles marquées par un cadenas, ne peuvent plus être modifié

Propriété	Obligatoire	Description	Exemple / Valeur
Owner	Oui	Définit le propriétaire de l’API (utilisateur ou équipe).	YENGO # (Available)
Unique Name	Oui	Nom logique unique utilisé en interne et dans l’API Web. Doit suivre le préfixe éditeur.	archia_ValidationClient
Name	Oui	Nom système de l’API, souvent identique au nom logique.	archia_ValidationClient
Display Name	Oui	Nom lisible affiché dans l’interface Power Apps / Power Automate.	API Validation Client
Description	Oui	Description textuelle expliquant le but ou la logique de l’API.	Vérifie si un email client existe déjà dans la table Contact.
Binding Type	Oui	Type de liaison de l’API : • Global (aucune entité liée) • Entity (lié à un enregistrement) • EntityCollection (lié à une collection).	Global
Bound Entity Logical Name	Non (selon le type de liaison)	Nom logique de l’entité liée, requis si Binding Type ≠ Global.	contact
Is Function	Oui	Spécifie le type de l’API : • Yes = Fonction (lecture) • No = Action (écriture/logique métier).	No
Is Private	Non	Masque l’API des utilisateurs standards si activé.	No
Enabled for Workflow	Non	Permet d’appeler l’API depuis un workflow classique (non recommandé).	No
Allowed Custom Processing Step Type	Oui	Définit le type de plug-in autorisé : • None • Async Only • Sync and Async.	None
Execute Privilege Name	Non	Nom du privilège requis pour exécuter l’API. Vide = accessible à tout utilisateur autorisé.	(vide)
Plugin Type	Non	Référence vers un plug-in (C#) associé à l’API, si applicable.	(aucun plugin pour ce cas)

Définir le nom logique, le nom d’affichage et le niveau d’accès (organisation, utilisateur, global).

1. Ajouter les paramètres d’entrée. Pour ce faire, ouvrir la fiche de l’API archia_ValidationClient dans le portail Maker (https://make.powerapps.com). Puis dans « Related » sélectionner « Custom API Request Parameters) comme indiquer ci-après

Ensuite, renseigner la valeur de chaque champs comme indiqué dans la capture d’écran ci-après:

Indications sur les propriétés et leur valeurs respectives pour la requête de l’API :

Propriété	Obligatoire	Valeur / Exemple	Description
Owner	Oui	YENGO # (Available)	Propriétaire du paramètre.
Custom API	Oui	archia_ValidationClient	API à laquelle le paramètre est rattaché.
Unique Name	Oui	archia_Email	Nom logique unique utilisé par Dataverse et le Web API.
Name	Oui	archia_Email	Nom technique, souvent identique au nom logique.
Display Name	Oui	Email	Nom lisible utilisé dans Power Automate ou les interfaces.
Description	Oui	Adresse email du client à valider.	But fonctionnel du paramètre.
Type	Oui	Boolean	Type de données du paramètre (ici booléen).
Logical Entity Name	Non	contact	Entité associée si le paramètre fait référence à une table Dataverse.
Is Optional	Oui	No	Indique que le paramètre est obligatoire à l’exécution.

Ce paramètre d’entrée Email (type Boolean) est lié à la table Contact.
Il sera utilisé pour transmettre ou vérifier une information de type booléenne dans l’API archia_ValidationClient.

Pour ajouter les paramètres de sortie, le principe est quasiment le même, il s’agit de sélectionner « Custom API Response Properties » dans « Related », comme vu précédemment. Ensuite dans le panneau de gauche, cliquer sur « New« , puis « Custom API Response Properties« 

Compléter les champs comme suit

Indications sur les propriétés et leur valeurs respectives de la réponse renvoyée par l’API archia_ValidationClient :

Indique que la valeur est renvoyée par l’API.

Propriété	Obligatoire	Valeur / Exemple	Description
Owner	Oui	YENGO # (Available)	Propriétaire du paramètre.
Custom API	Oui	archia_ValidationClient	API associée.
Unique Name	Oui	archia_IsValid	Nom logique unique du paramètre.
Name	Oui	archia_IsValid	Nom interne de référence.
Display Name	Oui	EstValide	Nom lisible par l’utilisateur.
Description	Oui	Retourne vrai si l’email existe déjà dans la table Contact.	But du paramètre.
Type	Oui	Boolean	Type de données retourné.
Logical Entity Name	Non	contact	Entité de référence.
Is Optional	Oui	No	Le paramètre est toujours retourné.
Direction	Oui	Sortie	Indique que la valeur est renvoyée par l’API.

Cliquer sur Enregistrer et fermer, puis Publier toutes les personnalisations.

L’API ne contient pas la logique de validation elle-même.
Elle expose un point d’entrée dans Dataverse (appelable via Power Automate, Postman, etc.).
C’est le plug-in C# enregistré sur cette API qui :

• récupère le paramètre d’entrée Email,
• interroge la table Contact,
• renvoie la valeur du paramètre de sortie EstValide selon le résultat.

Structure du plug-in (C#)

using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Query;

public class ValidationClientPlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
        var serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
        var service = serviceFactory.CreateOrganizationService(context.UserId);

        // Récupération du paramètre d’entrée
        if (context.InputParameters.Contains("Email") && context.InputParameters["Email"] is string email)
        {
            // Vérification dans la table Contact
            var query = new QueryExpression("contact")
            {
                ColumnSet = new ColumnSet("emailaddress1"),
                Criteria = new FilterExpression
                {
                    Conditions =
                    {
                        new ConditionExpression("emailaddress1", ConditionOperator.Equal, email)
                    }
                }
            };

            var results = service.RetrieveMultiple(query);

            // Définition du paramètre de sortie
            context.OutputParameters["EstValide"] = results.Entities.Count > 0;
        }
        else
        {
            throw new InvalidPluginExecutionException("Le paramètre 'Email' est requis.");
        }
    }
}

---

Étapes techniques

1. Créer le plug-in dans Visual Studio (classe implémentant IPlugin).
2. Compiler le projet et générer le fichier .dll.
3. Enregistrer le plug-in dans Dataverse via :
   • le Plugin Registration Tool, ou
   • une solution Power Platform (rubrique Plug-ins).
4. Associer le plug-in à l’API personnalisée :
   • Dans le Maker Portal → ouvrir archia_ValidationClient.
   • Renseigner le champ Plugin Type avec le nom du plug-in (ValidationClientPlugin).
   • Publier les personnalisations.

Exemple d’appel via Postman

POST https://<organisation>.crm.dynamics.com/api/data/v9.2/archia_ValidationClient
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "Email": "client@contoso.com"
}

Réponse :

{
  "EstValide": true
}