Testen & probleemoplossing

Berichtvoorbeeld

Berichtvoorbeeld (beschikbaar vanuit zowel de lijst met Event Tables als een individuele Event-kaart) toont precies wat er voor een echt record verzonden zou worden — zonder daadwerkelijk iets te versturen.

Het toont:

• De JSON-payload, opgebouwd uit de velden die u heeft geregistreerd.
• Of het huidige record op dit moment door de Insert- en Modify-filters zou komen (✅ geslaagd, ❌ mislukt, leeg als er geen filter is ingesteld voor dat gebeurtenistype).
• De before/after-vergelijking, als Include Previous Values voor die tabel is ingeschakeld.
• Ofwel de volledige RabbitMQ-berichtenvelop, ofwel dezelfde metadata weergegeven als een Headers-blok, afhankelijk van het Endpoint Type dat is geconfigureerd op Setup — zie Headers & properties hieronder voor wat die metadata precies is, en waar deze voor elk eindpunt terechtkomt op de lijn.
• Een Estimated Message Size, in bytes of KB — opgebouwd uit de daadwerkelijke berichttekst voor uw geconfigureerde Endpoint Type, geen ruwe schatting, dus deze houdt al rekening met base64/XML-overhead bij Azure Queue Storage, de EventGridEvent-wrapper bij Azure Event Grid, enzovoort. Als Include Previous Values is ingeschakeld, krijgt u aparte schattingen voor insert/delete en modify/rename, aangezien de before/after-vergelijking de grootte ongeveer verdubbelt. Bevat in beide gevallen de x-pbo-*-metadata, ongeacht of deze in de body terechtkomt of als aparte HTTP-headers voor uw eindpunt — maar sluit standaard transportheaders zoals Content-Type en Authorization uit. Vergelijk dit met de limieten voor payloadgrootte voordat u in productie op een tabel vertrouwt.

Send Test Payload is hier anders dan die op Setup: het plaatst de daadwerkelijke payload van het momenteel weergegeven record in de wachtrij voor echte aflevering via dezelfde Event Queue die een vastgelegde gebeurtenis zou gebruiken, zodat u de aflevering end-to-end kunt bevestigen — niet alleen de vorm — zonder te wachten op een echte wijziging. Het wordt altijd verzonden als een insert-gebeurtenis en gaat altijd uit, ongeacht of Insert Event voor de tabel is ingeschakeld of of het record op dit moment door het Insert-filter komt — de hierboven getoonde ✅/❌ is alleen informatief en beperkt deze knop niet. Controleer daarna de Event Queue voor het afleveringsresultaat.

Gebruik de acties First Record / Previous Record / Next Record om door de werkelijke records in de onderliggende tabel te bladeren en te zien hoe de payload van het ene record naar het andere verandert — handig om te bevestigen dat filters en gerelateerde velden zich gedragen zoals verwacht over een reeks echte gegevens, niet alleen één voorbeeldrecord.

Headers & eigenschappen

Elke gebeurtenis bevat een vaste set x-pbo-*-metadata die door Business Central wordt gegenereerd, onafhankelijk van de velden die u op de tabel heeft geregistreerd:

Header	Waarde
x-pbo-company-name	Het bedrijf waarin de gebeurtenis is geactiveerd.
x-pbo-environment-name	De naam van de Business Central-omgeving.
x-pbo-is-production / x-pbo-is-sandbox	Alleen aanwezig (true) voor het omgevingstype dat daadwerkelijk overeenkomt — nooit beide, en bij sommige omgevingstypen geen van beide.
x-pbo-company-badge	De Custom System Indicator Text van het bedrijf, indien ingesteld — anders weggelaten.
x-pbo-event-type	insert, modified, rename, of delete.
x-pbo-table-name	De naam van de tabel, zoals geregistreerd bij Event Tables.
x-pbo-modified-at	Het tijdstip van de laatste wijziging van het record.
x-pbo-tenant-id	De Business Central-tenant-ID.
x-pbo-aad-tenant-id / x-pbo-aad-tenant-domain-name	De Entra ID-tenant achter deze omgeving.
x-pbo-user-id / x-pbo-user-email / x-pbo-user-fullname	De uitvoerende gebruiker — wordt alleen verzonden als Include User Data is ingeschakeld (zie Setup → General), en de e-mail/volledige naam alleen als die gebruiker daadwerkelijk een waarde daarvoor heeft ingesteld.

Waar deze metadata daadwerkelijk terechtkomt, hangt af van het Endpoint Type — voor drie ervan zijn het echte HTTP-verzoekheaders, voor de andere drie is het in plaats daarvan een sleutel binnen de JSON-body:

