Архитектурные элементы конфигурации

Общие сведения

Пакеты

Пакет в Creatio — это совокупность конфигурационных элементов (схем, данных, скриптов, дополнительных библиотек), которые реализуют определенный блок функциональности.

Механизм пакетов Creatio основан на принципе открытости/закрытости ООП, cогласно которому все сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для изменения. Это означает, что новая функциональность должна реализовываться путем добавления новых сущностей, а не путем изменения старых.

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

Пакеты Creatio условно можно разделить на два вида:

• Предустановленные пакеты. Поставляются вместе с системой и устанавливаются в рабочее пространство по умолчанию. К таким относятся пакеты с базовой функциональностью (например, Base, NUI), пакеты, расширяющие функциональность системы (например, пакеты интеграции с 1С, телефонией и т.д.), а также пакеты, созданные сторонними разработчиками. Такие пакеты поставляются вместе с приложением или устанавливаются из zip-архивов как приложения marketplace.
• Пользовательские пакеты — пакеты, создаваемые пользователями системы. Они могут быть привязаны к хранилищу SVN.

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

Механизм замещения в пакетах

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

Иерархия пакетов

Для того чтобы в одном пакете использовать функциональность из другого пакета, необходимо указать зависимость от этого пакета.

В зависимом пакете дополняется или изменяется функциональность того пакета, от которого он зависит. Таким образом, строится иерархия зависимости пакетов, в которой пакеты более низкого уровня могут дополнять или изменять функциональность любого пакета выше по иерархии (рис. 1).

Рис. 1. — Зависимости пакетов

Полный список всех установленных в рабочее пространство пакетов отображается на вкладке [Пакеты] раздела [Конфигурация].

Пакеты в рабочее пространство могут быть установлены как из файлового zip-архива (как правило, это предустановленные базовые пакеты), так и из хранилища системы контроля версий. Также на вкладке отображаются пакеты, которые были созданы пользователем в рабочем пространстве.

Состав пакетов:

1. Схемы — конфигурационные единицы системы, которые определяют либо новые, либо существующие конфигурационные элементы.
2. Внешние сборки — сторонние библиотеки, которые необходимы для разработки и интеграции с внешними системами. После установки могут использоваться в схемах исходных кодов.
3. SQL-скрипты — произвольные SQL-скрипты, которые выполняются в БД при установке пакета. SQL-скрипты могут понадобиться для переноса пакета в другие конфигурации, если с ним связаны изменения в базе данных.
4. Данные — записи разделов, значения справочников и системных настроек, которые разработаны в пакете. Могут понадобиться для переноса пакета в другие конфигурации, если с ним связаны определенные записи и значения из базы данных.

Подробнее о работе с пакетами можно узнать из статьи "Работа с пакетами".

Схема

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

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

Типы схем:

Схема	Класс	Назначение
Схема объекта	EntitySchema	С помощью схем этого типа можно управлять структурой базы данных, не обращаясь к ней напрямую.
Схема клиентского модуля	ClientUnitSchema	С помощью схем этого типа реализуется клиентская часть приложения.
Схема исходного кода	SourceCodeSchema	С помощью схем этого типа реализуется дополнительная серверная логика приложения.
Схема бизнес-процесса	ProcessSchema	С помощью схем этого типа генерируются пользовательские бизнес-процессы.
Схема страницы	PageSchema	С помощью схем этого типа реализуются серверные ASP.NET страницы.
Схема действия бизнес-процесса	ProcessUserTaskSchema	С помощью схем этого типа генерируются пользовательские действия бизнес-процессов.
Схема отчета	ReportSchema	С помощью схем этого типа генерируются отчеты.
Схема списка изображений	ImageListSchema	С помощью схем этого типа можно управлять списками изображений.

Схемы хранятся в базе данных в виде мета-данных и исходных кодов (для схем с исходным кодом). Для редактирования схем используются различные дизайнеры раздела [Конфигурация] — дизайнер объектов, дизайнер процессов, дизайнер модулей, дизайнер исходных кодов и т.д.

Любая схема любого типа как наследник базового класса Schema имеет обязательные свойства и методы.

Обязательные свойства схем:

1. UId — уникальный идентификатор. При создании любого элемента конфигурации создается его схема, которой, в свою очередь, присваивается уникальный идентификатор.
2. Name — название схемы. Используется для идентификации схемы в программном коде.
3. Caption — заголовок схемы. Используется для идентификации схемы в интерфейсе системы.

Основные методы схем:

1. ReadMetaData — метод, который осуществляет чтение метаданных схемы из базы данных.
2. WriteMetaData — метод, который осуществляет запись метаданных схемы в базу данных.
3. GetLocalizableValues — метод, который возвращает коллекцию локализуемых ресурсов схемы. Эти ресурсы используются для хранения и отображения заголовков, названий и т.д.

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

