Integration Messages

The Integration Messages page shows you the inbound integration messages received by Business Central and the outbound integration messages sent by Business Central. The data in this table is specific to the company.

Find Text in Message Content

The Find Text in Message Content action allows you to find a message containing a specific value. For example, you can search for 4534516027.

Note when using this feature:

• You must first specify filters to limit the number of records (e.g. filter on a date range, message type, etc.).
• The search feature is only against the message content. It does not search any other fields. You can use standard Business Central search features to do that.
• The action opens a filter page. Under integration entries, you will see the filters you have already applied in the page. You can add more fields and specify filters on these fields if you wish.

_

note

While the app does use a filter page to capture the Text Search String, the Text Search String is NOT interpreted as a filter. value and search for a value that matches it. It is NOT case sensitive.

View Message Details

From the Integration Messages page you can open the Message Details page, which shows you details about the message including:

• Message Properties
• Message Body (payload)
• Processing Message/Error
• Error Call Stack
• Error Classification

The following actions are also available:

• Export Message Content - exports to a text file
• Export Message/Error - exports the message or error to a text file
• Create Error Classification Rule - opens a wizard to create an Error Classification Rule. You can read more about this here.

Testing Integration Messages

You can test inbound/outbound integration handlers from the lists or cards without having to call an endpoint.

Integration Record ID in Integration Messages

This field reflects the last Record ID of the related integration event. For example, if the event resulted in the creation of a single sales order, this record ID will be the record id of that order. From here you can drill down to view the record on a page.

The drill down only caters for a pre-defined list of standard Business Central tables. The following tables have specific logic to open the relevant card page:

• Sales Header: has logic to take you to the relevant page based on the document type. If the record no longer exists it looks for a posted invoice/credit memo and takes you there instead.
• Sales Invoice Header
• Sales Shipment Header
• Sales Cr. Memo Header
• Item
• Customer
• Vendor

There are also many other standard tables supported by this feature. However these are handled generically and will open the LookupPage for the table. You can subscribe to the following events to extend this:

• OnOpenIntegrationRecordPageForCustomEntity - this allows you to handle a custom table
• OnBeforeSetRecordVariantFromRecordRef - if you only want to allow the table to be access using it's default lookup page (you also use this event to allow you to test the outbound integration handler)

Error Classification

The Integration Hub includes a feature to classify errors that occur during integration automatically. The classification assists with faster resolution of failed integration messages - especially during UAT when handling complex integrations with high transaction volumes.

Error Classifications

Here you define the different classifications you want to assign to failed messages. You can also see a count of failed messages per classification. When you install or upgrade the app, you will find that the app creates some default records to handle common scenarios. You can access the Error Classifications from the Integration Messages page.

Field	Purpose
Id	This is a system-generated Id.
Description	A meaningful description of the classification.
Error Group Code	This is an optional field that you can use for analysis
Default	This specifies that the error classification is the default assigned if no rules are defined that apply to the failed message.
Failed Messages - Current	This is the count of failed messages that still need to get handled. You can drill down to the integration messages.
Failed Messages - All	This is the count of all failed messages - even those already handled. You can drill down to the integration messages.
No. of Rules	This is the count of Error Classification Rules that get used to identify this classification.

note

If you use the orchestration model implemented by Theta, you will find that some errors get handled automatically. These errors would still initially be classified, but they get retried automatically.

tip

If you show the Fact box pane, you can add notes or links to provide support or procedural instructions.

Error Classification Rules

Here you define rules that get used to assign Error Classifications. The rules also serve as a sub-classification of errors. You can access this page from the Integration Messages page and the Error Classifications page.

You can add and edit the rules on this page. However, using the wizard, which you can read about here, is more straightforward. You can also get the count of failed messages from this page.

Field	Purpose
Id	This is a system-generated Id.
Description	A meaningful description of the classification.
Error Contains	a text substring that will occur on a message for this rule to be applicable. This substring must not contain transactional data such as document numbers, else the rule will not trigger.
Failed Messages - Current	This is the count of failed messages that still need to get handled. You can drill down to the integration messages.
Failed Messages - All	This is the count of all failed messages - even those already handled. You can drill down to the integration messages.
Error Classification Id	This is the error classification that the rule is associated with.
Error Classification	The description of the error classification.
Error Group Code	The error group linked to the error classification.
Source	This gets used as a filter for the rule. You specify this if the rule only applies to a specific source.
Destination	This gets used as a filter for the rule. You specify this if the rule only applies to a specific destination.
Message Type	This gets used as a filter for the rule. You specify this if the rule only applies to a specific message type.
Change Status	Specifies that you want to change the status of the integration entry when you receive this type of error.
Change Status To	Specifies the status you want the integration entry to get changed to when you have set that you wish to update the status.

tip

If you show the Fact box pane, you can add notes or links to provide support or procedural instructions.

Add new Error Classification Rules

You can use a wizard to create new rules. The action is available from the Integration Messages page.

Step 1: Classify the Error

1. Select an Error Classification Id to specify how you want to classify the error.
2. Specify a meaningful description of the new rule.
3. Copy a substring from the error message at the bottom of this page that will always occur. This substring must not include any transactional details such as document numbers.
4. Click next.

Step 2: Specify if this rule only applies to specific messages

If you want the rule to only apply to specific messages, then you select Create for this message type only. In our example, we want this to apply to all message types.

Some errors will be common to all messages from the same source or destination. If this applies to your error, only specify the value that will always occur. For example, remove the destination and message type if this error occurs on all transactions from a specific source.

Finish

Review the changes and then click Finish.

note

The Reclassify Failed Messages is selected by default. When set, the app will reclassify the integration errors based on the latest rules - including the new error classification rule you just added.

Review Error Classification Rules

The Error Classification Rules page gets opened after the failed messages get reclassified, so you can review the new rule and see how many errors fall into this classification.

Addition Information

The *Additional Information- table gets used to store data that cannot be mapped to a business central field. This is commonly used to store values that are meaningful to an EDI Partner.

Helper Functions

Additional functions have been added to this table when you want to create or refer to this data in code.

Custom Parameters

You can define custom parameters against inbound and integration handlers. You can use these parameters instead of hard-coding values in your code (when the integration requires additional business logic).

The data gets stored in the additional information table. There are also helpers in the additional integration table to access/create/update these parameters from code.

Telemetry

ID	Feature	Type	Comments
IF010	Integration event entry inserted	Usage
IF020	HTTP Call Made by Integration Hub	Usage

Example Query

Show all telemetry for the last 3 hours

traces
| where timestamp > ago(3h)
| where  customDimensions.eventId contains 'ALIF0'

Count events per 15 minutes for the last 3 hours

traces
| where timestamp > ago(3h)
| where  customDimensions.eventId contains 'ALIF0'
| project 
    timestamp
    ,addId =  tostring(customDimensions.aadTenantId)
    ,environmentName = tostring(customDimensions.environmentName)
    ,environmentType = tostring(customDimensions.environmentType ) 
    ,companyName = tostring(customDimensions.companyName) 
    ,eventId = tostring(customDimensions.eventId)
    ,message
|summarize EventCount=count() by addId, environmentName,companyName , EnvironmentType, EventId,message , Time=bin(timestamp, 15m)