Синхронный MODX

Сентябрь 7, 2022

Главная
Алгебра
Синхронный MODX

Содержание

2. С чего все началось? Как автоматизировать?
3. Базовые требования к системе Централизация всех обрабатываемых данных Возможность автономной работы заведения при локальном отсутствии интернета
4. Почему ? Основная причина мое хорошее знание этого фреймворка и очень сжатые сроки до запуска первой
5. Дополнительные аргументы в пользу MODX Модульность Механизм обновления компонентов через транспортные пакеты, возможность создать собственный репозиторий
6. «Железная» структура Физический локальный сервер (ЛС) Центральный сервер (ЦС)
7. Синхронизатор: важное требование Динамическая поддержка любых объектов
8. Синхронизатор: первый шаг. Товары и категории err err err msProduct msCategory Всего два типа объектов Минимальная
9. Синхронизатор: развитие. Улучшенная обработка ошибок + заказы msProduct msCategory TV Template TV Template modUser Groups msOrder
10. Показатели на данный момент 400 товаров 3500 пользователей 500 000 заказов 1 000 000 товаров в
11. Принцип работы синхронизатора Действие Действие Действие Плагин Журнал синхронизации +1 запись Отслеживание изменений
12. Обмен данными между серверами 1’ ЛС упаковать изменения Отправка ЦС распаковка + упаковка Отправка ЛС распаковка
13. Правила синхронизации Специальные классы, название которых состоит из специального префикса и названия оригинального класса объекта class
14. Главные методы Упаковать sync::pack() получает из БД запись журнала об измененном объекте запускает pack() из соответствующего
15. class chsrmodUser extends chsrRule { public function pack($journalEntry) { // function code here } public function
16. Уникальные ключи ID ID uID uID
17. Уникализация msOrder msOrder stock_id id local_id msOrder local_id stock_id gOrder
18. Обработка ошибок Прогнозируемые Непредвиденные Заранее определяется критичность ошибки. Важно? Нет: запись пропускается, в журнале сохраняется статус
19. Обслуживание серверов Выполнение сервисных команд
20. Обновление компонентов системы Используется штатный механизм обновления пакетов, обновления происходят в автоматическом режиме после получения команды
21. Перспективы развития Устранение старого кода в правилах, переход на максимальное использование принципов ООП и процессоров MODX
23. Скачать презентацию

Слайд 2

С чего все началось?
Как автоматизировать?

Слайд 3

Базовые требования к системе
Централизация всех обрабатываемых данных
Возможность автономной работы заведения при

локальном отсутствии интернета
Обмен данными в реальном времени

Слайд 4

Почему ?
Основная причина
мое хорошее знание этого фреймворка и очень

сжатые сроки до запуска первой версии
проекта

Слайд 5

Дополнительные аргументы в пользу MODX
Модульность
Механизм обновления компонентов через транспортные пакеты, возможность

создать собственный репозиторий
Наличие админки

Слайд 6

«Железная» структура
Физический
локальный сервер (ЛС)
Центральный
сервер (ЦС)

Слайд 7

Синхронизатор: важное требование
Динамическая поддержка
любых объектов

Слайд 8

Синхронизатор: первый шаг. Товары и категории
err
err
err
msProduct
msCategory
Всего два типа объектов
Минимальная обработка ошибок
Недостаточная

стабильность

Слайд 9

Синхронизатор: развитие.
Улучшенная обработка ошибок + заказы
msProduct
msCategory
TV
Template
TV
Template
modUser
Groups
msOrder
msOrderProduct
msOrderAddress
Корректная обработка всех известных ошибок
Обработка

сопутствующих объектов
Значительно расширенный список обрабатываемых объектов

Слайд 10

Показатели на данный момент
400 товаров
3500 пользователей
500 000 заказов
1 000 000 товаров

в заказах

1 центральный
14 локальных

База данных

Серверы

+ 20 типов обрабатываемых объектов, без учета сопутствующих

Слайд 11

Принцип работы синхронизатора
Действие
Действие
Действие
Плагин
Журнал
синхронизации
+1
запись
Отслеживание изменений

Слайд 12

Обмен данными между серверами
1’
ЛС
упаковать
изменения
Отправка
ЦС
распаковка
+
упаковка
Отправка
ЛС
распаковка

Слайд 13

Правила синхронизации
Специальные классы,
название которых
состоит
из специального префикса
и названия оригинального
класса

объекта

class chsrmodUser extends chsrRule {
// class code here
}
class chsrGuest extends chsrmodUser {
// class code here
}

class chsrmodResource extends chsrRule {
// class code here
}
class chsrmsProduct extends chsrmodResource {
// class code here
}

Слайд 14

Главные методы
Упаковать
sync::pack()
получает из БД запись журнала об измененном объекте
запускает

pack() из соответствующего Правила

Распаковать
sync::unpack()

получает весь массив данных для распаковки
для каждого элемента запускает unpack() соответствующего Правила

Слайд 15

class chsrmodUser extends chsrRule {
public function pack($journalEntry) {
// function

code here
}
public function unpack($package = array()) {
// function code here
}
}

class chSync {
public function pack($stock_id = 0, $piece = '') {
// function code here
}
public function unpack($package = array()) {
// function code here
}
}

Слайд 16

Уникальные ключи
ID
ID
uID
uID

Слайд 17

Уникализация msOrder
msOrder
stock_id
id
local_id
msOrder
local_id
stock_id
gOrder

Слайд 18

Обработка ошибок
Прогнозируемые
Непредвиденные
Заранее определяется критичность ошибки. Важно?
Нет: запись пропускается, в журнале сохраняется

статус ошибки.
Да: Если обработать и исправить ошибку важно в ручном режиме, должно отправляться уведомление разработчику.

Здесь все зависит от конкретной ситуации и времени обнаружения ошибки. В большинстве случаев все ограничиваетя остановкой синхронизации на некоторое время.

Слайд 19

Обслуживание серверов
Выполнение сервисных команд

Слайд 20

Обновление компонентов системы
Используется штатный
механизм
обновления пакетов,
обновления происходят
в автоматическом режиме
после получения

команды
с ЦС

Слайд 21

Перспективы развития
Устранение старого кода в правилах, переход на максимальное использование принципов

ООП и процессоров MODX

Администрирование серверов:
Выполнение сервисных команд/задач
Выполнение небольших кусков кода
Мониторинг состояния

Синхронный MODX

Содержание

С чего все началось?Как автоматизировать?

Базовые требования к системеЦентрализация всех обрабатываемых данныхВозможность автономной работы заведения при

Почему ?Основная причина мое хорошее знание этого фреймворка и очень

Дополнительные аргументы в пользу MODX МодульностьМеханизм обновления компонентов через транспортные пакеты, возможность

«Железная» структура Физический локальный сервер (ЛС)Центральный сервер (ЦС)

Синхронизатор: важное требование Динамическая поддержка любых объектов

Синхронизатор: первый шаг. Товары и категорииerrerrerrmsProductmsCategoryВсего два типа объектовМинимальная обработка ошибокНедостаточная

Синхронизатор: развитие. Улучшенная обработка ошибок + заказыmsProductmsCategoryTVTemplateTVTemplatemodUserGroupsmsOrdermsOrderProductmsOrderAddressКорректная обработка всех известных ошибокОбработка

Показатели на данный момент400 товаров3500 пользователей500 000 заказов1 000 000 товаров

Принцип работы синхронизатораДействиеДействиеДействиеПлагинЖурнал синхронизации+1 записьОтслеживание изменений

Обмен данными между серверами1’ЛСупаковать измененияОтправкаЦСраспаковка+упаковкаОтправкаЛСраспаковка

Правила синхронизацииСпециальные классы,название которых состоит из специального префикса и названия оригинальногокласса

Главные методыУпаковатьsync::pack() получает из БД запись журнала об измененном объекте запускает

class chsrmodUser extends chsrRule { public function pack($journalEntry) { // function

Уникальные ключиIDIDuIDuID

Уникализация msOrdermsOrderstock_ididlocal_idmsOrderlocal_idstock_idgOrder

Обработка ошибокПрогнозируемыеНепредвиденныеЗаранее определяется критичность ошибки. Важно?Нет: запись пропускается, в журнале сохраняется

Обслуживание серверов Выполнение сервисных команд

Обновление компонентов системыИспользуется штатныймеханизмобновления пакетов,обновления происходят в автоматическом режиме после получения

Перспективы развитияУстранение старого кода в правилах, переход на максимальное использование принципов

Похожие презентации