Introduction
In the synchronization dashboard you can set up and activate all webservice methods that are used to communicate with the e-commerce platform of your choice. This dashboard can be seen as the primary logging and monitoring tool for syncing events and processes.
Each Synchronisation Dashboard is linked to a unique Sales Channel. The channel itself, as shown here, is where the connection to the webshop is configured. When the Tinx app is activated, a set of pre-defined dashboards is imported in the customers BC database, all based on standard BC functionality.
To find the available dashboards, go to Communication > Synchronisation Dashboard.
| Field | Description |
| Code | |
| Description | |
| Direction Type | Define whether it is Inbound or Outbound communication. |
| Status | |
| Processing Policy | |
| Priority | Define the sequence of the different |
| Sales Channel | Define to which Sales Channel the dashboard is linked. |
| API Code | If you are using different endpoints you can choose the API code to set another API endpoint |
| API Type | Define which API type should be used: REST or GraphQL. |
| Job Queue Category | If you are running multiple service tiers define which Jobs should be executed here. |
| Hide inactive Lines | Show or hide the synchronisation lines |
| Comment | Add information about the Dashboard, useful if you have made changes or created a custom Dashboard. |
Mapping
In a given dashboard, for example SHOP_IN_ORDERS, you will see several documents. Each document has a webservice, which shows the endpoint of the REST API on the webshop side we target, as well as a description of the message, whether it is active, the priority of messages, among others.
For each of these lines (or documents), that is, for SHOP-086, SHOP-087-1 and SHOP-087, various settings can be checked from this screen. Filters, for example, determine whether or not a message should be allowed to go through (e.g. is the connector allowed to create a sales header based on certain criteria). Events / Triggers are used to ensure a message, such as the sending of updated stock to the webshop, is triggered if the connector updates a product.
Opening the Message Definition shows you the mapping of each document. As an example, seen below is the mapping of the SHOP-087 message. This message is used to create sales header documents (table 36) in BC, using data received via the orders/%1.json endpoint of Shopify.
As can be seen, we basically look to the JSON response from Shopify (the 'answer' that Shopify gives us when we ask it for information of a specific order) and check various element names (areas in the JSON response) for data. That data is then put into different tables as needed, all for a specific document. In this case the sales header, so tables 36 and 37 are filled in.
Finally, when opening the 'Fields' of a line in the message, we can see the actual fields in the JSON that are mapped/looked at. In the image below, this means that for a sales header that the connector is tasked to create in BC for a given order, the field 100 External Document No. is filled with the value of the <id> field in the Shopify response.
As can be seen as well, there are various types that a field can have in BC and from which data can be obtained or calculated. In the above example, the Sell-to Customer No. is not directly written from the Shopify web order; rather, the value in the <number> field is checked in the TINX Sales Order table. If a match can be found, then the value of field number 73 of that TINX Sales Order table (i.e. Default Customer No.) is used as the Sell-to Customer No.
Triggers
When so-called outbound messages are active, meaning these messages are used to send data from BC to a webshop, modifying relevant data is captured in the Record Queue via triggers. It is from this queue that records are sent to the webshop. The Tinx app uses the Change Log Mgt. function for some of these triggers. The following triggers are used usually in our integrations.
- OnInsert: this filter is based on Primary Keys for records that have not been sent before and which are created by the system. This option is often used for postings, such as the item ledger entry (i.e. stock), posted shipments and sales invoices. If you set the trigger to 'OnInsert', the record will be sent only once based on the primary key. This means that should you want to send a record again, you will have to delete the appropriate entry via History > Registers. You can also use 'OnInsert' to do an initial sync when you are starting an integration.
- OnModify: send information each time a record is manually inserted or modified (i.e. done by our own change log). Data which is modified in a batch process will not be considered (i.e. Rapid Start): only manual changed data done by users has an effect.
- OnDelete: when a record is deleted in BC, you can send an update to the webshop to remove the data, such as a product or price.
- OnSchedule: define the recurrence of the document line in question. An example would be the desire to send daily price updates. This allows you to select a specific time at which the data is processed (e.g. after working hours). Note: this function is only implemented for Magento.
Usage of Outbound Filters
For each line in the document, you can also set the filters for synchronising data. After downloading our standard package, several filters are pre-defined. An example is the filter below which is set up for the sending of new items to a webshop: Publish to Webshop = 1, Product ID = 0 and only from a certain Vendor No..
Below more about filters.
| Field | Description |
| Ignore Filter | Flag this if you don't want to use this filter (in case of testing). |
| Field No. | Define the field you want to use as the filter. This is a search field in which you can find all available fields in the table (i.e. the first table or 'header' in the Message Definition (such as 27 for items). |
| Field Name | A flowfield showing the name / caption of the field. |
| Operator Sign | The criteria of the filter, such as '=', '<>', '>', '<'. |
| Field Filter | The value the filter should have to meet the criteria. |
| Update Filter Value | Relevant for lines which are set to 'OnInsert', such as postings of stock updates, shipments and invoices. The 'Field Filter' will be incremented each time data is sent to the web shop. The field you choose must either be an 'Entry No.' or a field with an incremental value (e.g. the No. Series). This helps to speed up performance when searching tables. |
| Date Expression | This field is used in combination with the 'Reference Date'. If you have a date filter defined like ''|%1.., you might want to filter on a date in the past, which could look like '-60D'. |
| Reference Date | Set the Reference Date to 'TODAY' or 'WORKINGDATE'. If you leave the Date Expression empty, it will automatically use today's date. Otherwise, the data will be calculated based on the Date Expression set. |
If you are using a filter for an Option value, make sure you use the Option Integer value in the 'Field Filter' instead of the Option Textual value. Otherwise, this might cause language problems.
Usage of Inbound Filters
Two types of inbound filters are supported by the connector:
- Filters based on webshop criteria.
- Filters used in combination with the field Info Table No.
Below shows an example of the Info Table No. , used for the TINX Sales Order. These filters are used when processing web orders before creating sales headers in BC (that meet the below criteria).