Vtiger и RabbitMQ - обновляем данные в приложении на Laravel

Продолжаем наш курс на тему "Асинхронный Vtiger с RabbitMQ". В нашем первом эпизоде мы провели всю необходимую подготовительную работу: установили RabbitMQ и Vtiger, подключили менеджер пакетов, установили Laravel и научились создавать контакты в Laravel через события в Vtiger.

На первый взгляд, всё было довольно просто - мы создали пользовательскую функцию, установили необходимые пакеты и отправили данные в очередь. И затем приняли их в нашем приложении на laravel.

Наш обработчик будет запускаться каждый раз, как только мы создаём контакт.

Но мы не рассмотрели сценарий - что делать, если мы производим изменения в контакте, например, номер телефона или фамилию? Нам же нужно каким-то образом обновить их и в нашем приложении на Laravel!

В текущей реализации это не возможно и слишком дорого. Мы отправляем весь массив с информацией о контакте. А нам бы желательно отправлять только те поля, которые были изменены. В нашем случае мы должны передать в очередь ID контакта и номер телефона.

Поэтому в данном видео мы создадим событие, которое будет срабатывать перед каждым сохранением и будем передавать событие в RabbitMQ и затем обрабатывать его в Laravel.

Способ передачи сообщений в RabbitMQ у нас по-прежнему очень простой - мы вызываем publish у exchange. В качестве роутинга мы используем название очереди и в виде содержимого сообщения мы передаём массив данных. Часто вам понадобится включать в сообщение дополнительные параметры:

• content_type (string): Сообщение будет получено сторонним приложением в виде массива байтов и конечный получатель не знает что делать с этими данными, если мы не говорим явно, что представляет собой этот массив.
• content_encoding (string): Для сериализации сообщений используется определённая кодировка (UTF-8). И снова, чтобы получатели понимали, как работать с сообщением, лучше указать название кодировки явно.
• message_id (string): Для отслеживания и дебага всегда советую нумеровать сообщения.
• persistent (boolean): Определяет, должно ли сообщение храниться на диске или нет.

Имейте в виду, что сообщения, помеченные как non-persistent, будут удалены из очереди после перезапуска брокера. В итоге вы получите пустую очередь. Но в то же время, сообщения, помеченные как persistent в non-persistent очереди, также будут очищены после перезапуска брокера. Поэтому, если вы хотите сохранить сообщения, вы должны объявить очередь как durable, а сообщения помечать как persistent.

Но не советую помечать все сообщения как persistent. Это даст лишнюю нагрузку на сервер. Делайте постоянными только важные сообщения, влияющие на бизнес-логику.

Более подробную структуру сообщения вы видите на скрине выше.

Итак, мы передаём сообщения в Laravel, парсим полученные данные, находим контакт и обновляем полученные в сообщении поля в базе портала. Видео с данным уроком приложено ниже, не забывайте ставить лайки и делать репосты. Буду рад ответить на ваши вопросы.

Если вы ещё не посмотрели первое видео курса, рекомендую начать именно с него.

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