Connector App Libraries

Brand

To start, consider the straightforward implementation of the brand endpoint. This endpoint is managed by the "Brand Api Handler WRS" codeunit (as previously mentioned, each endpoint has its own implementation codeunit). Within this implementation, there is a Send procedure, which, as outlined in the Brand Wair Endpoint POST /Brands, includes a FullLoad query parameter.

Because this parameter is part of the documentation, the Send procedure also incorporates it.

Picture 8: Brand Api Handler Send procedure

The procedure processes the provided temporary brand record set, iterating through each record to generate a JSON payload with predefined request values such as brandId, code, and description. This design eliminates the need to manually ensure the correct Wair endpoint values are used when creating a request, as the connector app handles this automatically.

Picture 9: Brand Json creation

An important note is that certain optional values will only be added to the payload if they’re not empty.

Picture 10: OnInsert() trigger field check

Values mandatory in the Wair API are checked for emptiness on the OnInsert trigger of proxy tables. To identify which values are required, refer to the Wair API Swagger documentation. All the mandatory values are marked with the red asterisk as displayed below.

Picture 11: Mandatory fields

Given that the Brand API on Wair includes a delete request endpoint, the "Brand Api Handler" also incorporates a corresponding procedure, named Delete. This procedure handles the delete request by sending all records with the type "Brand" in the Delete Wair Log Entries table. Upon execution, if the delete request is successfully processed, the procedure returns true, indicating that the operation was completed successfully.

Picture 12: Brand Delete procedure

Details on how to map to this endpoint can be found here: POST /Brands.

Item

Now let’s check a more complicated endpoint – Item. This implementation has limits and multiple arrays inside the request itself. For each array inside the item, there is a proxy table created that needs to be passed as a parameter to this procedure from the custom implementation.

Picture 13: Item Api Handler Send procedure

The procedure sends a POST request to Wair with the payload created from the items provided. The principle is the same as in the example above – brands, however, if the number of provided items exceeds the limit set in the Wair connector setup, the procedure will split the request into multiple parts and send multiple requests to Wair. If any of the parts fail, the procedure will return false — however, some parts might have been sent successfully. Every item that has been successfully sent will have the "Is Successful" field set to true. The procedure takes several parameters:

• Item

• ItemAttribute

• ItemStyleAttribute

• ItemStockKeepingUnit

• ItemSkuBarcode

• ItemCategory

• ItemUnitOfMeasure

All these parameters are used to generate the payload and send it to Wair. Keep in mind that additional record sets are not mandatory (only Item is mandatory) – this means that if the Item does not have a category, an empty table can be passed into this procedure.

All the additional record sets are according to the documentation:

• ItemAttribute record set is an array of attributes for the specific Item

• ItemStyleAttribute record set is also an array of attributes for the specific Item

• The same is true for the other record sets.

Picture 14: Item endpoint arrays

Purchase Orders

The Purchase Order Endpoint introduces a new query parameter – moreRecordsAvailable. For endpoints that can have large datasets, an additional query parameter can be used in the case of a full load. With this query parameter, you indicate if there are more API calls following, to prevent the data not included in the API call from being cleared. This endpoint implementation also has a limit, and all that differs from the Item implementation is that this has both parameters in the URL:

• FullLoad

• MoreRecordsAvailable

From the code itself, it is also the same as with Items – if the number of provided purchase orders exceeds the limit set in the Wair connector setup, the procedure will split the request into multiple parts and send multiple requests to Wair. If any of the parts fail, the procedure will return false — however, some parts might have been sent successfully. Every item that has been successfully sent will have the "Is Successful" field set to true.

For instance, if the limit for purchase orders is set to 10,000 and there is a need to send 25,000 purchase orders, the system will divide this request into three separate parts. The URLs for these requests will be generated accordingly, assuming the fullLoad parameter is used. The first two requests will each handle 10,000 purchase orders, while the third request will process the remaining 5,000 purchase orders. This splitting process ensures that the data is transmitted in manageable segments, adhering to the specified limits from Wair.

The first two requests indicate moreRecordsAvailable as true, whereas the final request has this parameter set to false.

Picture 15: Purchase Order with FullLoad parameter

Getting Recommendations

Separate handlers are available to get the recommendations from Wair:

• ProductDescriptionApiHndlrWRS

• ProductDescrTagApiHandlerWRS

• RecommendedTransferApiHndlrWRS

• RecommStockTargetApiHndlrWRS

Each handler operates similarly: the Retrieve procedure fetches recommended product description tags from a specified endpoint and inserts them into a designated proxy table record, which can then be utilized by the solution.

Please note that the imported text fields that are imported in recommendation API  handlers are truncated to maximum length of the table fields which they are imported to.

Here is the list of maximum lengths of specific table fields:

• Table Recommended Product Style

  • Category – 100 characters

  • Tone Of Voice - 500 characters

  • Confirmed By - 100 characters

• Table Recommended Product Descr.

  • Language Code – 10 characters

  • Language – 50 characters

  • Country Iso2 – 2 characters

  • Country Iso3 - 2 characters

  • Product Title - 250 characters

  • Product Meta Description – 250 characters

  • Product Description – 2048 characters

• Table Recommended Product Tag:

  • Tag Key – 100 characters

  • Value – 100 characters

• Table Recommended Prod Descr Tag:

  • Attribute Type – 250 characters

  • Attribute Value – 250 characters

• Table Recommended Transfer:

  • Reference Id – 80 characters

Picture 16: Recommendation retrieval

To find out how to map the recommendations, check it out here: Mapping app.

Summary

Each of the remaining endpoints is equipped with its own dedicated API handler, implemented in a manner like the approaches described earlier. These API handlers are tailored to meet the specific requirements of their respective endpoints, ensuring consistent and efficient processing of requests. Whether it's handling data transmission, deletion, or retrieval, every endpoint's API handler is designed to manage the necessary operations seamlessly within the framework of the connector app. This structured approach allows for uniformity across the various endpoints while accommodating the unique needs of each.