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.
_
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 tableOnBeforeSetRecordVariantFromRecordRef
- 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. |
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.
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. |
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
- Select an Error Classification Id to specify how you want to classify the error.
- Specify a meaningful description of the new rule.
- 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.
- 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.
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.