Tests et dépannage

Aperçu du message

Disponible à la fois depuis la liste des Tables d'événements et depuis une Carte d'événement individuelle, l'Aperçu du message montre exactement ce qui serait envoyé pour un enregistrement réel — sans réellement rien envoyer.

Il affiche :

• La charge utile JSON, construite à partir des champs que vous avez enregistrés.
• Si l'enregistrement actuel passerait actuellement les filtres d'insertion et de modification (✅ passe, ❌ échoue, vide si aucun filtre n'est défini pour ce type d'événement).
• La comparaison before/after, si Include Previous Values est activé pour cette table.
• Soit l'enveloppe de message RabbitMQ complète, soit les mêmes métadonnées présentées sous forme de bloc Headers, selon le Endpoint Type configuré dans Setup — voir En-têtes et propriétés ci-dessous pour savoir ce que sont réellement ces métadonnées, et où elles finissent sur le réseau pour chaque point de terminaison.
• Une Estimated Message Size, en octets ou Ko — construite à partir du corps réseau réel pour votre Endpoint Type configuré, et non une estimation approximative, elle tient donc déjà compte de la surcharge base64/XML sur Azure Queue Storage, de l'enveloppe EventGridEvent sur Azure Event Grid, etc. Si Include Previous Values est activé, vous obtenez des estimations distinctes pour insert/delete et modify/rename, car la comparaison before/after double approximativement la taille. Inclut les métadonnées x-pbo-* dans tous les cas, qu'elles finissent dans le corps ou en tant qu'en-têtes HTTP distincts pour votre point de terminaison — mais exclut les en-têtes de transport standard comme Content-Type et Authorization. Comparez-la aux limites de taille de charge utile avant de vous fier à une table en production.

Le Send Test Payload ici est différent de celui de Setup : il met en file d'attente la charge utile réelle de l'enregistrement actuellement affiché pour une livraison réelle via la même File d'attente d'événements qu'utiliserait un événement capturé, ce qui vous permet de confirmer la livraison de bout en bout — pas seulement la structure — sans attendre un changement réel. Il est toujours envoyé comme un événement insert et est toujours envoyé, que la table ait Insert Event activé ou non, et que l'enregistrement passe actuellement son filtre d'insertion ou non — le ✅/❌ affiché ci-dessus est purement informatif et ne conditionne pas ce bouton. Vérifiez ensuite la File d'attente d'événements pour connaître le résultat de la livraison.

Utilisez les actions First Record / Previous Record / Next Record pour parcourir les enregistrements réels de la table sous-jacente et voir comment la charge utile change d'un enregistrement à l'autre — pratique pour vérifier que les filtres et les champs associés se comportent comme prévu sur un ensemble de données réelles, et pas seulement sur un exemple isolé.

En-têtes et propriétés

Chaque événement transporte un ensemble fixe de métadonnées x-pbo-* générées par Business Central, indépendamment des champs que vous avez enregistrés sur la table :

En-tête	Valeur
x-pbo-company-name	L'entreprise dans laquelle l'événement s'est déclenché.
x-pbo-environment-name	Le nom de l'environnement Business Central.
x-pbo-is-production / x-pbo-is-sandbox	Présent (true) uniquement pour le type d'environnement qui correspond réellement — jamais les deux, et aucun des deux sur certains types d'environnement.
x-pbo-company-badge	Le Custom System Indicator Text de l'entreprise, s'il en existe un — omis sinon.
x-pbo-event-type	insert, modified, rename, ou delete.
x-pbo-table-name	Le nom de la table, tel qu'enregistré dans Tables d'événements.
x-pbo-modified-at	L'horodatage de dernière modification de l'enregistrement.
x-pbo-tenant-id	L'ID du locataire Business Central.
x-pbo-aad-tenant-id / x-pbo-aad-tenant-domain-name	Le locataire Entra ID à l'origine de cet environnement.
x-pbo-user-id / x-pbo-user-email / x-pbo-user-fullname	L'utilisateur à l'origine de l'action — envoyé uniquement lorsque Include User Data est activé (voir Setup → General), et les valeurs e-mail/nom complet uniquement si cet utilisateur a effectivement une valeur définie pour elles.

L'endroit où ces métadonnées atterrissent réellement dépend du Endpoint Type — pour trois d'entre eux, ce sont de véritables en-têtes de requête HTTP, pour les trois autres, c'est plutôt une clé à l'intérieur du corps JSON :

