В статье //infostart.ru/public/192074/ описывается подход к разработке модульного приложения. Эта статья продолжает тему модульности и посвящена модели распространения модулей до конечных заказчиков.
В глобальном смысле возможны две схемы работы клиента: в режиме сервиса (Saas) и локально (On-site); режим работы в сервисе делится ещё на два вида: в общем сервисе (единая разделённая база) и выделенная база на сервере для клиента. Причём разные модули у одного клиента могут располагаться в разных местах: Модуль1 – в общем сервисе, Модуль2 – в отдельной выделенной базе на сервисе, Модуль3 – локально на севере предприятия. Все эти модули могут взаимодействовать друг с другом и иметь общие сквозные данные и процессы. Механика такого взаимодействия — это отдельная тема и в данной статье обсуждаться не будет.
За учёт характеристик клиента, набора купленных им модулей и используемых баз отвечает управляющая система.
Разработка модулей может вестись разными командами разработки независимо, но, в конечном итоге, все модули попадают в одно общее хранилище конфигурации. Типовые поставки клиентам делаются на основе конфигурации последнего стабильного релиза, из специальной базы (база для поставок). Если сопровождение изменённой конфигурации клиента ведётся компанией владельцем сервиса, то существует также хранилище изменённой конфигурации под конкретного клиента, и поставка делается на основе него. Здесь будет уместно сказать, что мы понимаем под изменёнными конфигурациями – нами рассматривается вариант, что вся доп. функциональность, разрабатываемая под клиента, включается в типовую конфигурацию как модули, доступные только для этого клиента, т.е. при наличии такого доп. модуля, с точки зрения системы, конфигурация остаётся типовой; изменённая конфигурация в такой постановке может быть только в следующих случаях: модуль внедрён в другую систему, заказчиком вносятся изменения в конфигурацию самостоятельно или функционал типовых модулей изменяется таким образом, что его нельзя оформить как доп. модуль.
Пара слов о версиях конфигурации и модулей:
Типовая конфигурация имеет единую версию, версии модулей хранятся отдельно. Если конфигурация встроена в другую систему, то её версия состоит из нескольких частей – наша версия и версия системы. Если модуль изменяется под клиента, и функциональность этого изменения по каким-то причинам не может быть выделена в отдельный модуль, то версия модуля также состоит из 2х частей – типовая версия и версия поставки клиенту.
Обновление версий модулей осуществляется перед поставкой нового типового релиза конфигурации.
Проследим действия человека и управляющей системы при покупке новых модулей:
|
ЧЕЛОВЕК |
СИСТЕМА |
1 |
Заходит в магазин приложений, вводит логин, пароль и идентификатор базы, для которой он собирается совершить покупку.
|
Происходит аутенфикация пользователя в системе. |
2 |
Выбирает нужные модули, кладёт их в «корзину» |
Проверяются связи модулей – если для работы выбранного модуля необходим модуль, ранее не приобретённый клиентом или не добавленный в корзину, то его покупка не доступна. Также осуществляются проверки совместимости модулей с текущей версией конфигурации у клиента. |
3 |
Нажимает кнопку «Оформить заказ» |
Создаётся документ «Заявка». При проведении документа ещё раз проверяется корректность всех данных, в т.ч. набора выбранных модулей. |
4 |
Выбирает способ оплаты, заполняет поля оплаты, нажимает «Оплатить» |
Осуществляется биллинг платежа, создаётся документ «Оплата», при проведении которого записывается информация о новых купленных модулях клиента. При необходимости выписываются документы для отчётности. |
5 |
Если целевая база клиента в сервисе – то администратору автоматически становятся доступны роли и настройки новых модулей; если локально – в личном кабинете пользователя магазина появляется ссылка на скачивание комплекта поставки |
Запускается механизм поставки модулей.
|
Теперь подробно рассмотрим пятый пункт с точки зрения работы системы.
Конечная цель механизма – сделать процесс доставки нового модуля до клиента удобным и быстрым. Для этого в процессе поставки необходимо максимально исключить ручной труд технического специалиста.
Для определения процесса поставки по конкретному заказу нужно ответить на следующие вопросы:
- Целевая база находится в сервисе или локально?
- Конфигурация целевой базы содержит изменения по сравнению с типовой поставкой?
Она сопровождается нами, или клиент вносит туда изменения самостоятельно? Нам доступна изменённая конфигурация целевой базы? - Конфигурация целевой базы имеет последнюю версию типовой поставки?
- Какие модули необходимо поставить клиенту?
Вся информация по этим вопросам хранится в управляющей системе в разрезе клиента и базы. В зависимости от ответов на них, механизм поставки можно полностью или частично автоматизировать.
В процессе поставки новых модулей клиенту можно выделить следующие операции:
- создание файлов комплекта поставки, содержащего нужный набор модулей;
- тестирование поставки;
- обновление поставкой целевой базы;
- запуск необходимых обработчиков для инициализации новых модулей и обновления существующих.
Сам механизм поставки в управляющей базе должен быть оформлен как настраиваемый бизнес процесс, максимально разбитый на элементарные операции. Это нужно для того, чтобы варьировать процесс поставки в зависимости от разных входных условий.
Обсудим технические моменты реализации некоторых операций поставки:
1. создание файлов комплекта поставки, содержащего нужный набор модулей
Процесс создания файлов поставки легко автоматизируется с помощью параметров командной строки в режиме запуска конфигуратора.
С помощью новой возможности платформы, добавленной в 8.3, конфигурация выгружается в файлы (/DumpConfigToFiles), те программные модули, которые не должны поставляться, очищаются, и далее конфигурация загружается в специальную базу (/LoadConfigFromFiles), из которой делается целевая поставка (/CreateDistributionFiles).
В глаза бросается, что при данном подходе мы не «вырезаем» непоставляемые объекты метаданных, а только очищаем их программные модули. Решение не выделять в поставке наборы необходимых метаданных обосновано тем что: 1) разработка такого механизма трудозатратна, а плюсы, кроме уменьшения общего количества таблиц в целевой базе, не очевидны; 2) возможен сбой всего процесса поставки, если по какой-то причине (например, по ошибке разработчика модуля, не указавшего все внешние связи) в поставляемом модуле оказались ссылки на непоставляемые объекты.
Ещё один момент, который вытекает из этого решения – файлы поставок должны делаться на машине по управлением ОС Windows (может быть здесь я не прав и пакетный режим запуска работает на Linux клиенте, если это так прошу сказать об этом в комментариях)
2. тестирование поставки
Исходя из алгоритмов в п.1, обязательно тестирование на синтаксический контроль конфигурации. Другие виды тестирования (например, запуск сценарного тестирование под конкретный набор модулей) является опциональным, т.к. всеобъемлющее тестирование – это задача этапа создания типовой поставки нового релиза конфигурации (которая делается не автоматически, а под пристальным контролем специалистов), а не поставки набора модулей под конкретный заказ (при которой важным критерием становится время затраченное клиентом от факта оплаты до доставки купленных модулей)
3. обновление поставкой целевой базы
Данный пункт актуален только для баз расположенных локально (on-site) или выделенных в отдельную базу на сервисе. В первом случае обновление происходит специалистом заказчика с помощью файла поставки самостоятельно; во втором случае обновление возможно автоматически (если конфигурация типовая), или специалистами сервиса (если конфигурация изменённая) – клиент выбирает только желаемое время обновления базы.
4. запуск необходимых обработчиков для инициализации новых модулей и обновления существующих.
Для варианта «Saas» запускается специальный служебный сеанс, в котором осуществляются все необходимые обработки обновления; для варианта «on-site» - обработчики запускаются при первом входе пользователя в систему.
Выводы
Таким образом, мы полагаем, что процесс доставки отдельных модулей до конечного клиента в большинстве случаев можно полностью автоматизировать. Это позволит сделать систему удобной и сократить издержки на её сопровождение.