Свойства и методы различных классов схем и менеджеров схем описаны в библиотеке классов.

Объект

Модель данных Creatio основана на объектах. Объект — это бизнес-сущность, которая позволяет объявить на уровне серверного ядра новый класс ORM-модели. На уровне базы создание объекта означает создание новой таблицы с таким же именем, как у созданного объекта, и с таким же составом колонок. То есть, в большинстве случаев каждый объект в системе является системным представлением одной физической таблицы в базе данных.

Объекты бывают базовыми и пользовательскими.

• Базовые объекты недоступны для редактирования и располагаются в предустановленных пакетах. Они могут быть замещены в пользовательских пакетах.
• Пользовательские объекты — это объекты, которые можно создавать при конфигурировании, и помещать их в свои пользовательские пакеты.

В Creatio выделяют 3 типа объектов:

1. Объекты, которые связаны с таблицей в базе данных.
2. Объекты, которые связаны с представлением в базе данных.
3. Виртуальные объекты, которые используются в системе для построения иерархий и реализации механизма наследования (например, BaseEntity).

Тип объекта может быть определен при его создании в дизайнере объектов (рис. 2).

Рис. 2. — Указание типа объекта

Объект системы характеризуется тремя основными компонентами:

1. Схема объекта — это структура и свойства таблицы в БД. Схема объекта включает в себя колонки таблицы (наименования и типы данных), индексы, права доступа к схеме объекта. Схема каждого объекта представляет собой экземпляр класса EntitySchema.

2. Данные объекта — условно, это строка данных в таблице и методы их обработки. Каждая строка данных представляет собой экземпляр класса Entity.

3. Встроеный процесс объекта. Для каждого объекта системы реализована событийная модель. Обработка событий объекта реализована с помощью встроенного процесса объекта.

Модуль

Начиная с версии 7.0 клиентская часть приложения имеет модульную структуру, то есть реализована в виде набора блоков функциональности, каждый из которых реализован в отдельном модуле. В процессе работы приложения загрузка модулей и их зависимостей выполняется в соответствии с подходом Asynchronouse Module Definition (AMD).

Подход AMD декларирует механизм определения и асинхронной загрузки модулей и их зависимостей, который позволяет в процессе работы с системой подгружать только те данные, которые необходимы для работы в текущий момент. Концепцию AMD поддерживают различные JS-фреймворки. В Creatio для работы с модулями используется загрузчик RequireJS.

Понятие модуль можно сформулировать как фрагмент кода, инкапсулированный в обособленный блок, который может быть загружен и выполнен самостоятельно.

Загрузчик RequireJS предоставляет механизм объявления и загрузки модулей, базирующийся на концепции AMD. Основные принципы работы механизма загрузчика RequireJS:

1. Объявление модуля выполняется в специальной функции define(), которая регистририрует функцию-фабрику для инстанцирования модуля, но при этом не загружает его немедленно в момент вызова.
2. Зависимости модуля передаются как массив строковых значений, а не через свойства глобального объекта.
3. Загрузчик выполняет загрузку всех модулей-зависимостей, переданных в качестве аргументов в define(). Модули загружаются асинхронно, при этом порядок их загрузки определяется загрузчиком произвольно.
4. После того как будут загружены все указанные зависимости модуля, будет вызвана функция-фабрика, которая вернет значение модуля. При этом в функцию-фабрику в качестве аргументов будут переданы загруженные модули-зависимости.

Каждая клиентская схема в Creatio 7.x характеризуется как минимум одним клиентским модулем.

Клиентское ядро предоставляет механизм работы с модулями:

• Предоставляет API для доступа к клиентским модулям.
• Определяет механизм обмена сообщениями и загрузки модулей.
• Предоставляет доступ к базовым библиотекам, системным перечислениям и константам.
• Реализует клиентский механизм работы с данными.

Виды клиентских модулей

В Creatio можно выделить несколько разновидностей клиентских модулей:

1) Невизуальный модуль

Невизуальный модуль содержит в себе реализацию функциональности системы, которая, как правило, не сопряжена с привязкой данных и отображением их в интерфейсе. Примерами невизуальных модулей в системе являются модули бизнес-правил (BusinessRuleModule), утилитные модули, которые реализуют служебные функции (в базовой версии — это модули с названиями *Utilities, *UtilitiesModule).

2) Схема представления (визуальный модуль)

К визуальным модулям относятся модули, которые реализуют в системе Модели представления (ViewModel) согласно шаблону MVVM. Эти модули инкапсулируют в себе данные, которые отображаются в элементах управлениях графического интерфейса, а также методы работы с этими данными. Примерами визуальных модулей в системе являются модули моделей представления разделов, деталей, страниц.

3) Модуль расширения (замещающий клиентский модуль)

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