Business event personnalisé D365 F&O vers Power Automate ou Azure
Créer un business event personnalisé dans D365 F&O : classe d'événement, contrat, envoi, puis consommation par Power Automate, Service Bus ou Event Grid.
La réponse courte
Un business event personnalisé dans Dynamics 365 Finance & Operations repose sur deux classes X++ : une classe d'événement qui hérite de BusinessEventsBase (avec l'attribut BusinessEvents) et une classe de contrat qui hérite de BusinessEventsContract (le payload). On appelle ensuite send() au bon endroit du code métier. Après déploiement, l'événement apparaît dans le catalogue des business events, où on l'active vers un point de terminaison : Power Automate, Azure Service Bus, Azure Event Grid, HTTPS, etc.
Microsoft insiste sur l'usage : un business event sert à déclencher une action métier hors de F&O (notifier, lancer un flux), pas à exporter des données. Pour transférer des données, utilisez les mécanismes d'export existants.
Étape 1 : la classe d'événement
Convention de nommage Microsoft : <nom><action au passé>BusinessEvent, par exemple VendorInvoicePostedBusinessEvent. La classe comporte un constructeur statique newFrom…, un new privé, des méthodes parm privées et buildContract. Exemple complet de Learn :
[BusinessEvents(classStr(SalesInvoicePostedBusinessEventContract),
'AccountsReceivable:SalesOrderInvoicePostedBusinessEventName',
'AccountsReceivable:SalesOrderInvoicePostedBusinessEventDescription',
ModuleAxapta::SalesOrder)]
public class SalesInvoicePostedBusinessEvent extends BusinessEventsBase
{
private CustInvoiceJour custInvoiceJour;
static public SalesInvoicePostedBusinessEvent newFromCustInvoiceJour(CustInvoiceJour _custInvoiceJour)
{
SalesInvoicePostedBusinessEvent businessEvent = new SalesInvoicePostedBusinessEvent();
businessEvent.parmCustInvoiceJour(_custInvoiceJour);
return businessEvent;
}
private void new()
{
}
private CustInvoiceJour parmCustInvoiceJour(CustInvoiceJour _custInvoiceJour = custInvoiceJour)
{
custInvoiceJour = _custInvoiceJour;
return custInvoiceJour;
}
[Wrappable(false), Replaceable(false)]
public BusinessEventsContract buildContract()
{
return SalesInvoicePostedBusinessEventContract::newFromCustInvoiceJour(custInvoiceJour);
}
}Les arguments de nom et de description de l'attribut sont des libellés.
Étape 2 : le contrat et l'envoi
Le contrat hérite de BusinessEventsContract, porte l'attribut DataContract, contient des variables privées (numéro de facture, montant, date…), une méthode initialize protégée, un constructeur statique et des méthodes parm décorées en DataMember. C'est lui qui définit le JSON envoyé.
L'envoi se fait au point où l'information est disponible, idéalement dans la logique métier plutôt qu'au niveau de la table : on garde le contexte métier et on évite le « bruit ». L'envoi est lié au commit de la transaction : si elle est annulée, l'événement n'est pas envoyé. Si préparer l'événement coûte cher, testez d'abord s'il est activé :
if (BusinessEventsConfigurationReader::isBusinessEventEnabled(classStr(CollectionStatusUpdatedBusinessEvent)))
{
// logique coûteuse seulement si l'événement est activé
CollectionStatusUpdatedBusinessEvent::newFromCustDispute(dispute).send();
}Étape 3 : activer et consommer
Le catalogue est reconstruit lors de la synchronisation de la base au déploiement ; sinon, utilisez Manage > Rebuild business events catalog. Dans l'espace Business events, créez un point de terminaison (Power Automate, Service Bus, Event Grid, HTTPS…) puis activez l'événement pour une ou plusieurs sociétés. Power Automate peut aussi s'abonner directement. Les abonnements Azure ou Power Automate sont à votre charge.
Erreurs fréquentes
- Utiliser un business event pour exporter des données en masse : mauvais usage selon Microsoft.
- Capturer l'événement au niveau table (insert/update) : contexte métier perdu et filtres complexes, et l'événement peut manquer si les données passent par une autre voie.
- Construire le contrat même quand l'événement n'est pas activé, sur un traitement coûteux.
- Oublier de reconstruire le catalogue : l'événement n'apparaît pas.
- Envoyer un événement « faux » (avant la validation réelle de l'opération) : le destinataire doit pouvoir s'y fier.
Faire générer ce développement
Classe d'événement, contrat, libellés et point d'envoi : un business event personnalisé est un développement court et bien délimité. 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 automatisation de workflows D365 F&O et 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).
À lire aussi : EDI DESADV dans D365 F&O.
Sources
- Microsoft Learn, « Business events developer documentation », mise à jour du 15/01/2026, consultée le 18/10/2026.
- Microsoft Learn, « Business events overview », mise à jour du 15/01/2026, consultée le 18/10/2026.
Questions fréquentes
Quelle différence entre business event et export de données ?
Le business event signale qu'une opération métier a eu lieu pour déclencher une action ailleurs. Pour transférer des volumes de données, Microsoft recommande les mécanismes d'export (data entities, DMF).
Mon business event n'apparaît pas dans le catalogue, pourquoi ?
Le catalogue est construit à la synchronisation de la base. Lancez Manage > Rebuild business events catalog et vérifiez que la classe porte bien l'attribut BusinessEvents.
L'événement est-il envoyé si la transaction échoue ?
Non. L'envoi est lié au commit de la transaction ; si elle est annulée, l'événement n'est pas envoyé.
Prêt à transformer votre D365 ?
Rejoignez les DSI qui développent leurs tickets D365 en 2 à 4 h pour 1 crédit (≈ 400 € en Basic, 200 € en Pro).