Onyma xRM — платформа для построения приложений и автоматизации бизнес-процессов. Платформа состоит из трех уровней. В приложениях, построенных на основе xRM, могут быть в произвольном наборе задействованы разные уровни (и их компоненты). Одни приложения, например, могут не использовать в своей работе бизнес-процессы, другие — не нуждаются в графическом интерфейсе...

Среди важнейших возможностей системы Onyma и ее приложений (CRM — системы взаимодействия с клиентами; BPM  — системы управления бизнес-процессами):

  • Работа с бизнес-процессами;
  • Гибкая система хранения данных;
  • Богатые возможности настройки.

1. Бизнес-процессы

Бизнес-процесс —  совокупность взаимосвязанных мероприятий или работ, направленных на создание продукта или услуги для потребителей. Бизнес-процесс позволяет автоматизировать действия пользователя и сократить число ошибок.

1.1. Пример бизнес-процесса

Для интернет-провайдера, например, один из бизнес-процессов — подключение нового пользователя к сети:

Администратор xRM может изменять уже существующие бизнес-процессы или создавать новые.

1.2. Модель процесса

Логика процесса описывается моделью. Модель содержит:

  • Список шагов;
  • Правила перехода с шага на шаг;
  • Список участников каждого шага.

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

В графическом интерфейсе каждому правилу перехода соответствует кнопка:

2. Система хранения данных

Для хранения данных xRM использует классы и создаваемые на их основе объекты.

2.1. Классы

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

2.2. Атрибуты

Атрибуты различаются типом хранимых данных, местом хранения в БД, обязательностью и т. д.

2.3. Расширение существующего класса через наследование

Часто приходится хранить сведения о похожих, но не одинаковых сущностях. Часть атрибутов у таких сущностей может совпадать, а часть — различаться. Чтобы не создавать новые классы для каждого случая, можно «расширять» существующие путем наследования. Классы-потомки наследуют все атрибуты родителя и прибавляют к ним свои. Родитель у класса может быть только один.

Наследование на примере классов, хранящих сведения о контрагентах:

2.4. Класс и объекты

На основе класса (схемы хранения данных) создаются объекты (хранилища данных). Одному классу может соответствовать любое число созданных на его основе объектов.

3. Ввод-вывод данных

Для ввод-вывода данных служат интерфейсные объекты. Каждому интерфейсному объекту сопоставлено свое представление — прослойка между интерфейсом и таблицей в базе данных. Представление является частью API. Права доступа к нему зависят от позиции пользователя.

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

О представлениях и интерфейсных объектах см. статью Данные: от БД до интерфейсного объекта.

3.1. Формы и форматы

Расположение и настройки отображения атрибутов определяются формой. Формы объединяются в наборы, или форматы. Благодаря форматам можно разделять формы, принадлежащие разным группам, «песочницам», компаниям.

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

3.2. Создание новых форм через наследование

Новые формы, как и новые классы, можно создавать путем наследования. Форма-наследник перенимает от родителя все поля и их настройки. Если изменить настройки унаследованных полей на форме-родителе, они изменятся и на форме-потомке. Наследственную связь можно разорвать, переопределив поле. (Для этого нужно изменить его настройки или хотя бы положение на форме, «сдвинув» поле мышью и вернув на место.)

3.3. Виды полей формы

Для ввода и вывода данных на форме используются поля.

Поля различаются источниками отображаемых данных:

ВидИсточник данныхФормат имени
АтрибутыКласс, которому принадлежит форма.A$99999999999
Фиктивные поляРасчет на основе значений других полей.S$НАЗВАНИЕ_ПОЛЯ
Колонки представленияТаблица в БД.НАЗВАНИЕ_СХЕМЫ.НАЗВАНИЕ_ПРЕДСТАВЛЕНИЯ.НАЗВАНИЕ_КОЛОНКИ

На основе полей создаются контро́лы (или элементы управления).

3.4. Контролы

Контро́л — надстройка над полем, расширяющая его возможности. Примеры контролов, созданных на основе простого поля ввода:

В системе есть, например, следующие элементы управления:

  • Редактор для языка разметки Textile;
  • Редактор для языка разметки HTML;
  • Поле для ввода адреса;
  • Поле для загрузки файла.

3.5. Настройки контролов

Поля и созданные на их основе элементы управления можно настраивать в зависимости от нужд решаемой задачи.

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

Примеры настроек:

4. Разграничение прав доступа

Разграничение прав доступа в xRM достигается за счет групп, позиций, ролей и допусков.

4.1. Группы

Отделу предприятия в xRM соответствует группа. Группы иерархически упорядочены. У группы может быть любое число потомков и предков (последнее не относится к группе root или \, самой верхней в иерархии).

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

Особый вид групп — личные группы. Личные группы не оказывают влияния на доступность данных; они созданы для хранения настроек операторов и контрагентов. У каждого оператора или КА есть своя личная группа.

Доступность объектов и таблиц для пользователя, имеющего доступ к некоей группе, показана ниже (пример условный):

Пользователь видит объекты, входящие в:

  • Группу, которой принадлежит его личная группа;
  • Группы-предки этой группы;
  • Группы-потомки этой группы.

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

4.2. Права доступа, роли и позиции

Права доступа к каждой части системы (полномочия) поддаются тонкой настройке:

Сочетания полномочий, необходимые для решения отдельных задач, называются ролями.

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

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

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

4.3. Допуск и грифы

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


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

В свою очередь, каждому пользователю назначен допуск. Допуск состоит из тех же двух частей, что и гриф. Пользователю доступны материалы с грифом не выше, чем его допуск.

Рассмотрим пример: пользователя, имеющего допуск к конфиденциальным материалам и к персональным данным 2-й категории.