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

Пакеты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Схема

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

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

Типы схем:

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

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

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

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

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

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

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

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

Более подробно о разных типах схем и менеджеров можно узнать из раздела "Описание платформы". Свойства и методы различных классов схем и менеджеров схем описаны в библиотеке классов.

Объект

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

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

Базовые объекты недоступны для редактирования и располагаются в предустановленных пакетах.

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

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

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

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

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

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

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

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

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

Модуль

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

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

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

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

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

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

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

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

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

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

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

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

Для создания невизуального модуля необходимо перейти в раздел [Конфигурация] и выполнить пункт меню Добавить > Расширенные > Модуль (рис. 3).

Рис. 3. — Создание невизуального модуля

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

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

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

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

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

Рис. 4. — Создание замещающего клиентского модуля