This section is mainly intended for developers who will be responsible for integrating the connector app with their solution. It provides an overview of how the APIs are implemented within the connector app, helping developers understand what needs to be mapped and how to perform the mapping.
Connector App Implementation
As a developer, there is no need to manually execute any HTTP calls, as the entire process has been abstracted by the Connector App.
Regarding authorization with Wair, the process is streamlined by the connector app. Before any request is sent, the app retrieves an authorization token, stores it in IsolatedStorage, and updates its expiration time. This ensures that, as long as the token remains valid, subsequent requests can reuse it without needing to fetch a new token from Wair, thereby optimizing the efficiency of the communication process.
Since the connector app automatically handles tasks like constructing JSON payloads, selecting endpoints, and managing authorization, custom solution implementations can focus solely on utilizing the dedicated API handlers for integration.
Each endpoint in the connector app is managed by a dedicated API handler, ensuring that the specific needs of that endpoint are addressed in its implementation. There are a total of 29 endpoints, as detailed in the Wair documentation, and each one has a unique implementation that can be utilized during the mapping process with a custom solution. By familiarizing themselves with these implementations, developers can more efficiently and accurately map the connector app to their specific requirements.
The following API Handlers exist in the connector library:
"Brand Api Handler WRS"
"Category Api Handler WRS"
"Collection Api Handler WRS"
"Color Api Handler WRS"
"Currency Api Handler WRS"
"Disc. Reason Api Handler WRS"
"Image Api Handler WRS"
"Image Url Api Handler WRS"
"Item Api Handler WRS"
"Location Api Handler WRS"
"Material Api Handler WRS"
"Merch. Cat. Api Handler WRS"
"Merch Cat Lvl. Api Handler WRS"
"Purchase Order Api Handler WRS"
"RecommendedTransferApiHndlrWRS"
"RecommStockTargetApiHandlerWRS"
"Sales Api Handler WRS"
"Season Api Handler WRS"
"Size Api Handler WRS"
"Stock Api Handler WRS"
"Stock Mutation Api Handler WRS"
"Stock Targets Api Handler WRS"
"Telemetry Logger WRS"
"Theme Api Handler WRS"
"Transfer Api Handler WRS"
"UoM Api Handler WRS"
"Vendor Api Handler WRS"
"ProductDescrTagApiHandlerWRS"
"ProductDescriptionApiHndlrWRS"
Every implementation includes a Send procedure designed to handle a provided proxy record set. The procedure processes the given proxy table by converting the provided data into a JSON format. This JSON is then used for the API request. In some cases, this procedure includes a parameter called FullLoad, which can be further explored in the linked documentation to understand its specific function. The procedure returns a Boolean value to indicate whether the request was successful.
Delete Entries
Certain API Handlers include a Delete procedure, which is responsible for sending a delete request to Wair using a URL generated from the Delete Log Entries specific to that endpoint. These Delete Log Entries are not automatically created — they must be generated by the developer or partner as part of the custom solution's implementation of the Connector App.
To create these entries, the custom solution must call the CreateWairDeleteLogEntry procedure, located within the "Delete Log Management WRS" codeunit. When invoking this procedure, it is necessary to provide two key pieces of information:
The entry type specifies the nature of the deleted log entry (Brand, Category, Item, etc.).
The record ID (In most implementations, it will be an automatically generated system field of the record - SystemId).
This process ensures that the delete operations are accurately logged and properly executed for the relevant endpoint. Proper implementation of this procedure within the custom solution is essential for maintaining consistency and traceability of delete requests sent to Wair.
Proxy Tables
Each endpoint in Wair has a corresponding proxy table within Business Central. The following proxy tables are created in the Connector App for sending and receiving data:
Table Name | Description |
|---|---|
Image | Used in |
Brand | Used in |
Category | Used in |
Collection | Used in |
Color | Used in |
Item | Used in |
ItemAttribute | Used in |
ItemCategory | Used in |
ItemSkuBarcode | Used in |
ItemStockKeepingUnit | Used in |
ItemStyleAttribute | Used in |
ItemUnitOfMeasure | Used in |
Material | Used in |
MerchandiseCategory | Used in |
MerchandiseCategoryLevel | Used in |
Season | Used in |
Size | Used in |
Theme | Used in |
UnitOfMeasure | Used in |
PurchaseOrder | Used in |
PurchaseOrderLine | Used in |
Vendor | Used in |
RecommendedProductDescription | Used in |
RecommendedProductStyle | Used in |
RecommendedProductTag | Used in |
RecommendedStockTarget | Used in |
RecommendedTransfer | Used in |
RecommendedProdDescrTag | Used in |
Currency | Used in |
Discount | Used in |
DiscountReason | Used in |
SalesOrder | Used in |
SalesOrderLine | Used in |
Location | Used in |
Stock | Used in |
StockMutation | Used in |
StockTarget | Used in |
Transfer | Used in |
TransferLine | Used in |
When filling the proxy tables, it is mandatory to use the Insert(true) method. The OnInsert trigger will use Testfield to check if all mandatory fields are populated.
It's important to note that errors related to Testfields tend to be technical. For mandatory fields, if more user-friendly error messages are desired on the UI, these fields should be checked before the insertion process. This allows for more intuitive error handling, ensuring that if a mandatory field is missing or incorrect, a clear and user-friendly error message is displayed, rather than a technical one. Implementing this approach improves the overall user experience by preventing confusion and making error resolution easier for end users.