Создание прикладной информационной системы с использованием БИС

Прикладная информационная система отличается от базовой наличием сформированной модели данных и запрограммированной логики работы с этими данными. И то и другое можно сделать внутри клиентского приложения БИС.

Собственная модель данных БИС

БИС построена на двух типах объектов:

• Объекты конфигурирования, описывающие прикладную модель данных и логику работы с ними;
  • Шаблон объекта (Template) - описывает набор атрибутов, кнопок и прочего для конкретного типа прикладного объекта.
  • Определение атрибута (AttributeDef) - описывает атрибут прикладного объекта, определяет тип значения.
  • Определение страницы/вкладки (PageDef) - группирует несколько атрибутов для отображения их на отдельной странице/вкладке.
  • Определение кнопки/команды в пользовательском интерфейсе (UICommand).
  • Правило вложения (TemplateConstraint) - определяет правила, какие объекты к каким могут быть дочерними.
  • Роль (Role) и правила доступа (AccessRule) - определяют разрешённые действия с конкретным объектом для конкретного пользователя.
  • Прочие вспомогательные объекты: именованные значения, иконки, строки локализации, элементы реестра, пространства уникальности, скриптовые действия разных типов.
  • Конфигурация (Configuration) - группирующий именованный объект для выделения логического модуля внутри прикладной модели данных.
• Объекты для хранения прикладной информации. Пять основных сущностей, атрибуты и поведение которых настраиваются через шаблоны:
  • Пользователь/группа (User) - учётная запись пользователя или группа пользователей.
  • Информационный объект (InfoObject) - основной объект для хранения прикладной информации.
  • Контейнер (DataContainer) - объект, структурирующий хранение информационных объектов.
  • Письмо/Нагрузка (WorkItem) - объект, предназначенный для сообщений пользователю, как от других пользователей (внутренняя почта), так и от системы (например нагрузка пользователю от модуля WorkFlow, или уведомление от события по изменению какого-либо объекта).
  • Процесс/задача (Task) - объект для реализации конкретных действий или достижения целей на определённом этапе бизнес процесса. Задачи могут порождаться, например, при продвижении по диаграмме бизнес процесса (WorkFlow). Экземпляр задачи для реализации себя может программно отправлять пользователям нагрузки, дожидаться их выполнения и/или отслеживать изменения в информационных объектах.

Для хранения атрибутируемых объектов мы используем по одному набору таблиц СУБД на каждую из этих пяти сущностей. То есть все атрибуты, например, информационных объектов вне зависимости от их шаблона хранятся в одной таблице СУБД. Такое решение идёт в разрез с канонами реляционных баз данных, однако преимущества в рамках нашей области применения перевесили. Каноническое реляционное решение позволяет эффективнее индексировать и искать данные, да. Наш выбор такого способа хранения позволяет полностью переделать модель данных даже, когда их часть уже внесена в систему. А разработка прикладной информационной системы часто требует именно такого подхода, когда по мере развития организации, меняется и модель данных её информационной системы. Мы изначально ориентировались именно на такой подход в разработке информационных систем.

Формирование прикладной модели данных

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

Примечание. Раздел конфигурирования в клиентском приложении БИС является средой разработки прикладной модели данных. Он доступен пользователям - конфигураторам системы. При этом как конфигураторы, так и обычные пользователи в основном разделе клиентского приложения могут сразу видеть доступные им объекты, создавать новые, нажимать на подготовленные кнопки - работать с информацией.

Атрибуты объектов в нашем случае - это нечто гораздо большее, чем можно представить. Атрибутами могут быть:

• Тексты, числа, даты, интервалы времени, флажки;
• Форматированные тексты (HTML, RTF, XAML);
• Картинки (JPEG, PNF, EMF, PDF и прочие);
• Файлы (тела файлов хранятся на файловых серверах в составе БИС);
• Коллекции атрибутируемых элементов (каждый элемент списка состоит из набора атрибутов, в том числе списковых);
• Ссылки на атрибутируемые объекты (пользователь, контейнер, информационный объект, процесс/задача);
• Ссылки на именованные значения;
• Ссылки на шаблоны, роли, иконки;
• Множества объектов;
• Подпись (в том числе ЭЦП);
• Бинарные данные;
• XML данные;
• DataSet для показа данных через ReportViewer;
• MS Chart контрол для показа графиков и диаграмм;
• Графический контрол для рисования чего-либо скриптом;
• Редактор диаграммы WorkFlow процесса.

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

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

Следующее действие - административное. В системе должны быть заведены учётные записи (User) и группы пользователей. А так же должны быть заведены корневые контейнеры (DataContainer) для формирования структуры, где какая информация будет храниться. На контейнеры назначаются ролевые права доступа для конкретных пользователей или групп, после чего информационная система готова выполнять прикладные многопользовательские  информационные задачи.

Программирование прикладной логики

Информационная система на основе БИС может работать и без единой строчки скриптового кода. В ней уже многое можно, но со скриптами, конечно, интереснее.

