Vtiger and RabbitMQ - updating data in a Laravel application

We continue our course on the topic "Asynchronous Vtiger with RabbitMQ". In our first episode, we did all the necessary preparation: installed RabbitMQ and Vtiger, connected the package manager, installed Laravel and learned how to create contacts in Laravel through events in Vtiger.

At first glance, everything was quite simple - we created a custom function, installed the necessary packages and sent the data to the queue. And then we accepted them in our laravel application.

Our handler will run every time we create a contact.

But we have not considered other scenario - what if we make changes in the contact, for example, phone number or last name? We need to somehow update them in our Laravel application too!

In the current implementation, this is not possible and too expensive. We send the entire array with contact information. And we would like to send only those fields that have been changed. In our case, we must pass contact ID and phone number to the queue.

Therefore, in this video, we will create an event that will fire before each save and will transmit the event to RabbitMQ and then process it in Laravel.

The way we send messages to RabbitMQ is still very simple - we call publish on exchange. As a routing, we use the name of the queue and as the content of the message, we transfer an array of data. Often you will need to include additional parameters in the message:

• content_type (string): The message will be received by a third-party application as an array of bytes and the final recipient does not know what to do with this data unless we explicitly say what this array is.
• content_encoding (string): A specific encoding (UTF-8) is used to serialize messages. And again, so that recipients understand how to work with the message, it is better to specify the name of the encoding explicitly.
• message_id (string): For tracking and debugging, I always advise you to number your messages.
• persistent (boolean): Determines whether the message should be stored on disk or not.

Be aware that messages marked as non-persistent will be removed from the queue after the broker is restarted. You end up with an empty queue. But at the same time, messages marked as persistent in the non-persistent queue will also be cleared after the broker is restarted. Therefore, if you want to persist messages, you must declare the queue as durable and mark the messages as persistent.

But I don't recommend marking all messages as persistent. This will put unnecessary load on the server. Make only important messages persistent that affect business logic.

You can see a more detailed structure of the message in the screenshot above.

So, we transfer messages to Laravel, parse the received data, find a contact and update the fields received in the message in the portal database. The video with this lesson is attached below, do not forget to like and repost. I will be glad to answer your questions.

If you haven't watched the first video of the course yet, I recommend starting with it.

If you watched this video, go to third episode, where we will try to get messages from RabbitMQ