Point de terminaison	Où ces métadonnées atterrissent
API endpoint, Azure Service Bus, Azure Event Hub	En-têtes de requête HTTP littéraux — jamais à l'intérieur du corps JSON.
RabbitMQ	À l'intérieur du corps du message, sous properties.headers de l'enveloppe AMQP — le propre concept de RabbitMQ pour les propriétés/en-têtes de message, et non des en-têtes HTTP.
Azure Event Grid	À l'intérieur du corps du message, sous data.headers de l'enveloppe EventGridEvent.
Azure Queue Storage	À l'intérieur du corps du message, sous son propre objet headers de premier niveau (aux côtés de event_type, table_name et payload). Seul x-ms-version est ajouté comme en-tête HTTP littéral.

L'Aperçu du message désigne toujours ces métadonnées par « Headers » (sauf pour RabbitMQ, où il affiche plutôt l'enveloppe de message complète), que l'une ou l'autre des deux catégories ci-dessus s'applique réellement — pour Azure Event Grid et Azure Queue Storage en particulier, ce que l'aperçu appelle « Headers » est ce qui finit intégré dans le corps de la requête sur le réseau, et non envoyé comme en-têtes HTTP littéraux.

Send Test Payload

Sur Event Bridge Setup, Send Test Payload envoie un événement factice (une charge utile fixe {"Test Message": "Hi!"}, type d'événement insert, nom de table Test) directement vers le point de terminaison configuré, immédiatement et en dehors de la file d'attente. C'est un moyen rapide de confirmer que l'URL de votre point de terminaison et son autorisation sont correctes de bout en bout, sans avoir besoin d'avoir déjà enregistré une table.

Lire les messages d'erreur

Lorsqu'un événement échoue à être envoyé — immédiatement dans la boîte de dialogue Send Test Payload, ou en tant que Error Message d'une entrée dans la File d'attente d'événements — le message est l'un des suivants :

• « HTTP requests are blocked by your environment settings. » — Les appels HTTP sortants ne sont pas encore activés pour cette extension. Dans la boîte de dialogue Send Test Payload, ceci renvoie directement vers Extension Management, où vous devez activer le HTTP sortant pour BC Event Bridge.
• « Failed to send event. Server responded with <status>: <reason>. » — Le point de terminaison a été atteint, mais a rejeté la requête. Le code de statut et la phrase de raison sont votre meilleure piste — un 401/403 pointe généralement vers l'Authentification, un 413 vers un événement dépassant la limite de taille de charge utile de votre point de terminaison, tout le reste vers les propres journaux du système récepteur. Pour OAuth 2.0, Business Central réessaie déjà une fois avec un nouveau jeton en cas de 401 avant d'afficher ce message, donc un 401 ici signifie que la nouvelle tentative a également échoué — vérifiez l'enregistrement d'application lui-même, pas seulement un cache périmé.
• « Unable to acquire an OAuth2 access token. Verify the token endpoint, client ID, client secret and scope... » — Business Central n'a pas pu terminer le flux client-credentials. Vérifiez ces quatre champs par rapport à votre enregistrement d'application ; voir OAuth 2.0.
• « Unable to build a SAS authorization header. Verify the SAS key name and value... » — Le nom de clé ou la valeur du Azure SAS Token dans Setup est manquant ou n'a pas été enregistré.
• « Unable to build a Storage SAS request URL. Verify the SAS token... » — Le Storage SAS Token dans Setup est manquant, n'a pas été enregistré, ou a expiré.
• « Unable to build an Event Grid SAS authorization header. Verify the access key... » — La clé d'accès du Event Grid SAS Token dans Setup est manquante ou n'a pas été enregistrée.
• « Unable to find a valid endpoint setup. » — Un champ requis pour votre Endpoint Type configuré est vide (RabbitMQ API URL ; API Endpoint ; Service Bus Namespace/Queue-Topic Name ; Event Hub Namespace/Event Hub Name ; Storage Account/Queue Name ; ou Event Grid Topic Endpoint). Dans la boîte de dialogue Send Test Payload, ceci renvoie vers Event Bridge Setup.

Qui voit ces erreurs

Un échec de livraison pour un événement réel capturé n'interrompt ni ne notifie l'utilisateur dont l'action l'a déclenché — il est enregistré silencieusement sur cette entrée dans la File d'attente d'événements avec le statut Error, et nulle part ailleurs dans Business Central. Personne ne le voit à moins d'aller le chercher.

Si vous vous appuyez sur Event Bridge pour quelque chose d'important sur le plan opérationnel, vérifiez régulièrement la File d'attente d'événements — ou mieux, surveillez la livraison depuis le côté récepteur (RabbitMQ ou les propres journaux de votre point de terminaison API) — plutôt que de vous attendre à ce que les échecs vous soient signalés automatiquement.

Qui peut utiliser ces fonctionnalités

L'Aperçu du message et Send Test Payload nécessitent le même accès Event Bridge Admin requis pour Setup et Tables d'événements — voir Licences et accès.