Endpoint	Waar deze metadata terechtkomt
API endpoint, Azure Service Bus, Azure Event Hub	Letterlijke HTTP-verzoekheaders — nooit binnen de JSON-body.
RabbitMQ	Binnen de berichtbody, onder properties.headers van de AMQP-envelop — RabbitMQ's eigen concept van berichteigenschappen/headers, geen HTTP-headers.
Azure Event Grid	Binnen de berichtbody, onder data.headers van de EventGridEvent-wrapper.
Azure Queue Storage	Binnen de berichtbody, onder een eigen top-level headers-object (naast event_type, table_name en payload). Alleen x-ms-version wordt toegevoegd als letterlijke HTTP-header.

Berichtvoorbeeld noemt deze metadata altijd "Headers" (behalve bij RabbitMQ, waar in plaats daarvan de volledige berichtenvelop wordt getoond), ongeacht welke van de twee bovenstaande categorieën daadwerkelijk van toepassing is — specifiek voor Azure Event Grid en Azure Queue Storage is wat het voorbeeld "Headers" noemt, wat uiteindelijk ingebed wordt in de request body op de lijn, niet verzonden als letterlijke HTTP-headers.

Send Test Payload

Op Event Bridge Setup verstuurt Send Test Payload één dummy-gebeurtenis (een vaste {"Test Message": "Hi!"}-payload, gebeurtenistype insert, tabelnaam Test) rechtstreeks naar het geconfigureerde eindpunt, onmiddellijk en buiten de wachtrij om. Het is een snelle manier om te bevestigen dat uw eindpunt-URL en autorisatie end-to-end correct zijn, zonder dat er al een tabel geregistreerd hoeft te zijn.

De foutmeldingen lezen

Wanneer het verzenden van een gebeurtenis mislukt — direct in het Send Test Payload-dialoogvenster, of als Error Message van een item in de Event Queue — is het bericht een van de volgende:

• "HTTP requests are blocked by your environment settings." — Uitgaande HTTP-aanroepen zijn nog niet ingeschakeld voor deze extensie. In het Send Test Payload-dialoogvenster verwijst dit rechtstreeks naar Extension Management, waar u uitgaande HTTP voor BC Event Bridge moet inschakelen.
• "Failed to send event. Server responded with <status>: <reason>." — Het eindpunt is bereikt, maar heeft het verzoek geweigerd. De statuscode en reden zijn uw beste aanwijzing — een 401/403 wijst meestal op Authenticatie, een 413 op het overschrijden van de limiet voor payloadgrootte van uw eindpunt, al het andere op de eigen logboeken van het ontvangende systeem. Bij OAuth 2.0 probeert Business Central bij een 401 al één keer opnieuw met een verse token voordat deze melding wordt getoond, dus een 401 hier betekent dat ook die nieuwe poging is mislukt — controleer de app-registratie zelf, niet alleen een verouderde cache.
• "Unable to acquire an OAuth2 access token. Verify the token endpoint, client ID, client secret and scope..." — Business Central kon de client-credentials-flow niet voltooien. Controleer die vier velden ten opzichte van uw app-registratie; zie OAuth 2.0.
• "Unable to build a SAS authorization header. Verify the SAS key name and value..." — De sleutelnaam of -waarde van Azure SAS Token op Setup ontbreekt of is niet opgeslagen.
• "Unable to build a Storage SAS request URL. Verify the SAS token..." — De Storage SAS Token op Setup ontbreekt, is niet opgeslagen, of is verlopen.
• "Unable to build an Event Grid SAS authorization header. Verify the access key..." — De toegangssleutel van Event Grid SAS Token op Setup ontbreekt of is niet opgeslagen.
• "Unable to find a valid endpoint setup." — Een verplicht veld voor uw geconfigureerde Endpoint Type is leeg (RabbitMQ API URL; API Endpoint; Service Bus Namespace/Queue-Topic Name; Event Hub Namespace/Event Hub Name; Storage Account/Queue Name; of Event Grid Topic Endpoint). In het Send Test Payload-dialoogvenster verwijst dit naar Event Bridge Setup.

Wie ziet deze fouten

Een mislukte aflevering van een echte, vastgelegde gebeurtenis onderbreekt de gebruiker wiens actie deze heeft veroorzaakt niet en informeert hem of haar ook niet — het wordt stilzwijgend geregistreerd op dat item in de Event Queue met status Error, en nergens anders binnen Business Central. Niemand ziet het, tenzij er actief naar gezocht wordt.

Als u voor iets operationeel belangrijks op Event Bridge vertrouwt, controleer dan regelmatig de Event Queue — of nog beter, bewaak de aflevering vanaf de ontvangende kant (RabbitMQ of de eigen logboeken van uw API-eindpunt) — in plaats van te verwachten dat fouten automatisch aan u worden teruggekoppeld.

Wie dit kan gebruiken

Voor Berichtvoorbeeld en Send Test Payload is dezelfde Event Bridge Admin-toegang vereist als voor Setup en Event Tables — zie Licenties en toegang.