Service personnalisé ou action OData dans D365 F&O : lequel choisir ?

Pour exposer de la logique X++ à un système externe, Dynamics 365 Finance & Operations offre deux voies principales :

• Une action OData : une méthode ajoutée à une data entity publique et décorée avec SysODataActionAttribute. Elle apparaît dans le $metadata OData et s'appelle depuis l'URL du service. Idéale quand l'opération concerne une entité déjà exposée.
• Un service personnalisé : une classe X++ rattachée à un service et à un groupe de services. Chaque groupe est déployé automatiquement sur deux points de terminaison, SOAP et JSON (/api/services/groupe/service/opération). Adapté aux opérations qui ne correspondent à aucune entité, comme une consultation de stock en temps réel, scénario pour lequel Microsoft recommande justement un service personnalisé.

Exemple de Microsoft Learn : la méthode est ajoutée à l'entité, le premier argument de l'attribut est le nom public de l'action, le second indique si elle est toujours disponible.

[SysODataActionAttribute("CalcMaintenanceDuration", true)]
public int CalculateMaintenanceDuration()
{
    //do something
    return 0;
}

Pour renvoyer une collection typée, ajoutez SysODataCollectionAttribute (nom du paramètre, ou return ; type X++ des éléments ; nom public de la ressource) :

[SysODataActionAttribute("GetColors", true),
    SysODataCollectionAttribute("return", Types::Record, "CarColor")]
public List GetColorsByAvailability(boolean onlyAvailableVehicles)
{
    List returnList = new List(Types::Record);
    // do something
    return returnList;
}

1. Créez une classe X++ avec des méthodes publiques ; utilisez des classes de contrat de données (DataContract) pour les paramètres complexes.
2. Créez un élément Service qui pointe vers la classe et déclarez ses opérations.
3. Ajoutez le service à un groupe de services : tous les groupes sous le nœud Service group sont déployés automatiquement.
4. Appelez l'endpoint JSON https://<hôte>/api/services/<groupe>/<service>/<opération> ou l'endpoint SOAP /soap/services/<groupe>?wsdl, avec une authentification Microsoft Entra ID.

Pour un appel depuis un agent IA, la voie moderne est différente : une classe exposée comme outil d'IA via le serveur MCP Dynamics 365 ERP. Voir agents Copilot Studio : ce qui demande encore du X++.

• Créer un service personnalisé pour du CRUD qu'une data entity OData couvre déjà.
• Oublier d'ajouter le service à un groupe : il n'est pas déployé.
• Faire des appels OData unitaires pour de gros volumes : Microsoft oriente les volumes importants vers les API asynchrones (package DMF, intégrations récurrentes).
• Oublier la sécurité : l'élément d'entrée (service, entité) doit être couvert par un privilège rattaché au rôle de l'application cliente.
• Renvoyer un type non pris en charge par une action OData : types primitifs ou entité publique modifiable.

Action OData, service JSON, contrats et sécurité : ce sont des développements courts et testables. Skalp AI rédige la spécification, génère le code X++ et les tests unitaires, compile en contrôlant les bonnes pratiques, puis livre par pull request dans votre Azure DevOps : rien n'est fusionné sans la validation de votre architecte technique. Voir interfaces et API D365 F&O, le cadre général dans développer en X++ sans consultant en 2026, et les offres Basic, Pro et Max (1 crédit, ≈ 400 € en Basic, 200 € en Pro, consommé seulement à la génération du code).

• Microsoft Learn, « Open Data Protocol (OData) », mise à jour du 14/01/2026, consultée le 18/10/2026.
• Microsoft Learn, « Custom service development », mise à jour du 29/10/2025, consultée le 18/10/2026.
• Microsoft Learn, « Integration between finance and operations apps and third-party services », mise à jour du 09/03/2026, consultée le 18/10/2026.