Administration and health check

Every message between companies, logged

See what was sent, received or failed, and retry.

What it does

The message log shows success, failure and in-process messages, filters by date, time, sender and receiver; failed messages retry automatically and old successes are removed after the time you set.

When you need it: Finding why one invoice did not arrive.

How it works

  1. In the console open Monitoring › Message Log. Set the time window in "From" and "To" (it opens on today, midnight to 23:59:59) and narrow it by "Sender System", "Receiver System", sender object, receiver object and "Status". Choose the rows per page and press "Display log".
  2. Each row is one message between two companies. For a failed one, open the link in the "Payload" column to read what went wrong.
  3. Correct the cause, for example a missing master record or mapping, and press "Retry" on the row, or "Retry All Errors" above the table.
  4. To repeat failures without anyone pressing a button, open Preferences › Auto Retry Errors, choose a daily or weekly run and the hour, and press "Activate".
  5. To stop the log growing, open Preferences › Manage Logs and enter after how many days success messages and the various histories are deleted, and how often a failed message is retried.

Set it up

The guide suggests deleting each log after 30 days and setting no more than 5 retries: every retry uses server resources and makes the integration framework's database bigger. "Reset" on the auto-retry page stops any retry run in progress. A large log can also be cleared by hand for a date range with "Delete Log".

Since: Version 54 (April 2025): failures in replication through the Service Layer show a precise error in the message log instead of a general HTTP 400 message.

Good to know

  • The cockpit tile "Message Log of Today" counts successful, failed, filtered and in-process messages and opens the log; the tiles for in-process and failed replication open it already filtered.
  • Automatic retry fits errors caused by missing data that the customer can supply: once the data is there, the message goes again at the set time.
  • Monitoring › Notification Log lists failed alerts and emails, with the same payload and retry links.
  • Preferences › Audit Log records changes made in the console; events started by the system show "B1i Queue" as the user.