В качестве скриптового языка мы используем C#. Скрипты компилируются при первом запуске сервера и клиентов и далее по мере необходимости при изменениях в них. Скомпилированные скрипты в виде dll файлов с исходниками доступны для отладчика, профайлера и прочих программистских сервисов. Скрипты можно писать прямо в клиентском приложении БИС или использовать Visual Studio.

В качестве модели программирования прикладной логики мы использовали подход "скриптовой кастомизации". То есть в ключевых точках поведения информационной системы мы вставляем вызовы "кастомизаторов", делая выход в скриптовой код. Кастомизатор объекта - это один или несколько методов с предопределёнными сигнатурами и правилами вызова изнутри кода БИС.

Например, для кастомизации того, как объект выглядит в дереве, списках и ссылках БИС вызывает соответствующий метод-кастомизатор в скрипте шаблона объекта (а так же в скриптах его родительских шаблонов), чтобы скриптовой код мог вернуть необходимые значения для показа объекта, такие как: название, основная иконка, оверлейная иконка, набор дополнительных иконок, цвет и стиль текста, и множество прочих параметров.

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

За годы использования БИС, всё что нам понадобилось (или казалось полезным) для создания информационных системы, мы выносили в скриптовые кастомизаторы. На практике их получилось вполне разумное обозримое количество. При этом код кастомизации привязан к своему объекту, который он "кастомизирует" и набор точек входа в скрипт для каждого отдельного объекта сравнительно небольшой.

Мы не пытались идти по пути программистского фреймворка, когда каждая сущность - это свой c# класс. Нам требовалась гибкость и переменчивость модели данных, которая по мере роста информационной системы может меняться как угодно. Поэтому скрипты в БИС получились в большинстве своём "локальными" - то есть влияющими только на свои объекты и не влияющие на скриптовой код прочих объектов. Такая модель программирования прикладной логики оказалась достаточно простой, чтобы конфигурировать, поддерживать и развивать информационную систему могли бы и сотрудники не обладающие высокой программистской квалификацией (таких обычно не хватает).

Скрипты кастомизации естественным образом группируются вместе со своими объектами в логические модули, реализующие тот или иной компонент информационной системы. Такие модули мы называем конфигурациями. Каждая конфигурация компилируется в собственный dll файл. На уровне конфигурации настраиваются внешние dll библиотеки, зависимости от библиотечных скриптов других конфигураций, блоки using для скриптов объектов, относящихся к этой конфигурации и другие настройки. Таким образом БИС - это и программистская среда разработки сложных программных информационных систем, с естественным разбиением кода на логические модули.

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

Основа скриптового API БИС - это работа с атрибутами объектов и операция сохранения:

var container = Service.GetDataContainer( @"путь\по ключам" ); // получаем контейнер для хранения ИО
var io = new InfoObject( container, @"IO\путь\к\шаблону" ); // создаём экземпляр нового объекта
io["Name"] = "имя объекта"; // устанавливаем значение атрибута с ключом "Name"
io.Save(); // сохраняем на сервер

Этот фрагмент кода создаёт новый информационный объект, устанавливает ему имя и сохраняет на сервер.

Сопутствующие конфигурации

Часть функциональности БИС нами также реализована на уровне скриптов кастомизации отдельными конфигурациями. Собственный код БИС обеспечивает необходимый функциональный минимум, а всё, что может быть подвержено кастомизации, мы выносили на скриптовой слой.

Так сделан модуль управления бизнес-процессами (WorkFlow). Графический редактор диаграммы процесса и серверный движок, реализующий логику продвижения процесса по диаграмме реализован внутренним кодом БИС, а конкретные экземпляры процессов и подзадач этапов диаграммы - это экземпляры объектов Task, атрибутируемые по шаблонам и тем самым кастомизируемые максимально гибким образом. Уже на уровне скриптовой кастомизации в модуле WorkFlow была добавлена кастомизация процессов следующего уровня - автозадачи, которые в редакторе диаграммы разработчики процесса могут цеплять к этапам, управляя тем самым, какие именно действия или проверки должны быть выполнены при переходе от этапа к этапу по диаграмме процесса. Тем не менее скриптовой код WorkFlow открыт и сам модуль может быть адаптирован под конкретные нужды (а то и сделан заново).

Другой пример сопутствующей конфигурации - это внутренний чат. Возможность общения с картинками и ссылками на тему конкретного прикладного объекта - необычайно востребована в любых системах, где происходит многопользовательская разработка чего-либо. Бис обеспечивает рамки пользовательского интерфейса для чата, а сами чаты, групповые чаты, сообщения, контакты - это обычные для БИС информационные объекты, разложенные по контейнерам, и учётные записи пользователей. Сообщения - это HTML атрибуты элементов списка в объекте Сообщения-за-день. Добавление сообщение - очередное сохранение информационного объекта штатными средствами БИС. Скриптовой код может заводить чаты (беседы) по каким-то своим конкретным объектам (например по заявкам), добавлять необходимые атрибуты и поведение чатам.

Есть и другие общеприменимые конфигурации на стыке с внутренним кодом БИС.