RICS is one of the leaders in retail services industry.
The following service is very flexible for business, needs product stock and nomenclature control. As the majority of modern services it has its own API. This API has a specific feature that does not allow to send a request at any time you need it. Therefore it’s necessary to accumulate the data. For this purpose RICS provides several feeds:
- Product feeds is used for adding and updating products;
- Price feeds is used for price updating;
- Inventory feeds — product stock data updating.
To meet customer requirements and reduce RICS expenses, the following scheme has been suggested:
On this scheme, “Bridge” is a certain service, which could accumulate all requests from RICS and responses from e-commerse stores (Magento1, Magento2) for succeeding back and forth transfer. Services communication is carried out via REST API using JSON data format. One of the customer required to easily add another store to Bridge, which could receive updates from RICS as well as send it to Bridge orders. The scheme of Bridge is given below.
Since the following service is quite simple, use of a full size framework wasn’t expedient, instead it was decided to use slim framework Silex. Silex was chosen due to the fact it has large community and its quite simple in development, additionally there is a bundle for using RabbitMQ already written for this framework. It has been decided to use RabbitMQ for providing rapid data transfer from RICS to stores, and avoid data transfer blocking, in case one of the store is not available. As the database MySql 5.7 was used. MySql is the reliable, simple and checked database, and starting from version 5.7 it’s easy-to-use with the JSON data format, including JSON fields indexing, therefore MySql completely suited us.
The basic idea of Bridge is simple. When data is sent from RICS to Bridge, it gets written to the database and sent to RabbitMQ. RabbitMQ is configured in such a way that each store corresponds with its queue. This allows to send updates to all the stores simultaneously and avoid blocking in case one of the stores is not available or works slowly. Basically for this pattern MySql is not needed as the data is transfered to RabbitMQ immediately and the database is not used. Database is only being used for requests and response logging from e-commerce stores. This is done so that messages can be sent later in case the stores are not available. Besides, there is a possibility provided to send data not through RabbitMQ but by means of mysql+cron to take care of the situation when RabbitMQ is not available due to some reasons.
To subscribe for the updates from RICS in Bridge a new store needs to be registered. To do this URL and accesses to the store must be added, new queue must be created in RabbitMQ.
In our case e-commerce stores were developed on Magento 2.0 EE. Therefore for this platform we have created an extension to integrate Bridge and Magento 2.0. The extension functioning lies in the fact that orders will be sent to Bridge that will be later sent to RICS and quantity of products coming from Bridge will be updated. As Magento 2.0 EE provides a possibility to work with RabbitMQ from the box, we have decided to apply it in our extension. Such a solution allows to send orders to Bridge almost immediately without blocking of the frontend part of the store. In the course of integration development a solution was found which turned out to be quite simple and easily scalable. New Magento 2.0 features such as RabbitMq have been used. It is worth mentioning that working with RabbitMQ in Magento 2.0 is well organized.
You can read more about RabbitMQ in this article.
Partner With Us
Looking for a partner to grow your business? We are the right company to bring your webstore to success.
Talk to Andrey
Nice Blog. Thanks for sharing it with us.