АСУ для кофеен. Часть 4

Часть 1. Предыстория.

Часть 2. Почему выбран MODX Revolution. Серверная часть.

Часть 3. Работа с оборудованием. Примерная хронология проекта.

Часть 4. Синхронизация данных и обновление компонентов АСУ

Часть 5. Пути решения проблем при «непонятном» поведении движка/компонентов. Реализация складского учета

Часть 6. Текущие функциональные возможности АСУ - 1

Часть 7. Текущие функциональные возможности АСУ - 2.

Часть 8. Текущие показатели АСУ. Желаемые планы. Заключение

Синхронизация данных и обновление компонентов АСУ

Первоначально, пока АСУ была запущена всего в 3-х кофейнях, любые изменения осуществлялись в ручном режиме. Чем больше времени проходило, тем меньше радости возникало при необходимости скорректировать цены, добавить товар или обновить компонент. Благо, с самого начала предполагалось создание центрального сервера (ЦС) и синхронизации всех локальных серверов через него.

В первой версии синхронизатора реализовали поддержку только товаров и категорий. Опять же, в связи с последовательной реализацией сначала сделали инструмент переноса товаров в кофейни, а через некоторое время создали интерфейс для редактирования товаров. Когда это произошло, у старших менеджеров появилась первая существенная радость, так изменение меню стало удобным, а главное, быстрым. Раньше требовалось после изменения цены или добавления позиции сообщить об этом персоналу всех кофеен, дождаться, пока все сотрудники запомнят изменение, после чего проконтролировать. Теперь же стало достаточным изменить цену в одном месте в человеческом интерфейсе, после чего изменение применится везде сразу.

Это лишь один наглядный пример, как одна из возможностей подобных автоматизированных систем практически мгновенно меняет бизнес-процессы компании.

Немного технических деталей

Синхронизация работает через cron, обмен данными происходит ежеминутно. Соединение инициирует локальный сервер кофейни. Такой подход позволяет упростить процесс обмена, так как на сетевом уровне не требуется абсолютно никаких особенных настроек.

Реализованные типы обмена данных:

• Ресурсы (документы, товары, категории)
• Пользователи (гости, сотрудники, стандартные пользователи)
• Состояние лицевого счета гостя
• Дисконтные карты (включая карты сотрудников)
• Заказы
• Ингредиенты
• Подарки (несколько разных объектов)
• Задания резервного копирования
• Служебные задания

О правилах

Все объекты упаковываются и распаковываются правилами синхронизации, принцип которых подсмотрен у процессоров. С нынешними знаниями MODX, вероятнее всего, процессоры и были бы взяты за основу. Но в 2014 году такой идеи не появилось. Тем не менее, правила позволяют как осуществлять наследование (в парадигме ООП), так и автоматически загружать нужное. За счет этого основной сервис, отвечающий за синхронизацию, ничего не знает об объектах, которые он способен обрабатывать.

В поздних версиях синхронизатора добавилась возможность работать даже с такими объектами, правил для которых нет — благодаря докрученному базовому правилу стандартные объекты, которым достаточно для работы передачи только методов toArray() и fromArray(), обрабатываются только в рамках этого правила.

Об очереди синхронизации

За необходимостью передачи измененных объектов следит плагин, срабатывающий на соответствующие события. Когда нужное событие возникает, в очередь синхронизации попадает запись о новом (или измененном) объекте с указанием его класса и уникального ID.

Важно: уникальным ID не во всех случаях является стандартный ID системы, здесь все зависит от свойств каждого отдельного объекта. Таким образом решена проблема несоответствий системных ID на разных серверах.

Самый простой пример из системных объектов MODX — имя пользователя. Пользователи (в т.ч. наследующие их гости и сотрудники) передаются с указанием только username, ID перед передачей откидывается.

В некоторых других случаях в качестве уникального ключа используется комбинация из двух полей. К примеру, для дисконтных карт это поля «тип карты» и «номер карты».

О системных заданиях

Среди системных заданий реализованы 2 действия:

• Сброс кэша, иногда требуется после редактирования товаров;
• Установка пакетов

Установка пакетов производится автоматически по команде с центрального сервера. Очень сильно в данном случае помогает собственный репозиторий, на который предварительно заливается обновленная версия какого-либо компонента системы.

Когда была добавлена возможность обновления пакетов централизованно, для меня это оказался почти праздник — настолько сильно к тому моменту я устал подключаться к серверу каждой кофейни по отдельности и вручную заливать новые версии.