1C:Drive and REST API integration

Question:

We need to export data to a client's B2B site via the REST API. For example:
When the B2B site triggers the REST API, the products found in the 1C:Drive database will be sent. We want to share a REST API link with the B2B site and send the B2B site login information to this link. After the login information, we will send the products added that day as a JSON bundle.
The same way: a sales order will be created on the site, and when the B2B site sends this information, it will be saved in 1C:Drive. Likewise, it should be able to save orders to the 1C:Drive database via a REST API link connected with login information. Product lines can be cycled in orders. All processes will be triggered by the B2B site.
Can we implement this?

Answer:

First, let's discuss this: "When the B2B site triggers the REST API, the products found in the 1C:Drive database will be sent."

This solution only works when the B2B site is first populated with information from the 1C:Drive database. This procedure does not work for changes to the list of products. Let's assume that some time after the list of all products is transferred from 1C:Drive to the B2B system, a new product is created in 1C:Drive. That product has not yet been transferred to the B2B site. If the only way to transfer data between 1C:Drive and the B2B site is to transfer the list of all products on the initiative of the B2B site, how do we transfer the newly created product from 1C:Drive to the B2B site? The following problems appear in this instance:

a) B2B site has no information whether the product list has been updated in 1C:Drive. Therefore, the B2B site needs to send data transfer requests periodically, regardless of whether there is a change in the product list in 1C:Drive. This puts unnecessary load on the system.

b) We have 2 options for updating the product list on the B2B site:

• Deleting all product information currently available on the B2B site and transferring the full product list again from 1C:Drive to the B2B site. This can lead to many adverse issues. For example, if a user has any products in their basket on the B2B site, during the data transfer process, their basket may be unexpectedly emptied because all product information is deleted from the B2B site.
• Comparing the old product data available on the B2B site with the latest product data in 1C:Drive, and transferring only the differences to the B2B site. This option works better than the first one, but it is very complicated to implement. For example, we need to learn how to identify products that exist on the B2B site but are not in the 1C:Drive database containing up-to-date information (for example, because they were deleted by the user), so that we can delete these products from the B2B site.

Now, let's proceed to the next point: "All processes will be triggered by the B2B site."

A much better solution is to set up bidirectional data exchange between the B2B site and 1C:Drive. This means that both the B2B site and 1C:Drive should have their own APIs so that they can “talk” to each other bidirectionally. The principle should be like this:

a) Data transfer is initiated by the side where the product data has changed. If the data has changed on the 1C:Drive side, 1C:Drive must call the API on the B2B site and notify this API about the change. If there has been a change on the B2B site, then the B2B site must call the API on the 1C:Drive side and notify it about the change.

b) Each unique data exchange is transmitted to the other party using a separate query. For example:

• Let's say a new Sales order has been created on the B2B site. Then the B2B site will send a message to 1C:Drive: "POST /sales-orders/{id} + JSON sales order data".
• Let's say the name of the product has changed on the 1C:Drive side. Then 1C:Drive will send a message to the B2B site: "PUT /product/{produc_id}&name="new name".
• Let's say the product has been deleted on the 1C:Drive side (the products catalog item has been deleted from the database). Then 1C:Drive will send a query to the B2B site: "DELETE /product/{id}".

Extra comments:
           
1) We have two nodes in our distributed system: the 1C:Drive node and the B2B site node. Ideally, there should be a clear separation of the nodes' roles. One of the nodes should be an active node (master), and another one should be a passive node (slave). The 1C:Drive node is responsible for the data changes. It would be better if it is also responsible for initiating data exchange.

In this case, every data change will trigger the B2B site REST API request that will send a specific change to the site. It will require the B2B site to have this REST API, of course.

This approach has a lot of advantages compared to the B2B site being in charge of the data exchange.

2) We need to make sure we clearly map each 1C:Drive product to the corresponding B2B site product. We should store Catalogs.Products.Ref.UUID() to the B2B site, along with other product attributes, so we can find each product easily when we need to change or delete it.

3) If there is no way of calling B2B REST API from 1C:Drive and the data exchange is triggered by the B2B, we need to use Exchange Plans to track all data changes in 1C:Drive.