Глава 4. Продуктовая схема
Платформа «Era» имеет собственный процесс сборки Continuous Integration (далее CI). Результатом является дистрибутив. Это программный каталог, упакованный либо в docker-контейнер, либо в zip-архив, снабженный скриптом развертки.
Продукты, дистрибутивы и процесс сборки
Стек подразумевает создание на его базе программных продуктов с индивидуальным брендингом. Это решается с помощью кастомизации поведения платформы «Era» через файлы окружения (ассеты). Каждый такой продукт базируется на принципах платформы «Era», может иметь индивидуальные приложения и файлы окружения, о которых речь пойдет ниже.
Каждая версия продукта поставляется в форме дистрибутива, получаемом в результате сборки в процессе CI стека платформы «Era». В процессе CI платформы используются инструменты Jira, Jenkins, Docker, Salt и приложения для автоматизированного системного тестирования платформы «Era» и ее базовых приложений. Результаты сборки выкладываются в хранилище AWS, подключенное к Jira, ровно в ту задачу, которая инициировала процесс сборки.
Дистрибутив готового продукта содержит программный каталог, содержащий библиотеки всех входящих в состав приложений, включая саму платформу «Era», и файлы окружения (ассеты). Среди скриптов процесса CI присутствует сборочный скрипт по каждому собираемому продукту (это один из этапов CI). При необходимости этот скрипт может отличаться по своей структуре от скриптов сборки других продуктов, но его результат тем не менее тот же – совокупность файлов и ассетов в подготовленном к упаковке в контейнер программном каталоге. Дальнейшие этапы процесса CI рассчитывают на то, что собранный программный каталог содержит платформу «Era» и готов к системному тестированию.
Конкретная инсталляция всегда связана с конкретным продуктом – в рамках процесса сборки производится прошивка кода платформы, таким образом лицензия одного продукта не подходит для другого продукта вне зависимости от того, обладают они одинаковым набором решений или нет.
Существуют базовый продукт era, используются при разработке, тестировании и в процессе CI.
На уровне продукта формируются состав приложений и солюшенов, метаданные мастер-домена и его сущностей, базовая лицензия.
Solutions и предметные области
Солюшены (solutions) представляют собой обособленную логику решения проблем конкретной предметной области с конкретными ограничениями. В отличие от продукта, задачей которого является ограничение и брендирование, солюшен являет собой функциональное наполнение. Так, к солюшенам на момент написания статьи относятся era. Солюшены сопоставляются с доменами, то есть каждый домен имеет неизменную привязку к одному и только одному солюшену. Для этого у домена есть немодифицируемый атрибут solution. Каждый солюшен имеет собственный набор ассетов, кастомизирующих поведение связываемого с ним домена.
Продукт без солюшенов не несет функциональной полезности. Продукт поставляется по крайней мере с одним солюшеном. Один солюшен может поставляться как в рамках одного продукта, так и в рамках нескольких или всех продуктов – это решается путем параметризации процесса продуктовой сборки. Ограничение по использованию солюшенов в конкретной инсталляции продукта производится через лицензирование – ограничивается количество доменов, которые можно связать с тем или иным решением.
Существует базовый солюшен era, используемый при разработке, тестировании и в процессе CI.
На уровне управления солюшенами формируются метаданные доменов и их сущностей.
Приложения
Клиентские приложения
Платформа «Era» является серверным приложением. Любая система на ее базе предоставляет пользователям сервисы через свой обширный перечень функциональных API, а также стандартными протоколами.
Администратор или пользователь системы может пользоваться
-
браузером, чтобы через адресную строку выполнять HTTP-API;
-
специальными расширениями для браузеров, чтобы с их помощью выполнять HTTP-API;
-
созданными клиентскими приложениями с User-Interface, скрывающие внутри работу с API системы
-
толстыми: работающими под управлением операционных систем;
-
тонкими: работающими в браузере.
-
Система может быть интегрирована с другими различными клиент-серверными приложениями, например CRM. Таким образом серверы интегрированных приложений могут выступать клиентами системы на базе платформы «Era». Причем пользоваться как клиентскими API – выполняя запросы от имени каждого своего пользователя независимо, так и серверными API.
Что касается толстых клиентских приложений – их наличие, поставка, установка и использование обособлены от продуктов стека платформы «Era». Они суть отдельные продукты и рассматриваются отдельно.
Тонкие приложения реализуются иначе. Тонкое приложение загружается и отображается браузером при обращении к серверу. В ходе своей работы приложение запрашивает различные ресурсы с сервера, в том числе выполняет запросы к API-сервера.
В этой части рассматривается вопрос тонких приложений и их стыковки с платформой «Era».
Кейс: В адресной строке браузера пользователь заполняет адрес известного ему сервера системы с ролью WS, после чего загружается клиентское приложение, где он авторизуется и проводит работу в UI, не задумываясь об API.
Роль WS помимо обращений к API предоставляет доступ к статическим файлам, расположенным в отведенном для этого каталоге www (вложенном в программный каталог «Era» на каждом сервере). Таким образом, если там, внутри каталога www, располагаются программные файлы и ресурсы отдельно созданных веб-приложений, то WS будет без авторизации предоставлять доступ к ним, фактически являясь в этой части классическим веб-сервером.
Остается только создать по приложению под каждую функциональную задачу, реализующему принципы работы с API платформы «Era». И, возможно, объединить их в одно единое приложение. После чего обеспечить их размещение на всех серверах развернутой системы в каталоге статической выдачи www.
Любое веб-приложение для взаимодействия с платформой использует её API. Также может решать дополнительные задачи за рамками коммуникационной платформы.
Системные приложения
Для продуктов стека платформы «Era» создан и включен в поставку ряд веб-приложений, решающих стандартные задачи, опирающиеся на архитектуру платформы «Era»:
-
Управление конфигурациями
-
Управление сущностями доменов
-
Управление Autoprovision для SIP-телефонов
-
Мониторинг состояний
-
Редактор сценариев
-
Редактор оперативных отчетов
-
Редактор хронологических отчетов
Перечисленные приложения доступны из главного окна, которое также является веб-приложением и решает вопрос общей авторизации и отображения списка доступных авторизованному пользователю веб-приложений.
Эти и другие, включаемые в состав дистрибутива, веб-приложения называются системными веб-приложениями. Системные веб-приложения при сборке в процессе CI могут компилироваться, либо браться из хранилища уже готовых и скомпилированных решений и компоноваться наравне с другими ассетами. Все они взаимодействуют с системой через стандартный системный API (HTTP и/или WebSocket).
Веб-приложения в рамках continuous integration могут компилироваться, либо браться из хранилища уже готовых и скомпилированных решений и компоноваться наравне с другими ассетами.
Ролевые веб-приложения
Также платформа предоставляет возможность добавлять веб-приложения в домены во время эксплуатации системы путем создания сущностей домена типа roleapp. Такие веб-приложения называются ролевыми веб-приложениями.
Ролевые веб-приложения призваны расширять функциональность системы и увеличивать понятность и удобство для конкретных пользователей, выполняющих связанные с функциональностью операции.
Ролевое веб-приложение может быть реализовано на любом стеке технологий, работающих в веб-браузере, например js + react + redux. Результат сборки компонуется в zip-архив и снабжается конфигурационным файлом.
Для добавления ролевого веб-приложения администратору домена достаточно иметь доступ лишь к одному своему домену (роль позволяющая выполнять запросы на управление сущностями домена), и не иметь доступа ни к инфраструктуре, ни к мастер-домену.
При добавлении ролевых веб-приложений администратор домена указывает роли (пользовательские роли), которым приложение доступно, а также назначает при необходимости роли пользователям. Пользовательская роль - это атрибут, а не сущность. Она представляет собой произвольную строку - название роли. Вычисление ролевых веб-приложений, которые доступны авторизующемуся пользователю, производится методом пересечения списков ролей, назначенных пользователю и каждому из ролевых веб-приложений домена - пустое пересечение блокирует доступ. Таким образом, все доступные пользователю ролевые веб-приложения появляются в корневом веб-приложении после авторизации наряду с системными веб-приложениями.
При работе ролевое веб-приложение может использовать любые API сервера, доступные по ролевой политике.
При загрузке ролевого веб-приложения может быть указан служебный сценарий, реализующий проектное API. Всякое обращение к проектному HTTP-API ролевого веб-приложения инициирует запуск служебного сценария с передачей ему параметров HTTP запроса. Сценарий может содержать произвольную логику, может быть единым для нескольких ролевых веб-приложений.
Технология создания ролевых веб-приложений подразумевает разделение труда в целях оптимизации. Так, интегратор выявляет потребности конкретного заказчика или группы заказчиков, на основании их бизнес-процессов и ролей формирует ТЗ на ролевые веб-приложения и отдает на аутсорсинг любой доступной группе веб-разработки. Разработка может использовать произвольные технологии (для соблюдения стилистики рекомендуется к применению material design guidelines и библиотека компонентов material.io). В ходе приемки выявляется перечень используемых API, и для обеспечения защищенности данных строго ограничиваются файлом конфигурации ролевого веб-приложения. Интегратор, в ответственность которого входит также защищенность данных, самостоятельно формирует архив ролевого веб-приложения, заполняя файл конфигурации строго ограниченным набором URL HTTP-API, таким образом не выпуская контроля из своих рук.
Другие приложения
В состав продукта могут быть включены другие приложения, например
-
консольные приложения-сервисы для решения задач по запросам из сценариев, например адаптер к корпоративной системе;
-
приложения-сниппеты для выдачи их администраторам с целью включения их кода на сайт компании, например веб-чат;
-
толстые клиентские приложения, упакованные в архивы и готовые к скачиванию с веб-серверов системы, например редактор шаблонов отчетов;
-
внедренные глубоко в логику серверные модули клиентских приложений, например генератор отчетов;
-
различные версии виртуальных машин, в частности используемые самой платформой BEAM и JVM;
-
используемые самой платформой «Era» нативные приложения, например RTX и Mixer
-
стратегии поведения логики платформы, реализованные вовне.
Ассеты
Ассеты – это файлы окружения программных библиотек – платформы «Era» и других приложений. Они призваны кастомизировать поведение системы под нужды поставляемого продукта на различных участках, заранее подготовленных к такой кастомизации.
Все ассеты находятся в программном каталоге платформы (runtime). В программный каталог они попадают на этапе сборки дистрибутива версии продукта в качестве
-
глобальных ассетов,
-
собственных ассетов платформы «Era» (в том числе внешние),
-
ассетов входящих в состав приложений (в том числе внешние),
-
продуктовых ассетов, в том числе ассетов входящих в продукт солюшенов.
При этом возможно замещение в рамках процесса сборки одних ассетов другими, а также их замена на уже развернутой системе. Порядок включения ассетов при сборке отражен на схеме. Особенности:
-
Ассеты приложений платформы «Era» и RTX – частный случай ассетов приложения.
-
Любое приложение может содержать ассеты внутри репозитория с кодом и во внешнем репозитории (объемное содержимое, либо часто изменяемое бинарное содержимое).
-
Ассеты продукта и ассеты солюшенов собираются на одном шаге – последнем.
Метаданные, которые являются частью ассетов, можно разделить на следующие группы:
-
Внешние – сторонняя система запрашивает метаданные по определенному url и получает их без модификации. Платформа по указанному пути находит их на диске и возвращает содержимое "как есть". Например: метаданные веб-приложений (rest_metadata).
-
Фиксированные – сторонняя система запрашивает метаданные по определенному url и получает их без модификации. В платформе прошит путь до запрашиваемого файла, содержимое которого возвращается "как есть" (api/admin/v1/metadata/read).
-
Дополнительные – платформа знает путь до файла, может считывать его и использовать содержимое для расширения предоставляемого функционала. Например: url_routes.json.
-
Системные – платформа знает о расположении файлов, использует их для обеспечения динамики во время работы. Без метаданных функционал недоступен. Например: events.
-
Прошитые – содержатся в коде платформы.
Глобальные ассеты
К глобальным ассетам относятся
-
версия платформы BEAM (erlang),
-
версия платформы JVM (java),
Ассеты платформы
К ассетам платформы относятся
-
иконки компонентов сценариев,
-
скрипты базовых сценариев по умолчанию, таких как queue, parking, voicemail,
-
файлы звукового сопровождения (мелодии ожидания, озвучка селекторов, озвучка числительных),
-
файлы обновления баз данных,
-
серверные приложения, используемые функциональными ролями,
-
системные веб-приложения, собранные обособленно от процесса CI,
Ассеты платформы состоят из глобальных ассетов и ассетов приложений R и RTX.
Ассеты приложений
При сборке продукта определяется состав приложений, каждое из которых может иметь свой набор ассетов. Ответственность за его размещение в итоговый каталог возложена на процесс сборки приложения, включаемый по интерфейсу build.groovy в процесс сборки продукта. Те приложения, которые собраны заранее и включаются в виде готовых библиотек, с точки зрения процесса сборки являются ассетами продукта.
Частным особым случаем приложений являются приложения R и RTX, их ассеты рассмотрены выше в разделе Ассеты платформы.
Ассеты продуктов
permissions. Разрешения на использование различных ресурсов.
/era/era_env/priv/permissions.json
Файл позволяет ограничивать использование различных ресурсов. При отсутствии файла или ключа для некоего приложения, это приложение ведет себя в соответствии со своим дефолтным поведением. Ключи и значения нигде не публикуются и, соответственно, формирование такого файла возможно только в контакте с разработчиками.
objects. Метаданные объектов мастер-домена
Мастер-домен не имеет привязки к солюшенам, поэтому для него существует обособленный состав метаданных, управляемый на уровне продукта, но по смыслу и назначению аналогичный метаданным объектов с уровня ассетов солюшена (см. ниже).
cfg. Метаданные конфигурации
Метаданные конфигурации для работы клиентского веб-приложения "Редактор конфигураций".
defaultlic. Базовая лицензия
/era/era_env/priv/metadata/defaultlic.json
Формирует параметры лицензий, объединяемые с дополняемой лицензией. Используется для того, чтобы добавлять или снимать ограничения по конкретным показателям. Так, например, какой-то продукт может не включать лицензирование количества доменов в то время, как другому это необходимо. В этом случае в продукте, не использующем лицензирования доменов, должен появиться этот файл метаданных, где показатель ограничения количества доменов установлен в безлимитное значение 123456789 и подписано приватным ключом асимметричного алгоритма цифровой подписи.
url_routes. Маршрутизация веб-запросов
/era/era_env/priv/metadata/url_routes.json
Веб-сервер платформы «Era» имеет базовые API, обеспечиваемые диспетчером маршрутов и URL веб-страниц. В рамках продукта могут добавляться особые ассеты - веб-приложения. Веб-приложения как правило состоят не из одного файла, а из целой структуры каталогов. В следствие этого они требуют инвидидуальной маршрутизации на конкретные страницы внутри своей структуры. Решению этой задачи служит ассет url_routes, участвующий в конфигурации диспетчера URL адресов API.
lang_*. Языковые файлы
/era/era_env/priv/metadata/lang_ru.json, /era/era_env/priv/metadata/lang_en.json, ...
Ряд сервисов платформы выдает через API данные вместе с человеческими названиями и описаниями. Так, например, для функционирования редактора сценариев предоставляются метаданные, в которых компоненты имеют имена, свойства, значения выпадающих списков, описания функций и т.д. Все эти тексты могут быть модифицируемы и представлены на разных языках. Список всех текстов конкретного языка находится в соответствующем файле lang_ru, lang_eng и т.д. Файл состоит из разделов по ролям и компонентам.
www. Статическая выдача веб-сервера
/era/era_ws/priv/www/[WebApp]/*
Дополнительные приложения и статические файлы, доступные для скачивания через HTTP(s) интерфейс веб-сервера платформы «Era».
Прочие ассеты продуктов
Продукты при сборке могут модифицировать ассеты платформы и добавлять свои.
-
/era/era_cdr/priv/dbscripts/[Any].sql -
/era/era_script/priv/default_scripts/[ScriptType].json -
/era/era_script/priv/icons/[ComponentTypeId].json -
/era/era_sip/priv/sync/common– звуковые файлы по категориям, при запуске сип-ролей перемещаются в каталог?SYNC:, откуда растекаются по всем серверам и доступны ролям SIP и приложению RTX-MG для решения совместной задачи воспроизведения файлов в стримы. Внутри есть каталоги со звуковыми файлами/conf,/parking,/standard_expressions,/waitonhold. Внутри/standard_expressionsкаталоги с разными наборами озвучки числительных. -
/era/era_sip/priv/ssl/*– файлы сертификатов, упоминаемые в конфигурационном файле в опциях ролей SG и ESG. По умолчанию server.crt, server.key. -
/era/era_ws/priv/ssl/*– файлы сертификатов, упоминаемые в конфигурационном файле в опциях роли WEBSERVER. По умолчанию server.crt, server.key. -
/era/era_ws/priv/www/[WebApp]/*– дополнительные приложения и статические файлы, доступные для скачивания через HTTP интерфейс веб-сервера платформы «Era».
Ассеты солюшенов
objects. Метаданные объектов
/era/era_env/priv/metadata/[SOLUTION]/objects.json, /era/era_env/priv/metadata/[SOLUTION]/objects/[EntityType].json
Различные решения (а также продукты в контексте мастер-домена) могут иметь различные ограничения, соответственно ряд сущностей доменного центра может быть недоступен. Набор доступных сущностей, их последовательность, названия и описания типов представлены в файле метаданных решения (связаны с доменом).
Отдельно рядом находится каталог с метаданными атрибутов каждого открытого для использования в решении типа сущностей. Для сущности определяются доступные для редактирования атрибуты, их последовательность, названия и описания, границы допустимых значений, значение по умолчанию. Так, некоторые атрибуты могут быть скрыты, но снабжены конкретным значением по умолчанию.
scripts. Метаданные сценариев
/era/era_env/priv/metadata/[SOLUTION]/scripts.json
Компоненты сценариев и функции выражений сценариев реализуются внутри платформы. В дальнейшем по необходимости планируется реализовать подключение внешних модулей с программным кодом компонентов и функций выражений. В данный момент продукты и решения могут вводить ограничения на типы доступных в связанном домене сценариев (например будут только SVC, но не будет IVR). А также скрывать определенные типы компонентов. Так, например, компонент веб-запрос для разных нужд реализуется в двух видах - с прямым доступом к модификации полного URL и через использование URL лицензируемых сущностей webservice. То или иное решение может выбирать с каким компонентом иметь дело. Дополнительно метаданные решения могут скрывать определенные свойства, снабжая их значениями по умолчанию.
defaultscripts. Сценарии по умолчанию и метаданные
/era/era_env/priv/metadata/[SOLUTION]/defaultscripts.json, /era/era_dc/priv/default_scripts/[ScriptType]/[ScriptCode].scr
Во первых, в каталоге priv приложения доменного центра (era_dc) есть каталог defaultscripts, где размещаются файлы сценариев (содержимое), доступные для всех доменов через последовательный доступ к родительскому домену при поиске сценариев по коду. Но чтобы их использовать, необходимо установить в файле метаданных сценариев по умолчанию (а это уже в
roles. Метаданные ролей
/era/era_env/priv/metadata/[SOLUTION]/roles.json
Список обязательных ролей на каждом сайте для корректной работы солюшена.
webservices. Метаданные веб-сервисов
/era/era_env/priv/sys_metadata/solutions/[SOLUTION]/webservices.json
Категории веб-сервисов и связанные с ними служебные сценарии-обработчики сообщений при получении и отправке.
webapps. Метаданные веб-приложений
/era/era_env/priv/metadata/[SOLUTION]/webapps.json
Список веб-приложений солюшена и требуемых для них правил доступа.
events. Метаданные событий
/era/era_env/priv/metadata/[SOLUTION]/events/events.json, /era/era_env/priv/metadata/[SOLUTION]/events/[EventClass]/[EventType].json
Различные решения (а также продукты в контексте мастер-домена) могут иметь различные ограничения, соответственно ряд событий с системе может быть отключен. Набор доступных событий, названия и описания типов представлены в файле метаданных решения (связаны с доменом).
События могут отключатся удалением из списка доступных.
Прочие ассеты солюшенов
-
Преднастроенные сущности доменов;
-
Метаданные связей сущностей домена (/era/era_env/priv/metadata/[SOLUTION]/links/[OBJ_TYPE].json);
-
Следующая глава: Методики управления атрибутами качества
-
Предыдущая глава: глава: Кейсы для глубокого погружения в архитектуру