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-й категории.