Big Commerce Update Product implementation

Summary of Changes: (The purpose of this table is to keep traceability and Product team to highlight the things that were changed into the scope, based on comments or discussions)

When updating a product on Big Commerce, there are four steps/API calls to be done in order to fully update the content.

1. First one is update the product - Big Commerce Update Product
2. Second one - Big Commerce Update Product Variant
3. Then - Big Commerce Channel Assignment
4. And finally - Big Commerce Delete Product Custom Fields

The four actions will be chained one after the other, e.g. using the following design pattern. Imagine each handler as a single class extending an appropriate Cron abstraction (it might even be a custom one for the project if needed). First handler will be a special one which will select the products for update.After that every handler will work with the same products.

The difference with the crons which are done until now is that they won’t save success, i.e. update the flag to “Not Needed”, for the processed listings. The last handler will do this job. It is better to separate the success saving into a separate handler in order to have the flexibility to change the order of handlers if needed.

About the errors - every cron/step will save its errors and make sure the relevant listing won’t reach to the next step.

<v1.1>Please not that due to the complexity of the cron we are updating only flag Product Account > List / Update the Whole Item to Sent, Error and Not Needed. To make things clear - this means that we are not updating Update Quantity and Update Price even though we are sending quantity and price for unprotected products. </v1.1>

The goal is to select all the listings in the first handler and store them somewhere in a way that we are able to work with them in all next handlers. Please see the diagram below. Some custom work will be needed to change the behaviour of the abstraction.

Please note that there will be only one bin file for this and the handler will be created and ordered inside it.

Also there will be a step field (Product Account Big Commerce > Update Step) in order to be aware at which step happened an error/ a script failure. It will be invisible for the users, visible only to the devs. This field will be updated by a shutdown handler if something happens to the script. The data for it will be kept somewhere in a static array. A singleton or something else as the dev wished to implement it.