low-code-book-elma365

Low-code book
Краткое руководство по созданию

Low-code решений на платформе
ELMA365
Версия 1 от 31.03.2023
Оглавление
Оглавление .................................................................................................................. 2
Введение ..................................................................................................................... 7
Глава 1. Пример создания Low-code решения ....................................................... 10
1.1. Раздел ............................................................................................................. 11
1.2. Приложение..................................................................................................... 13
1.3. Организационная структура ........................................................................... 24
1.4. Бизнес-процесс ............................................................................................... 26
1.4.1. Настройки доступа .................................................................................... 41
1.5. Запуск решения............................................................................................... 42
1.5.1. Создание отпуска ..................................................................................... 43
1.5.2. Согласование отпуска .............................................................................. 46
1.5.3. Оповещение о согласовании ................................................................... 47
1.5.4. Подготовка приказа .................................................................................. 48
Глава 2. Расширенная настройка Low-code решения ............................................ 49
2.1. Статусы отпуска .............................................................................................. 49
2.2. Автоматическая нумерация отпусков ............................................................ 54
2.3. Настройка главной страницы ......................................................................... 56
2.4. Настройка видов отпусков .............................................................................. 69
2.5. Настройка отпуска .......................................................................................... 73
2.5.1. Добавление нового свойства ................................................................... 73
2.5.2. Добавление динамических элементов на форму создания .................. 74
2.5.3. Изменение действий на форме ............................................................... 85
2.5.4. Изменение настроек приложения «Отпуск» ........................................... 88
2.6. Настройка бизнес-процесса ........................................................................... 90
2.6.1. Запись данных бизнес-процесса в элемент приложения ...................... 90
2.6.2. Учёт вида отпусков в бизнес-процессе ................................................... 92
Low-code book ELMA365 2

2.6.3. Контроль подписания приказа ............................................................... 106
2.7. Тестирование решения ................................................................................ 107
2.8. Экспорт решения .......................................................................................... 108
Глава 3. Элементы платформы ............................................................................. 114
3.1. Раздел ........................................................................................................... 115
3.2. Приложение................................................................................................... 116
3.2.1. Стандартное приложение ...................................................................... 116
3.2.2. Событие................................................................................................... 119
3.2.3. Документ ................................................................................................. 120
3.3. Интерфейс ..................................................................................................... 121
3.3.1. Страница ................................................................................................. 121
3.3.2. Виджет ..................................................................................................... 122
3.4. Бизнес-процесс ............................................................................................. 124
3.5. Группы и роли ............................................................................................... 125
3.6. Нумераторы................................................................................................... 126
3.7. Контракт ......................................................................................................... 126
3.8. Шаблоны документов ................................................................................... 127
3.9. Дополнительные параметры........................................................................ 128
3.10. Портал ......................................................................................................... 129
3.11. Модуль ......................................................................................................... 130
Глава 4. Как использовать элементы платформы................................................ 133
4.1. Работа с данными ......................................................................................... 133
4.1.1. Хранение данных .................................................................................... 133
4.1.2. Взаимодействие пользователя с данными ........................................... 133
4.1.3. Доступ к данным ..................................................................................... 134
4.1.4. Бизнес-процессы — движение данных ................................................. 135
4.1.5. Обработка данных .................................................................................. 135
4.2. Хранение настроек ....................................................................................... 137

4.2.1. Дополнительные параметры ................................................................. 137
4.2.2. Настройки модуля .................................................................................. 138
4.2.3. Приложение ............................................................................................ 138
4.3. Интеграция .................................................................................................... 139
4.4. Хранение шаблонов документов ................................................................. 139
4.4.1. Один шаблон на документ ..................................................................... 139
4.4.2. Несколько шаблонов на документ ......................................................... 139
4.5. Использование сторонних библиотек ......................................................... 140
4.5.1. Подключение .js-библиотек ................................................................... 140
4.5.2. Подключение любых библиотек On-Premises ...................................... 141
4.6. Создание микросервиса On-Premises ......................................................... 141
Глава 5. Уровни изоляции и обновление решений .............................................. 142
5.1. Изоляция на уровне приложения................................................................. 144
5.2. Изоляция на уровне раздела ....................................................................... 144
5.3. Изоляция на уровне модуля ........................................................................ 145
5.4. Изоляция на уровне решения ...................................................................... 145
5.5. Изоляция на уровне конфигурации ............................................................. 145
5.6. Примеры ........................................................................................................ 146
5.6.1. Кейс 1. Счёт ............................................................................................ 146
5.6.2. Кейс 2. Счета с особенными требованиями ......................................... 147
5.6.3. Кейс 3. Большой проект ......................................................................... 148
5.7. Как выбрать уровень изоляции .................................................................... 148
5.8. Как сохранить изоляцию ............................................................................... 149
5.8.1. Зависимости ............................................................................................ 149
5.8.2. Использование оргструктуры ................................................................. 150
5.8.3. Интерфейс создания элементов приложений из других разделов ..... 150
5.9. Обновление решений ................................................................................... 151
5.9.1. Пример .................................................................................................... 152

5.9.2. Если решение не обновляется .............................................................. 153
Глава 6. Проектирование решения ........................................................................ 154
6.1. Ролевая модель решения ............................................................................ 156
6.1.1. Роли ......................................................................................................... 156
6.1.2. Мотивы .................................................................................................... 156
6.1.3. Сценарии взаимодействия .................................................................... 157
6.2. Контуры решения .......................................................................................... 158
6.2.1. Выделение контуров решения ............................................................... 159
6.2.2. Состав контуров ...................................................................................... 161
Глава 7. Организация процесса разработки ......................................................... 163
7.1. Роли в команде при разработке решений ................................................... 163
7.2. Совмещение ролей ....................................................................................... 164
7.2.1. Человек-оркестр ..................................................................................... 164
7.2.2. Команда: 3–7 человек ............................................................................ 165
7.2.3. Большая команда или несколько команд ............................................. 166
7.3. Разработка решения командами разного размера .................................... 168
7.3.1. Человек-оркестр ..................................................................................... 168
7.3.2. Команда: 3–7 человек ............................................................................ 168
7.3.3. Несколько команд ................................................................................... 169
Глава 8. Документирование решений.................................................................... 170
Глава 9. Оптимизация решений ............................................................................. 172
9.1. Как найти неоптимальные части решения .................................................. 172
9.1.1. В интерфейсах ........................................................................................ 172
9.1.2. В сценариях ............................................................................................ 173
9.2. Рекомендации ............................................................................................... 173
9.3. ON-PREMISES Высоконагруженные решения ............................................ 174
Глава 10. Пять принципов хорошего решения ...................................................... 175
10.1. Хорошее решение — какое оно? ............................................................... 175

10.2. 5 принципов ................................................................................................. 175
10.2.1. Решает проблему заказчика ................................................................ 175
10.2.2. Отвечает критериям качества заказчика ............................................ 176
10.2.3. Хорошо документировано .................................................................... 176
10.2.4. Просто поддерживается ....................................................................... 176
10.2.5. Легко адаптируется .............................................................................. 178

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

становятся ключевым фактором успеха.
Что же такое Low-code и в чём его преимущество для бизнеса?
Традиционный подход к автоматизации часто включает в себя написание

программного кода, что требует глубоких знаний и опыта в области
программирования. Этот подход может быть медленным и затратным в реализации,
а также может потребовать значительных усилий при внесении изменений.
В свою очередь, технология Low-code даёт возможность быстро создавать

приложения и автоматизировать бизнес-процессы с минимальным
использованием кода.
Рассмотрим основные конкурентные преимущества low-code.
1. Ускорение разработки приложений.

Технологии, бизнес-процессы, потребности рынка и клиентов развиваются с
высокой скоростью. Из-за этого срок жизни решений в корпоративной среде
существенно сократился: если раньше одно решение могло использоваться
несколько лет, то теперь его жизненный цикл ограничен 2-3 годами. Уже нельзя
потратить на разработку решения год и ждать, что оно останется актуальным надолго.
Более того, сам процесс разработки решений также должен быть максимально
оптимизирован, чтобы сократить время между появлением потребности в новом
решении и его реализацией.
Low-code платформы предоставляют готовые компоненты, инструменты для

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

Одно из важных преимуществ Low-code технологии – её доступность для широкой
аудитории. В разработке приложений могут участвовать сотрудники, которые хорошо

Введение
понимают предметную область, знают потребности бизнеса и глубоко погружены в

рабочие процессы. Это помогает сократить зависимость от IT-отдела и ускорить
процесс автоматизации.
3. Относительно низкие затраты на разработку.

Использование Low-code платформ сокращает затраты на автоматизацию,
поскольку компании требуется меньше времени на создание прототипов,
тестирование гипотез и внедрение новых инструментов в работу.
4. Большая гибкость и возможность быстрого внедрения изменений.

Решения, созданные на Low-code платформах, можно легко модифицировать и
дополнять, что позволяет быстрее реагировать на изменения в бизнес-процессах в
сравнении с традиционным подходом к автоматизации.
5. Низкие требования к техническому опыту пользователей.

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

предоставляет новый инструмент для создания приложений с минимальным уровнем
написания кода.
Кроме того, Low-code платформы часто предоставляют широкий набор

инструментов для интеграции с другими системами, а также для веб-сервисов. Это
позволяет создавать по-настоящему современные и технически-продвинутые
решения.
Таким образом с помощью low-code можно решить до 90% задач по

автоматизации, а участие программистов будет минимальным.
Книга, которую вы читаете, описывает авторский подход компании ELMA к

автоматизации с использованием low-code. За свою 10-летнюю историю компания
приобрела обширную экспертизу в этой области и разработала множество решений

Введение
для различных отраслей. Книга содержит пошаговое руководство для создания low-
code решения, которое легко понять даже новичку. Однако содержание этой книги не
ограничивается техническими инструкциями. Мы поделимся лучшими практиками по
проектированию и документированию решений, рассмотрим практические кейсы и
разберём принципы разработки хороших решений. Эта книга будет полезна для всех,
кто хочет оптимизировать свои бизнес-процессы и использовать современные
технологии в своей работе.

Пример создания Low-code решения
Глава 1. Пример создания Low-code решения

Начнём знакомство с технологией Low-code с простого примера — автоматизации
бизнес-процесса согласования отпуска. В больших компаниях этот процесс может
быть довольно трудоёмким, а контроль за его выполнением может требовать
значительных усилий со стороны сотрудников и руководства. В этой главе мы
рассмотрим, как создать решение для автоматизации процесса на базе Low-code
платформы, в ходе которого сотрудникам будут автоматически назначаться задачи, а
руководителям приходить уведомления об отклонениях. Это поможет сократить
время на обработку заявлений и повысить эффективность работы.
Рассмотрим участников процесса и их задачи:
 сотрудников организации, которые вынуждены уйти в отпуск за свой счёт по

личным обстоятельствам;
 руководителей сотрудников, которые должны быть в курсе отпусков и
предварительно согласовать их;
 сотрудников отдела кадров, которые формируют приказы на отпуск.
Для создания такого решения нам потребуется доступ к Low-code платформе
ELMA365. Вы можете получить демо-версию на сайте платформы, следуя инструкции
в справке.
После получения доступа к платформе вы попадёте на главную страницу

системы.

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

Создание раздела
Создание раздела

Новый раздел
1.2. Приложение
В созданном разделе Отпуска создадим приложение Отпуск, в котором будем
хранить информацию обо всех отпусках за свой счёт в компании.
Приложение — это ключевой компонент системы, который предназначен для хранения

данных и взаимодействия с ними. По своей сути это справочник, в котором можно хранить
информацию и взаимодействовать с ней: создавать новые записи, редактировать и
просматривать их. У приложения есть контекст, формы и действия.
Контекст — это описание структуры хранения. Он определяет, какие именно данные могут
храниться в приложении. Например, Дата начала, Дата окончания отпуска и Сотрудник,
который идёт в отпуск. Контекст приложения задаётся в типизированном виде, то есть для
каждого поля в контексте приложения указывается тип данных. От типа данных зависит
доступный пользователю способ заполнения и формат хранения в базе данных. Например, когда
мы говорим о вводе даты, мы представляем её выбор в календаре, а не ручной ввод с
клавиатуры. Поэтому для полей Дата начала и Дата окончания мы будем использовать тип
данных Дата/время.
Формы — это представления данных. Форма определяет, как именно данные будут
отображаться у пользователя. Например, форма, которая открывается при создании отпуска,
должна содержать период отпуска.

Действия — это доступные кнопки взаимодействия с приложением. Например, для

сотрудника, инициирующего свой отпуск, это могут быть кнопки: Создать отпуск, Перенести
отпуск.
Создание приложения
Для отпусков за свой счёт нам необходимо хранить:
1) сотрудника, который собирается в отпуск;

2) дату начала — это дата и время начала отпуска за свой счёт. Время здесь
необходимо на случай, если отпуск нужен на несколько часов в течение
одного дня;
3) дату окончания — аналогично дате начала;
4) причину — текстовое описание с причиной для информирования
руководителя;
5) руководителя — это пользователь системы, который согласует отпуск
сотрудника.
Добавим необходимые поля в контекст приложения. Каждое свойство,
размещённое в области слева, — это поле на форме. Используя технологию Drag-
and-Drop, перетаскивайте свойства с боковой панели, чтобы добавить нужные поля.
Выберем нужные нам типы данных на боковой панели:
Боковая панель
 Для хранения сотрудника будем использовать тип Пользователь. Он

позволяет выбрать активного пользователя системы из списка с
возможностью поиска:

Поле «Сотрудник» в контексте приложения «Отпуск»
 Для хранения даты начала и даты окончания будем использовать тип

Дата/время. Дополнительно укажем, что время опционально, в этом случае
пользователь сможет выбрать сам, указывать его или нет:
Поле «Дата начала» в контексте приложения «Отпуск»

Поле «Дата окончания» в контексте приложения «Отпуск»
 Для хранения причины используем тип Строка. Чтобы пользователь мог

описать её развернуто, укажем режим отображения Текст:
Поле «Причина» в контексте приложения «Отпуск»
 Для хранения руководителя используем тип Пользователь:

Поле «Руководитель» в контексте приложения «Отпуск»
Сохранив контекст приложения, мы уже можем с ним работать: формы создания,

просмотра и редактирования сформировались автоматически на основании
настроенного контекста.
Если заполнить форму создания и сохранить её в системе, появится Элемент

приложения.
Форма создания элемента приложения «Отпуск»

Элемент приложения «Отпуск»
Элемент приложения — это карточка на странице приложения, которая создаётся

пользователями и хранит в себе внесённые ими данные.
Например, приложение Отпуск используется для хранения данных об отпусках сотрудников.

Каждый отпуск, добавленный в приложение, будет являться его элементом.
Заголовок элемента — это его название, которое мы заполнили при создании. Чтобы открыть
форму просмотра элемента приложения, нажмите на его название. Чтобы изменить его, нажмите
кнопку Редактировать. Кнопка видна только пользователям с правами доступа на
редактирование.
Улучшим форму создания элемента приложения.
Во-первых, поле Название для отпуска можно не заполнять вручную, а

формировать его автоматически по шаблону. В нём мы можем использовать контекст
приложения. Например, можно настроить шаблон названия таким: Отпуск
{$__createdBy.__name} с {$date_start} по {$date_end}. Название элементов с таким
шаблоном будет выглядеть так: Отпуск Иванов Петр с 19.04.2023 по 20.04.2023.

Настройки приложения «Отпуск»
Настройка названия элемента приложения «Отпуск»
Во-вторых, у каждого приложения есть системные поля, они создаются и

заполняются системой автоматически: Дата создания, Автор, Дата изменения,
Редактор. В этом перечне системных полей нам важно поле Автор: именно оно
хранит пользователя, который создал отпуск. Таким образом, мы можем не
использовать поле Сотрудник, которое мы добавили, а использовать системное поле
Автор. Перейдем в расширенный режим настройки формы, чтобы изменить формы
создания и просмотра:

Настройка формы приложения «Отпуск»
Переход в расширенный режим настройки формы приложения «Отпуск»

Расширенный режим настройки форм приложения «Отпуск»
На форме создания:
 уберём с формы поле Сотрудник;
Настройка формы создания элемента приложения «Отпуск»
 добавим обязательность полей.

На форме просмотра:
 уберём с формы поле Сотрудник;

 добавим поле Автор создания и переименуем его в Сотрудник.
Посмотрим, что получилось:

Форма просмотра элемента приложения «Отпуск»
В-третьих, можно не заполнять вручную поле Руководитель. Система может

определить его автоматически, если настроена организационная структура.
1.3. Организационная структура

Настроим организационную структуру компании. Она позволит определять
руководителя автоматически, а также ставить задачи сотрудникам на определённых
должностях.
Перейдем в раздел Администрирование — Орг. Структура.

Администрирование системы
В открывшемся редакторе настроим Организационную структуру. Добавим

несколько отделов:
 Отдел продаж;
 Отдел поддержки;
 Отдел закупок;
 Отдел кадров.
Внутри отделов добавим начальников, а под ними группу сотрудников отдела.
Такой структуры будет достаточно для нашего примера.
Настройка организационной структуры

Теперь мы сможем назначать пользователей на нужные должности.
1.4. Бизнес-процесс
Настроим бизнес-процесс согласования отпуска.
Бизнес-процесс — это регулярно повторяющаяся последовательность взаимосвязанных

действий, направленных на создание определённого продукта или услуги для потребителей. При
этом потребителями могут быть не только внешние заказчики, но и внутренние. Например, банк
выдаёт кредиты своим клиентам — это бизнес-процесс с внешним заказчиком. Когда тот же банк
принимает на работу менеджера по кредитованию, в качестве заказчика будет выступать уже
руководитель департамента банка, который ищет себе нового сотрудника. Такой бизнес-процесс
удовлетворяет внутренние нужды компании.
Процессы можно описать и при помощи должностных инструкций, но лучше использовать для
этого специальные нотации. В системе за основу мы взяли нотацию BPMN 2.0. Она позволяет
не только описать последовательность действий в процессе, но и определить его участников.
Это, несомненно, одно из главных преимуществ нотации BPMN. Подробнее с нотацией можно
познакомиться на сайте.
Бизнес-процесс в BPMN — это схема, на которой каждый участник представлен в виде Зоны
ответственности. Внутри зоны ответственности располагаются события и задачи, за которые
отвечает участник процесса.
Вот, например, как будет выглядеть простой процесс покупки техники, описанный в ELMA365:
Пример бизнес-процесса
Определим участников бизнес-процесса:

 Инициатор — любой сотрудник организации, который собирается взять

отпуск за свой счет;
 Руководитель инициатора, который должен согласовать отпуск;
 Сотрудник отдела кадров, который формирует приказ на отпуск.
Создадим бизнес-процесс согласования отпуска. Если мы сделаем это через
приложение Отпуск, то процесс будет автоматически связан с приложением. Сразу
после создания элемента приложения Отпуск система автоматически запустит
связанный бизнес-процесс.
Бизнес-процессы приложения «Отпуск»

Создание бизнес-процесса
Сразу после создания мы попадаем в дизайнер бизнес-процессов. В нём уже есть

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

На первой вкладке находятся стандартные элементы, такие как Задача, Оповещение, Шлюз
и т. п. На второй — дополнительные элементы для работы с приложениями, документами и

другими элементами системы. На третьей — интеграционные элементы, которые позволяют

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

дальнейшем поставить ему задачу согласования. Для определения руководителя в
системе существует специальное действие в списке дополнительных элементов —
Получить руководителя. Перенесём его на схему процесса и соединим со
стартовым событием переходом.
Переход задаёт порядок выполнения действий и определяет последовательность событий в

процессе. Подписи к переходам повышают наглядность схемы, а также служат названиями
кнопок на формах задач.
Например, у задачи Заполнить заявление на отпуск/отгул есть два исходящих перехода:

Завершить и Отправить на согласование.
Пример переходов на схеме бизнес-процесса

Действие «Получить руководителя» на схеме бизнес-процесса
Настроим действие. Чтобы сохранить пользователя, который является

руководителем инициатора, создадим новую переменную в контексте процесса.
Сделать это можно прямо из настроек блока.
Все переменные бизнес-процесса находятся на вкладке Контекст. Они похожи на контекст

приложения, только связаны с бизнес-процессом.
Настройка действия «Получить руководителя»

Добавление свойства в контекст бизнес-процесса
Настройка действия «Получить руководителя»
Добавим зону ответственности Руководитель в процесс.
Зона ответственности может быть динамической или статической.
Динамическая зона ответственности используется, если должность участника определяется

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

до начала процесса. Например, главный бухгалтер или сотрудник отдела кадров.

Добавление зоны ответственности на схему бизнес-процесса
Выберем динамическую зону ответственности, а её исполнителем назначим

руководителя.
Теперь можно поставить руководителю задачу согласования отпуска.

Задача — это один из инструментов для организации работы внутри компании. Задачи могут
ставиться автоматически в рамках бизнес-процесса или вручную сотрудниками. Все задачи
отображаются в одноимённом разделе.
Задачи пользователя
Задача находится на вкладке стандартных элементов бизнес-процесса.

Перенесём её на схему процесса и соединим с действием получения руководителя.
Задача на схеме бизнес-процесса

Настроим задачу согласования:
 в названии укажем Согласовать отпуск;

 чтобы руководитель понимал, чей именно отпуск он согласует, настроим
формирование названия по шаблону. Если настроить шаблон таким
образом: Согласовать отпуск {$__createdBy.__name}, название задачи
будет выглядеть так: Согласовать отпуск Иванов Петр;
Настройка шаблона формирования названия задачи
 настроим форму задачи: добавим поля Отпуск и Комментарий на форму.

Так как Отпуск — это переменная типа Приложение, мы можем вывести на
форму поля этого приложения. Например, дату начала, завершения и
причину. Для этого нажмём на Отпуск, перейдём на вкладку Свойства,
перенесём нужные поля в правую область и сохраним настройки.

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

Оповещение. Оповещение по процессам отправляются в ленту сотрудника.
Лента позволяет наладить внутренние коммуникации в компании. В ней отображаются все

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

Лента пользователя
Перенесем Оповещение в зону ответственности руководителя, соединим его с

задачей согласования и перейдём к настройкам:
 в названии укажем: Оповещение о согласовании;

 в теме: Отпуск согласован;
 в тексте сообщения напишем: Ваш отпуск с {$leave.date_start} по
{$leave.date_end} согласован руководителем. Такой текст сообщения
будет выглядеть таким образом: Ваш отпуск с 19.04.2023 по 20.04.2023
согласован руководителем;
 на вкладке Получатели удалим Текущего пользователя и добавим
контекстную переменную Инициатор.
Сохраним настройки Оповещения и повторим действия: добавим оповещение на
случай, если руководитель не согласовал отпуск.
Оповещения на схеме бизнес-процесса
Добавим конечное событие на схему процесса после оповещения об отказе и

соединим с ним.

Конечное событие на схеме бизнес-процесса
Добавим ещё одну зону ответственности на схему бизнес-процесса для

сотрудника отдела кадров. Такая зона ответственности будет статической. В
настройках выберем Элемент оргструктуры и найдём в ней должность Сотрудник
отдела кадров.
Добавим на схему бизнес-процесса задачу для сотрудника отдела кадров и

соединим её переходом с оповещением о согласовании.

В настройках задачи:
 укажем название: Подготовить приказ на отпуск;

 чтобы сотрудник отдела кадров понимал, для кого именно необходимо
подготовить приказ, включим настройку формирования названия по
шаблону. Если настроить шаблон таким образом: Подготовить приказ на
отпуск за свой счет для {$__createdBy.__name}, название задачи будет
выглядеть так: Подготовить приказ на отпуск за свой счет для Иванов
Петр;
 на форму задачи достаточно вывести поле Отпуск и его вложенные
свойства: Дату начала, Дату окончания, Руководителя.

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

выбраны группа пользователей или отдел. Задача будет назначаться на всех сотрудников,
входящих в группу или отдел. Вы можете выбрать, каким образом пользователи будут её
выполнять:
Кто первый — задача будет назначена одновременно всем сотрудникам, указанным в

качестве исполнителей в зоне ответственности. Как только кто-то начнёт работу по задаче, она
исчезнет из списка задач остальных исполнителей.
Параллельное — задача будет поставлена одновременно всем исполнителям, указанным в

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

сотруднику, указанному в качестве исполнителя в зоне ответственности, а затем другому.
Процесс перейдёт к следующему шагу после того, как все сотрудники выполнят задачу.
После подготовки приказа настроим отправку инициатору оповещения о

необходимости подойти в отдел кадров и подписать приказ.

Оповещение на схеме бизнес-процесса
Настроим тему и текст оповещения, а также укажем инициатора бизнес-процесса

получателем.
Настройка оповещения
Добавим конечное событие после оповещения.

Конечное событие на схеме бизнес-процесса
Теперь можно опубликовать первую версию нашего бизнес-процесса и

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

права доступа к одному и тому же приложению. Например, сотрудник отдела продаж сможет
создавать, редактировать и просматривать только свои отпуска, а сотрудник отдела кадров —
отпуска всех сотрудников компании.
По умолчанию все новые приложения доступны группе Все пользователи. Но доступ можно
ограничить:
На уровне приложения — при выборе этой опции настройки доступа будут применяться ко
всем элементам данного приложения.
На уровне папок приложения — при настроенном иерархическом справочнике доступ

можно задавать отдельно для папок приложения.
На уровне элементов приложения — пользователи с уровнем доступа Назначение прав

смогут задавать права доступа отдельно для каждого элемента приложения. Также в качестве
объекта для назначения прав доступа можно будет указать автора элемента приложения.
Настроим права доступа к приложению Отпуск. Нам необходимо ограничить

доступ на уровне элементов приложения:

 все пользователи могут создавать элементы;

 автор может просматривать и редактировать;
 отдел кадров имеет полные права.
Настройки доступа приложения «Отпуск»
1.5. Запуск решения

Пригласим нового пользователя, чтобы проверить как работает реализованное
решение. Перейдем в раздел Администрирование — Пользователи и пригласим
несколько новых пользователей:
 Васильев Иван — начальник отдела продаж;

 Иванов Петр — клиентский менеджер;
 Петрова Мария — сотрудник отдела кадров;
 Карпов Владимир — сотрудник отдела кадров.

Логин пользователя в системе — e-mail, поэтому он должен быть уникальным. Чтобы

пригласить в систему нового пользователя, можно использовать свою почту несколько раз,
добавляя ей уникальности. Например, если почта администратора системы
example@elma365.ru, то вы не сможете добавить еще одного пользователя с таким же e-mail. Но
можно пригласить нового пользователя, добавив «+1» к e-mail: example+1@elma365.ru. Система
решит, что это уникальный e-mail, но вы как обладатель почты example@elma365.ru сможете
получить письмо со ссылкой-приглашением.
Если нужно добавить больше пользователей, можно увеличить цифру, например «+2». Или
явно указать роль пользователя, например example+chief@elma365.ru.
Для активации учетной записи необходимо принять приглашение, которое пришло

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

воспользуйтесь разными браузерами или режимом инкогнито.
1.5.1. Создание отпуска

Зайдём в систему под аккаунтом клиентского менеджера и перейдём в раздел
Отпуска. Убедимся, что права доступа настроены корректно и клиентский менеджер
не видит отпуска администратора, которые мы создали ранее.

Приложение «Отпуск»
Оформим отпуск:
Система автоматически уведомит инициатора бизнес-процесса о том, что процесс

запущен.

Сообщение в ленте пользователя о запуске бизнес-процесса
Инициатор может увидеть задачу согласования для своего руководителя в

исходящих задачах.
Исходящие задачи пользователя

1.5.2. Согласование отпуска

Зайдём в систему под аккаунтом начальника отдела продаж и перейдём в раздел
Задачи.
Задача согласования руководителем
Руководителю пришла задача согласования отпуска, в которой он видит

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

Форма задачи согласования
1.5.3. Оповещение о согласовании

Инициатор бизнес-процесса автоматически получает уведомление, после того как
руководитель принял решение.
Оповещение в ленте пользователя о согласовании

1.5.4. Подготовка приказа

Сотрудник отдела кадров получает задачу подготовить приказ.
Форма задачи подготовки приказа
После её выполнения бизнес-процесс завершится.
В следующей главе мы будем совершенствовать наше решение, постепенно

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

Расширенная настройка Low-code решения
Глава 2. Расширенная настройка Low-code

решения
В предыдущей главе мы настроили простое решение для автоматизации процесса
согласования отпуска. В этой главе мы улучшим его, используя тонкую настройку.
2.1. Статусы отпуска

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

автоматически в рамках бизнес-процесса.
Статус отпуска будем изменять по ходу бизнес-процесса.
Настройка статуса приложения

Добавим статусы в приложение Отпуск:
 Новый — начальный статус приложения. Как только сотрудник создаст

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

просматривать список элементов приложений не только в виде плитки или таблицы,
но и в виде канбан-доски.

Настройка отображения элементов приложения
Отображение элементов в виде канбан-доски
Сейчас существующие элементы приложения Отпуск находятся в начальном

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

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

Управление статусом
Настроим элемент, установим статус На согласовании.
Настройка изменения статуса
По аналогии добавим ещё два элемента для изменения статуса в бизнес-

процесс. Будем изменять статус на Не согласован и на Согласован после задачи
согласования руководителем. После чего опубликуем бизнес-процесс.

Схема бизнес-процесса
Создадим несколько элементов приложения Отпуск и оставим их на разных

этапах бизнес-процесса.
Отображение элементов приложения в виде канбан-доски
Статусы элементов отображаются не только на канбан-доске, но и на самой

форме просмотра элемента приложения.

Отображение статуса на форме просмотра отпуска
2.2. Автоматическая нумерация отпусков

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

номеров для элементов приложения. Например, для присвоения номера документу при
регистрации.
Различают нумераторы на уровне раздела и на уровне приложения. Первые служат для

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

Нумератор
Настройки нумератора
В настройках нумератора мы можем увидеть поле Следующий номер, в

котором номер отличается от 1, если уже создавались элементы приложения. При
необходимости следующий номер можно изменить.
Добавим порядковый номер в шаблон формирования названия Отпуска:

[{$__index}] {$__createdBy.__name} с {$date_start} по {$date_end}.

Индекс в шаблоне названия
После изменения шаблона названия мы можем обновить существующие

элементы повторно сохранив их.
Название элемента приложения
2.3. Настройка главной страницы

Настроим главную страницу системы, чтобы пользователю было проще в ней
ориентироваться.

Главная страница по умолчанию
Сразу после авторизации пользователь попадает на главную страницу ELMA365. Здесь он

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

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

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

работать пользователи. В системе существует предустановленный набор виджетов, а также
возможность создавать свои виджеты.
Настроим главную страницу. Разместим на ней две колонки:
 в левой колонке дадим пользователю возможность оформить отпуск или

воспользоваться другими сервисами организации;
 в правой напишем краткую информацию о компании.

Перед этим удалим с главной страницы текущие виджеты.
Удаление виджета по умолчанию
Затем настроим отображение страницы в две колонки. Для этого перейдём в

Настройки страницы и выберем необходимое количество колонок.
Переход в настройки страницы

Настройки страницы
Перейдём в конструктор левой колонки и настроим её.
Главная страница в дизайнере интерфейсов
Все доступные виджеты размещены в правой части конструктора.
Все виджеты для удобства сгруппированы по смыслу:
 Размещение элементов — виджеты в этой группе позволяют размещать информацию

на вкладках, в колонках, в меню и на панелях;
 HTML-виджеты позволяют использовать HTML-код для отображения информации;
 Простые виджеты позволяют вывести кнопку или надпись;

 Виджеты отчетов позволяют вывести информацию в виде графика, диаграммы или

таблицы;
 Виджеты системных разделов, которые используются в них. Например, План проекта

в разделе Проекты;
 Виджеты для работы с данными, которые помогают отобразить данные, хранящиеся

в системе. Например, Лист согласования документа;
 Виджеты для страниц помогают организовать информацию на странице: вывести

заголовок или её содержимое;
 Виджеты для внешнего портала помогают организовать его интерфейс для внешних
пользователей: вывести доступные на портале страницы или заголовок с логотипом
и информацией о пользователе;
 Другие виджеты.
Изменим заголовок страницы. Для этого выделим виджет Надпись и перейдём к

его настройкам.
Настройка виджета «Надпись»
Изменим текст в настройках виджета.

Настройка виджета «Надпись»
Удалим стандартный виджет Код.
Удаление виджета «Код»
Добавим необходимые виджеты. Для этого перетащим нужные виджеты с боковой

панели, используя Drag-and-Drop.
Добавим панель с заголовком Кадровые сервисы и сделаем её сворачиваемой.

Настройка панели с заголовком
Панель «Кадровые сервисы»
Внутри панели добавим виджет Колонки.

Виджет «Колонки»
Виджет «Колонки»
В колонках разметим необходимые сервисы, например, оформление отпуска и

командировки. Для этого в левую колонку добавим несворачиваемую панель
Отпуск.

Виджет «Панель с заголовком»
Внутрь панели поместим виджет Текст с описанием сервиса и виджет Кнопка,

при нажатии на которую будет создаваться элемент приложения Отпуск.
Настройка виджета «Текст»

Настройка виджета «Кнопка»
По аналогии добавим ещё несколько панелей:
 Командировку в Кадровых сервисах;

 Заявку на технику и IT-инцидент в IT-сервисах.
Мы добавим эти панели в качестве наглядного примера того, как может выглядеть
главная страница. Кнопки в этих сервисах пока не будут работать, т. к. мы не
настроили для них приложения и бизнес-процессы.
Левая колонка в дизайнере интерфейсов

Главная страница
Перейдём в конструктор правой колонки главной страницы и настроим её,

используя несколько виджетов:
 Заголовок страницы;
 Содержимое страницы;
 Текст.
Правая колонка в дизайнере интерфейсов

Настроенная правая колонка
Если необходимо создать главную страницу, используя бренд-бук организации,

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

этого перейдём в режим редактирования панели кнопок и создадим новую кнопку.
Редактирование панели кнопок

Создание кнопки
При необходимости можно добавить ещё несколько кнопок на верхнюю панель

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

Оформление отпуска
2.4. Настройка видов отпусков

В первой главе мы создали приложение Отпуск, имея в виду, что это отпуск за
свой счёт. В реальности видов отпусков гораздо больше. Вот, например, некоторые
из них:
 отпуск за свой счёт;

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

Добавим в него необходимые поля:
1. Название для хранения вида отпуска;

2. Описание типа Строка с форматом отображения Текст для хранения
описания вида отпуска;
3. Требуется приказ типа Выбор «да/нет» для хранения параметра, который
покажет необходимость формирования приказа. Например, для отпуска по
нетрудоспособности он не нужен.
Настройки формы

Для удобной навигации создадим разделитель. Он поможет отделить основное

приложение Отпуск от справочника Виды отпусков.
Разделитель — это простой инструмент для группировки приложений внутри раздела по

тематике.
В примере ниже использованы разделители Регламенты и Документы:
Пример разделителя
Создание разделителя

Создание разделителя
Настройка списка приложений

Разделитель в списке приложений
Заполним справочник Вид отпуска. В поле Описание укажем краткую инструкцию

для пользователя. В дальнейшем мы будем выводить её на форму создания.
Параметры будем использовать в бизнес-процессе.
Виды отпуска
2.5. Настройка отпуска
2.5.1. Добавление нового свойства

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

контекст. Чтобы в одном из полей приложения Отпуск можно было выбрать вид
отпуска, добавим свойство типа Приложение и выберем приложение Вид отпуска
из списка.
Виды отпуска
Выбор приложения
2.5.2. Добавление динамических элементов на форму создания

Добавим на форму создания динамические элементы:
 ограничим ввод даты:

o нельзя указать дату начала отпуска ранее, чем текущая дата;
o нельзя указать дату окончания отпуска ранее, чем дата начала;
 будем выводить описание отпуска как инструкцию к форме.

Чтобы добавить динамические элементы, воспользуемся дизайнером

интерфейсов. Для этого в настройках формы добавим форму создания элемента.
Настройки формы
Создание формы

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

которые добавлены на форму создания в её настройках. Удалим этот виджет и
добавим свойства по отдельности. Они расположены на боковой панели на вкладке
Свойства.

Свойства приложения в дизайнере интерфейсов
Свойства, добавленные на форму создания
Ограничение ввода дат

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

Сценарии могут быть:
 Клиентскими — выполняются в браузере пользователя;
 Серверными — обрабатываются на сервере ELMA365;
 Смешанными — сценарий, который выполняется на стороне клиента и вызывает

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

клиентские — с ограничением. Например, если в каком-либо приложении ограничен доступ к
элементам, то при попытке загрузить элемент, к которому у текущего пользователя нет доступа,
клиентский код вернёт ошибку, а серверный выполнится успешно. Аналогично при получении
списка элементов, на стороне Клиента вернутся только те, к которым есть доступ, на стороне
Сервера — все.
Как правило, сценарии для виджетов не требуют больших мощностей для реализации, и мы
рекомендуем писать их на стороне Клиента.
Работа со сценариями осуществляется на языке TypeScript в удобной среде разработки в

дизайнере интерфейсов на вкладке Сценарии.
Полное описание возможностей сценариев и примеров можно найти в TypeScript SDK.
Перейдём в настройки свойства Дата начала. На вкладке События создадим

сценарий на стороне Клиента для события при изменении значения. Такой сценарий
будет выполняться, когда пользователь изменит значение в поле Дата начала.
Создание сценария

Нажмём на кнопку Открыть и перейдём в редактор сценариев. Напишем

сценарий, который ограничивает ввод Даты окончания.
Сценарий на изменение значения даты начала
async function change_startdate(): Promise<void> {
if (Context.data.date_start) // если заполнена Дата начала

{
Context.fields.date_end.data.setFilter((self, global) => global.and(
// установить фильтр для Даты окончания
self.gt(Context.data.date_start!), // значение должно быть больше Даты начала
));
}
else
{
Context.fields.date_end.data.clearFilter(); // сбросить фильтр
}
}
Чтобы ограничить ввод даты начала по текущей дате, необходимо использовать

сценарий, который вызывается при загрузке формы. Для этого используется
системная функция onInit().

Сценарий «onInit»
async function onInit(): Promise<void> {
Context.fields.date_start.data.setFilter((self, global) => global.and(

// установить фильтр для Даты начала
self.gte(new Datetime()), // значение должно быть больше и равно текущей дате
));
}
Опубликуем форму и посмотрим, как она выглядит для пользователя:
Дата начала ограничена по текущей дате

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

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

Создание свойства в контексте формы
Теперь перейдём в шаблон формы и настроим виджет Инструкция:
Создание свойства в контексте формы
Свяжем свойство Описание с текстом инструкции:

Настройка виджета «Инструкция»
Теперь создадим сценарий, который будет срабатывать при изменении значения

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

Сценарий
async function change_leave_type(): Promise<void> {

if (Context.data.leave_type) // если заполнен Вид отпуска
{
const leaveType = await Context.data.leave_type.fetch(); // получить данные
элемента приложения Вид отпуска
ViewContext.data.description = leaveType.data.description; // заполнить
описание в контексте формы
}
else
{
ViewContext.data.description = 'Выберите вид отпуска.';
}
}
Опубликуем форму и посмотрим, как она выглядит:

Инструкция на форме создания
Изменённая инструкция на форме создания
2.5.3. Изменение действий на форме

После создания нового элемента приложения Отпуск у пользователя по
умолчанию есть два действия:
 Сохранить — сохраняется элемент приложения и запускается связанный с

ним бизнес-процесс;

 Отмена — отменяется создание отпуска.
Действия — это доступные кнопки взаимодействия с приложением. Например, для

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

действие. Откроем форму создания элемента приложения, нажмём на значок
шестеренки рядом с кнопками и перейдём в режим редактирования действий. В этом
режиме можно изменить существующие кнопки или добавить новые.
Изменение действий на форме создания
Нажмём на значок шестеренки рядом с кнопкой Сохранить и зададим новое

название кнопки: На согласование.

Изменение названия кнопки «Сохранить» на «На согласование»
Сохраним изменения и выйдем из режима редактирования. Изменения сразу

отобразятся на форме. Теперь пользователю будет понятно, что именно произойдёт
после добавления отпуска.
Форма создания

2.5.4. Изменение настроек приложения «Отпуск»

Перейдём в настройки приложения Отпуск и немного изменим формат
отображения.
Настройки приложения
Изменим иконку приложения и формат отображения элементов на табличный.

Теперь у каждого пользователя элементы приложения Отпуска будут отображаться
в виде таблицы.
Настройки приложения

Далее выберем свойства, которые будут отображаться в таблице:
 Название;
 Дата начала;
 Дата окончания;
 Статус.
Настройка таблицы
Настройка таблицы

Табличное отображение
2.6. Настройка бизнес-процесса

Теперь доработаем наш бизнес-процесс так, чтобы:
 сохранять информацию о руководителе не только в бизнес-процессе, но и в

элементе приложения;
 учитывать вид отпуска в схеме бизнес-процесса. Например, если это отпуск
по временной нетрудоспособности, не ставить задачу на подготовку
приказа;
 контролировать подписание приказа сотрудником.
2.6.1. Запись данных бизнес-процесса в элемент приложения

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

Изменение элемента на схеме бизнес-процесса
Перейдём в настройки блока Изменение элемента и установим следующие

опции:
 выберем переменную Отпуск. Элемент этого приложения будет изменён. В

нашем примере именно этот элемент приложения Отпуск создал
инициатор, после чего запустился процесс согласования;
 способ изменения установим Автоматически. Это позволит записать
данные без дополнительных действий пользователя.
Настройки блока «Изменение элемента»

Теперь перейдём на вкладку Значения полей и укажем, какие именно данные

будут передаваться из бизнес-процесса в элемент приложения Отпуск:
 в поле Сотрудник приложения Отпуск запишем инициатора бизнес-

процесса;
 в поле Руководитель приложения Отпуск запишем руководителя
инициатора.
Настройки блока «Изменение элемента»
2.6.2. Учёт вида отпусков в бизнес-процессе

Так как теперь в бизнес-процессе обрабатывается не только отпуск за свой счёт,
но и другие виды отпусков, изменим шаблон названия задачи Подготовить приказ
на отпуск. Ранее в шаблоне названия мы использовали вид отпуска. Теперь настроим
шаблон следующим образом: Подготовить приказ на отпуск для
{$__createdBy.__name}.
Кроме этого, добавим на форму информацию о сотруднике и виде отпуска.

Настройки свойства «Отпуск» на форме задачи
Теперь настроим бизнес-процесс таким образом, чтобы задача на подготовку

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

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

определить, нужен приказ или нет, передадим эти данные из элемента приложения
Вид отпуска в контекст бизнес-процесса.
Добавим в контекст процесса свойства Требуется приказ типа Выбор «да/нет».

Добавление нового свойства в контекст бизнес-процесса
Создадим в контексте бизнес-процесса ещё одно свойство и назовём его Дата

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

записать данные из элемента приложения в контекст бизнес-процесса. Разместим его
после элемента Оповещение о согласовании, добавим переход.
Элемент «Присваивание» на схеме бизнес-процесса

Перейдём в настройки элемента Присваивание на вкладку Таблица

соответствия и установим следующие соответствия:
 в поле Требуется приказ контекста процесса запишется значение поля

Требуется приказ, соответствующее виду отпуска и содержащееся в элементе
приложения Отпуск;
 в поле Дата начала отпуска контекста процесса запишется значение поля

Дата начала, содержащееся в элементе приложения Отпуск.
Настройки элемента «Присваивание»
Установим срок выполнения задачи Подготовить приказ на отпуск: за 3 рабочих

дня до даты начала отпуска.

Настройка времени выполнения задачи
Вынесем на схему процесса исключающий шлюз между элементом

Присваивание и задачей Подготовить приказ на отпуск, добавим переходы.
Исключающий шлюз направляет процесс только по одному исходящему переходу.
Как только процесс достигнет шлюза, система проверит заданные условия и выберет тот
переход, для которого условие выполнилось. Порядок проверки задаётся в настройках шлюза,
на вкладке Переходы.
Для исключающего шлюза обязательно должен быть указан переход по умолчанию.
Подпишем переход из Шлюза в задачу и настроим условие перехода. Процесс

перейдёт к задаче Подготовить приказ на отпуск, если свойство процесса
Требуется приказ имеет значение Да.

Настройка условий перехода
Шлюз на схеме бизнес-процесса
Теперь добавим ещё один переход из шлюза — на случай, когда сотрудник

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

 возможностью продлить отпуск.
Для этого создадим в контексте бизнес-процесса новые свойства:
 Номер больничного листа типа Строка;

 Дата окончания отпуска типа Дата/время.
Контекст бизнес-процесса
Дату окончания будем получать из приложения Отпуск. Для этого изменим

настройки элемента Присваивание, добавив получение в поле контекста
Дата окончания отпуска значение Дата окончания из элемента приложения
Отпуск.
Настройки элемента «Присваивание»

Добавим на схему бизнес-процесса элемент Таймер и соединим его со шлюзом:
Таймер на схеме бизнес-процесса
Настроим условия перехода:
Настройки перехода
Теперь настроим таймер. В сроке выполнения укажем переменную бизнес-

процесса Дата окончания отпуска. В этом случае бизнес-процесс остановится на

элементе Таймер до даты окончания отпуска. Как только она наступит, бизнес-
процесс двинется дальше по схеме.
Настройки таймера
Добавим переход по умолчанию из шлюза. Он понадобится, например, в том

случае, когда поле Требуется приказ окажется пустым. Такое может произойти, когда
это поле будет не заполнено в элементе приложения Вид отпуска.
Переход по умолчанию на схеме бизнес-процесса

В случае, если параметр Требуется приказ не установлен, сотрудник отдела

кадров получит задачу подготовить приказ. В этом примере мы добавили отдельный
переход, а не использовали существующий для демонстрации логики настройки
бизнес-процесса.
Перейдём в настройки шлюза и выберем переход по умолчанию:
Настройка перехода по умолчанию
На схему бизнес-процесса в зону ответственности инициатора добавим задачу

Указать больничный лист и соединим её с Таймером.

Настроим форму задачи:
 добавим информацию об отпуске и вынесем свойства переменной Отпуск

только для чтения;
 сделаем свойство Номер больничного листа обязательным для
заполнения.
Настроим переходы из задачи:

1) для продления больничного листа и оповещения об этом руководителя;

2) для закрытия больничного листа и оповещения об этом сотрудника отдела
кадров. Вместо оповещения можно добавить задачу бухгалтеру для расчёта
суммы больничных и её выплаты. Мы пропустим этот шаг, чтобы не
повторять настройки уже знакомых элементов.
Элементы «Оповещение» на схеме бизнес-процесса
Обратим внимание на переход Продлить больничный. Если пользователь его

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

Настройка формы подтверждения для перехода
Настройки формы подтверждения для перехода

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

обновлённую Дату окончания в элемент приложения Отпуск. Для этого
воспользуемся блоком Изменение элемента. Установим его между оповещением
Больничный лист продлен и Таймером, добавим переходы.
Блок «Изменение элемента» на схеме бизнес-процесса

В настройках блока Изменение элемента в качестве переменной выберем

Отпуск. На вкладке Значения полей установим связь между полем приложения Дата
окончания и переменной, содержащей новую дату окончания отпуска.
Изменим названия элементов для наглядности:
Схема бизнес-процесса
2.6.3. Контроль подписания приказа

Добавим сотруднику отдела кадров задачу контроля подписания приказа:

Задача контроля подписания на схеме бизнес-процесса
Настроим форму задачи:
2.7. Тестирование решения

Для тестирования решения можно воспользоваться учётными записями
пользователей, которые мы создали в предыдущей главе или механизмом отладки.

Отладка — это этап разработки бизнес-процесса, в ходе которого обнаруживают и

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

настроить стартовую форму события, чтобы при запуске отладки вы могли передать
в бизнес-процесс входные параметры. Такой приём может быть полезен в двух
случаях:
1) если вы отлаживаете бизнес-процесс, который является дочерним для

других процессов, чтобы заполнить в нём входные параметры;
2) если вы отлаживаете бизнес-процесс, который связан с приложением и
запускается сразу после создания его элемента, чтобы заполнить элемент
После того как вы протестируете бизнес-процесс и интерфейсы, можно
передавать функционал реальным пользователям.
2.8. Экспорт решения

После того как решение готово, можно экспортировать его из среды разработки,
чтобы затем импортировать в продакшн. Подробнее о средах разработки можно
узнать в главе «Организация процесса разработки».
В системе существует несколько пакетов экспорта:
1. Приложение — включает в себя само приложение со всем его содержимым.

Такой пакет экспорта для нас не подходит, так как мы используем несколько
приложений: Отпуск и Вид отпуска.
2. Раздел — включает в себя всё содержимое раздела. Этот вид экспорта для
нас наиболее предпочтителен.
3. Модуль — включает в себя всё содержимое модуля;
4. Решение — состоит из Разделов и Модулей, включает в себя их
содержимое;
5. Конфигурация — включает в себя все разделы и организационную
структуру компании.

Модуль и решение в нашем примере не используются, поэтому рассматривать их

не будем. Подробнее о них можно узнать в главе «Уровни изоляции и обновление
решений».
Экспортируем раздел Отпуск.
Настройки раздела «Отпуск»
Ошибка экспорта раздела «Отпуск»
Так как в бизнес-процессе в зоне ответственности использовались должности из

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

Есть вариант решения этой проблемы. Можно экспортировать конфигурацию

целиком через раздел Администрирование. Пакет экспорта конфигурации включает
в себя все разделы и организационную структуру.
Экспорт конфигурации в разделе «Администрирование»
Экспорт конфигурации — самый простой путь. Используя его, вы можете не

задумываться об изоляции решения.
Однако такой экспорт не всегда допустим. Например, если вы разрабатываете

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

изоляцию раздела Отпуск. Для этого необходимо отказаться от прямого
использования организационной структуры. Однако отказаться от неё совсем мы не
можем: в решении ставится задача сотрудникам отдела кадров, то есть
пользователям, назначенным на определённую должность.
Для решения такой задачи используются Группы и роли на уровне раздела или
приложения. Создадим группу Сотрудники отдела кадров в нашем разделе.

Настройки раздела
Настройка групп
Добавление в группу должности «Сотрудник отдела кадров»

Создание группы «Сотрудники отдела кадров»
После создания группы изменим бизнес-процесс: вместо должности выберем

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

Проверка раздела «Отпуск» при экспорте
Успешный экспорт раздела «Отпуск» в файл
Изменённый бизнес-процесс будет работать так же, как раньше. Единственное,

что изменится: после импорта раздела в другую среду потребуется указать в группе
Сотрудники отдела кадров должности пользователей.
Теперь можно параллельно вести разработку и переносить изменения

независимо от других частей системы.

Элементы платформы
Глава 3. Элементы платформы

Разберём, какие элементы существуют в ELMA365:
 Раздел размещается в левом меню системы и объединяет в себе

приложения, страницы, контракты и бизнес-процессы, реализуя функционал
для обеспечения работы одной бизнес-функции или бизнес-задачи;
 Приложение предназначено для хранения данных. По своей сути это
справочник. Приложение имеет:
o структуру данных — контекст приложения;
o формы элементов приложения: создание, редактирование, просмотр,
а также формат отображения для списка элементов: таблица, плитка
и канбан;
o кнопки действия;
o дополнительный настройки;
 Интерфейс предназначен для создания:
o страниц, которые можно разместить в меню системы или в меню
раздела. С помощью страниц создаются ролевые интерфейсы, на них
можно разместить быстрые действия и необходимую для роли
информацию;
o виджетов, которые можно разместить на форме элемента
приложения или процессной задачи, на странице;
 Бизнес-процесс предназначен для исполнения процессов в системе.
 Группы и роли помогают связать ролевую модель с функциями системы;
 Нумераторы используются для формирования последовательных номеров
по заданным правилам;
 Контракт позволяет объединить несколько приложений единой
функциональностью;
 Шаблоны документов позволяют генерировать файлы по шаблону;
 Дополнительные параметры позволяют изменять настройки в одном
месте, не внося изменения в функционал всего решения;
 Портал позволяет вовлечь внешних пользователей в бизнес-процессы
компании;
 Модуль позволяет расширить функционал системы:
o виджетами — увеличивают набор виджетов в дизайнере
интерфейсов;

o действиями в бизнес-процессе — позволяют увеличить набор

элементов в дизайнере бизнес-процессов;
o переносимыми сервисами — расширяют систему функциями,
реализованных в отдельных микросервисах;
o обработчиками — позволяют выполнять действия при наступлении
событий в системе;
o методами — для реализации интеграции со сторонними системами.
3.1. Раздел
Раздел размещается в левом меню системы и объединяет в себе приложения,
страницы, контракты и бизнес-процессы. Раздел реализует функционал для
обеспечения работы одного подразделения или реализации бизнес-задачи.
Подробнее о разделе и работе с ним читайте в справке.
Например, в организации могут быть разделы Рекрутинг, IT, Бухгалтерия.

Функционал этих разделов будут ограничен, по большей части, этими бизнес-
единицами. Раздел Рекрутинг объединит в себе следующие приложения:
 Заявки на вакансии;
 Кандидаты;
 Собеседования.
Этим разделом будут пользоваться специалисты по подбору персонала, их
руководитель, HR-директор, а также руководители организации, которые являются
заказчиками вакансий.
Раздел «Рекрутинг»

3.2. Приложение
Приложение помогает организовать хранение данных и работу с ними.
Приложение бывает нескольких типов:
 Стандартное;
 Событие;
 Документ.
Тип приложения влияет на форму его отображения и стандартный набор полей.
Подробнее о приложении читайте в справке.
Элемент приложения — это карточка на странице приложения, которая

создаётся пользователями и хранит в себе внесённые ими данные. Например,
приложение Отпуск используется для хранения данных об отпусках сотрудников.
Каждый отпуск, добавленный в приложение, и будет являться его элементом.
3.2.1. Стандартное приложение

Может быть использовано для хранения справочных данных или аккумуляции
информации по какому-то объекту системы. И в том и другом случае будет
использовано приложение.
Например, справочник регионов. В нём достаточно хранить информацию с

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

Приложение «Регионы»
Для приложения со справочными данными чаще всего достаточно настроить

контекст приложения и права доступа.
Контекст — это описание структуры хранения. Он определяет, какие именно данные могут
храниться в приложении. Например, Дата начала, Дата окончания отпуска и Сотрудник,
который идёт в отпуск. Контекст приложения задаётся в типизированном виде, то есть для
каждого поля в контексте приложения указывается тип данных. От типа данных зависит
доступный пользователю способ заполнения и формат хранения в базе данных. Например, когда
мы говорим о вводе даты, мы представляем её выбор в календаре, а не ручной ввод с
клавиатуры. Поэтому для полей Дата начала и Дата окончания мы будем использовать тип
данных Дата/время.
В зависимости от занимаемой должности или роли у сотрудников могут быть различные

права доступа к одному и тому же приложению. Например, сотрудник отдела продаж сможет
создавать, редактировать и просматривать только свои отпуска, а сотрудник отдела кадров —
отпуска всех сотрудников компании.
По умолчанию, все новые приложения доступны группе Все пользователи. Но доступ можно
ограничить:
На уровне приложения — при выборе этой опции настройки доступа будут применяться ко
всем элементам данного приложения.
На уровне папок приложения — при настроенном иерархическом справочнике доступ

можно задавать отдельно для папок приложения.
На уровне элементов приложения — пользователи смогут задавать права доступа

отдельно для каждого элемента приложения. Также в качестве объекта для назначения прав
доступа можно будет указать автора элемента приложения.

Для приложений, аккумулирующих информацию по объектам системы, требуется

более тонкая настройка:
 специальные формы создания, изменения и просмотра;

 права доступа, зависящие не только от роли пользователя, но и от
параметров самого приложения;
 статусы, которые будут отражать состояние приложения;
 кнопки, которые будут выполнять определённые действия с приложением;
 веб-формы, для получения элементов приложения с сайтов.
Например, приложение Сотрудник аккумулирует в себе всю информацию о
сотруднике организации и историю взаимодействия с ним:
 трудоустройство;
 все кадровые документы;
 переводы;
 увольнение.
Информации очень много, поэтому форма требует тщательной проработки и
распределения информации по разным вкладкам. Кроме самой формы, добавляются
действия с сотрудником, которые могут совершить специалисты кадровой службы:
 изменить данные сотрудника;

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

Форма просмотра элемента приложения «Сотрудник»
3.2.2. Событие
Приложение типа Событие имеет дополнительный способ отображения в виде
календаря и используется для хранения информации о событиях. У События есть
дополнительные системные поля:
 Дата начала;
 Дата завершения;
 Участники.
Это позволяет использовать такой тип приложений, как события в календаре,
дополняя их необходимой информацией.
Например, приложение Собеседование можно дополнить следующей

информацией:
 Кандидат, который придет на собеседование;

 Вакансия;
 Резюме кандидата.
Такое приложение даст всю необходимую информацию специалисту кадровой
службы на собеседовании.
Форма просмотра элемента приложения «Собеседование»

Форма просмотра приложения «Собеседование»
3.2.3. Документ
Приложение типа Документ используется для работы с документами. По
умолчанию в нём есть поле типа Файл, которое позволяет:
 загружать документы;
 хранить версии документов;
 согласовывать их;
 подписывать документы в электронном виде.
Например, документами будут Трудовой договор и Дополнительное
соглашение к нему.

Форма просмотра приложения «Трудовой договор»
3.3. Интерфейс
Интерфейс предназначен для создания:
 страниц, которые можно разместить в меню системы или в меню раздела;

 виджетов, которые можно разместить на форме элемента приложения или
процессной задачи, на странице.
Подробнее о создании интерфейсов читайте в справке.
3.3.1. Страница
Страница предназначена для создания ролевых интерфейсов, на ней можно
разместить быстрые действия и необходимую для роли информацию. Страницу
можно поместить в меню системы или в меню раздела. Страница создаётся из
виджетов.
Например, ролевая страница для специалиста кадровой службы с информацией

о недавно принятых сотрудниках и последних кадровых документах.

Страница раздела КЭДО для сотрудника отдела кадров
3.3.2. Виджет
Виджет используется для отображения информации. В системе есть
предустановленные виджеты, а также реализована возможность создавать
пользовательские виджеты.
Все виджеты для удобства сгруппированы по смыслу:
 Размещение элементов — виджеты в этой группе позволяют размещать информацию

на вкладках, в колонках, в меню и на панелях;
 HTML-виджеты позволяют использовать HTML-код для отображения информации;
 Простые виджеты позволяют вывести кнопку или надпись;
 Виджеты отчётов позволяют вывести информацию в виде графика, диаграммы или

таблицы;
 Виджеты системных разделов, которые используются в них. Например, План проекта

в разделе Проекты;
 Виджеты для работы с данными, которые помогают отобразить данные, хранящиеся

в системе. Например, Лист согласования документа;
 Виджеты для страниц помогают организовать информацию на странице: вывести

заголовок или её содержимое;

 Виджеты для внешнего портала помогают организовать его интерфейс для внешних
пользователей: вывести доступные на портале страницы или заголовок с логотипом
и информацией о пользователе;
 Другие виджеты.
Виджетом может быть ввод даты с подсказками из сервиса DaData или

отображение существующей в системе информации в особенном формате.
Форма создания элемента приложения «Контрагенты» с виджетом DaData
С помощью виджета можно вывести данные системы в особенном виде. Например

штатное расписание может формироваться из приложений Организация,
Подразделение и Должность.

Страница с виджетом Штатное расписание в КЭДО
3.4. Бизнес-процесс
Бизнес-процесс как элемент конфигурации позволяет смоделировать
исполняемый процесс. Бизнес-процессы помогают выстраивать взаимосвязанные
цепочки автоматических и пользовательских операций. Подробнее о бизнес-
процессах читайте в справке.
Процесс может быть инициирован:
 вручную пользователем;
 по таймеру;
 из другого процесса с помощью элемента Подпроцесс;
 из внешней системы через автоматически сгенерированное API;
 после создания элемента приложения.
У бизнес-процесса есть:
 Графическая модель (схема) — описывает логику движения по процессу;

 Контекст — данные, которые движутся и дополняются по ходу процесса;
 Формы — пользовательские интерфейсы задач процесса;
 Сценарии — вызываются по ходу движения процесса или на формах задач
процесса;
 Настройки.

Схема бизнес-процесса создаётся из готовых элементов Дизайнера бизнес-

процесса. В нём можно найти основные элементы нотации BPMN 2.0 и
дополнительные элементы, которые упрощают работу с данными в системе.
Например, элемент получения руководителя инициатора бизнес-процесса.
Подробнее о дизайнере бизнес-процессов и его элементах читайте в справке.
Схема бизнес-процесса согласования отпуска в дизайнере бизнес-процессов

может выглядеть так:
Бизнес-процесс «Согласование и оформление отпуска»
3.5. Группы и роли

Группы и роли помогают связать ролевую модель с функциями системы. С
помощью них вы можете:
 объединить пользователей в группы;

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

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

роль можно создать группу Сотрудники кадрового делопроизводства. Этой группе

назначаются права доступа для ввода новых сотрудников, их трудоустройства и
перевода между подразделениями.
3.6. Нумераторы
Нумераторы позволяют генерировать последовательные номера для элементов
приложения по заданным правилам. Их обычно используют для формирования
названия элемента приложения по шаблону с указанием порядкового номера, а также
для получения регистрационного номера документа. Подробнее о нумераторах
читайте в справке.
Пример нумератора для получения номера входящего письма.
Нумератор для входящего письма
3.7. Контракт
Контракт в определённом смысле реализует принцип наследования и позволяет
объединить несколько приложений в единый интерфейс. Используя контракт, можно
настраивать общую для приложений функциональность. Подробнее о контрактах
читайте в справке. У контракта есть:
 Приложения источники — это те приложения, которые объединяются в

контракт;
 Поля — это общий контекст, которые есть у всех приложений источников;
 Права доступа — по аналогии с правами доступа в приложении.
Например, приказ на отпуск и приказ о приёме на работу — это разные документы
со своими шаблонами и контекстом. Они могут быть реализованы в системе через

отдельные приложения типа Документ, каждое со своими формами и бизнес-

процессами. Но у них есть и общая часть — это процедура подписания:
1. Если внутри компании осуществляется электронное взаимодействие и

сотрудник соглашается с таким форматом, то сначала работодатель
подписывает документы электронной подписью, а затем их подписывает
сотрудник;
2. Если сотрудник не перешёл на электронное взаимодействие с
работодателем, то документы в том же порядке подписываются на бумаге.
Чтобы не делать отдельные процессы подписания для каждого документа, можно
объединить их в единый контракт Кадровые документы. Для этого контракта можно
реализовать бизнес-процесс Подписание кадровых документов, в котором
настроить необходимую цепочку действий. Таким образом, с помощью контракта
можно реализовать общую функциональность для разных приложений.
Контракт «Кадровые документы»
3.8. Шаблоны документов

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

Например, для автоматического формирования договора можно использовать

шаблон, в который система подставит данные.
Шаблон договора
3.9. Дополнительные параметры

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

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

Дополнительный параметр «Стандартный размер суточных»
3.10. Портал
Портал позволяет реализовать интерфейс взаимодействия с системой для
внешних пользователей. Подробнее о портале читайте в справке.
Внешними пользователями могут быть:
1) клиенты, которые могут оставить заявку в службу поддержки, получить

коммерческое предложение и обменяться документами;
2) поставщики, которые предоставляют обновленные прайсы и участвуют в
закупках;
3) сотрудники, которые взаимодействуют с общим центром обслуживания по
кадровым вопросам.
Например, портал поставщиков, на котором можно разместить текущие
закупочные процедуры, где поставщики смогут оставить свои предложения для
участия в процедуре. Или портал сотрудников, где каждый сотрудник организации
может получить информацию о количестве оставшихся дней отпуска, узнать даты
своего отпуска по графику, перенести его или оформить отгул.

Портал КЭДО
3.11. Модуль
Модуль позволяет расширить функциональность системы:
1) виджетами — создать свои виджеты и использовать их в других виджетах,

на страницах и формах;
2) действиями в бизнес-процессах — создать свой элемент бизнес-процесса;
3) обработчиками — позволяют выполнять действия после появления каких-
либо событий в системе;
4) методами для реализации интеграции со сторонними системами;
5) Переносимыми сервисами (для On-Premises) — расширяют функционал
системы отдельным микросервисом, могут быть написаны на любом языке
и использовать сторонние библиотеки.
Подробнее о модулях читайте в справке.
Например, для полноценной автоматизации кадрового документооборота

необходима интеграция с учётной системой, которую можно реализовать через
модуль. У такого модуля будут свои настройки:
 адрес подключения к учётной системе;

 учётная запись и пароль.

Настройка модуля интеграции с 1С
При необходимости можно расширить настройки интеграционного модуля

дополнительными параметрами, например:
 перечнем передаваемых документов;

 частотой синхронизации и т. п.
В самом модуле будут реализованы:
 действия в бизнес-процессах, чтобы аналитики при моделировании могли

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

Действия в бизнес-процессе в модуле

Как использовать элементы платформы
Глава 4. Как использовать элементы

платформы
В этой главе разобраны способы реализации ключевых сценариев с помощью
элементов платформы, необходимых при разработке решений.
4.1. Работа с данными
4.1.1. Хранение данных

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

Для взаимодействия пользователя с данными используйте:
1) формы приложений и их элементов;

2) формы задач бизнес-процессов;
3) страницы.
Все формы, страницы и виджеты могут быть настроены с помощью дизайнера
интерфейсов.
Формы приложений и их элементов

Существует несколько видов отображения приложений:
 Плитка — просмотр элементов приложений в общем списке в виде плиток;

 Таблица — просмотр элементов в табличном виде;
 Канбан — просмотр элементов по статусам. Такой вид отображения
доступен только тогда, когда у приложения включена опция Поле статус.
 Календарь — просмотр событий в календаре. Такой вид отображения
доступен только для приложений типа Событие.
Для вида отображения приложений есть своя настройка. Например, можно
настроить поля приложения, которые будут отображаться на плитке или в таблице.
Для элемента приложения можно настроить свою форму для каждого вида
действия:
 форма создания элемента;

 форма редактирования элемента;

 форма массового редактирования элементов;

 форма просмотра.
На страницу приложения и форму элемента приложения можно добавить
дополнительные действия, используя Кнопки. Например, на форму просмотра
элемента можно добавить кнопку Создать копию, с помощью которой скопируется
значение полей и создастся новый элемент.
Формы задач бизнес-процессов

Формы задач бизнес-процесса настраиваются с помощью дизайнера
интерфейсов, а действиями для них будут Переходы на схеме бизнес-процесса.
Переходы в пользовательской задаче отобразятся в виде кнопок. Если необходимо
дать пользователю дополнительное действие, не выходя из задачи, воспользуйтесь
виджетом Кнопка на форме задачи и настройте действие, которое она будет
выполнять.
Страницы
Страницы можно использовать как ролевой интерфейс для сотрудников.
Например, можно создать страницу для сотрудников отдела подбора персонала. На
неё вывести план по подбору персонала и текущее состояние.
4.1.3. Доступ к данным

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

конфиденциальность данных. Например, вы можете предоставить доступ к разделу
Рекрутинг, только для руководителей организации, сотрудников по подбору
персонала и их руководителя. При этом каждый руководитель, который является
инициатором новых вакансий, сможет видеть только те вакансии, которые он создал.
А сотрудники по подбору персонала и их руководитель будут иметь доступ ко всем
вакансиям.
Кроме этого, можно дать доступ к элементам приложения по группам подбора.

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

4.1.4. Бизнес-процессы — движение данных

Для автоматизации бизнес-процессов в организации используйте элемент
платформы Бизнес-процессы. Моделирование бизнес-процессов осуществляется с
помощью графических элементов, среди которых есть:
1. стандартные элементы нотации BPMN. Например, события, переходы,

задачи, подпроцессы и т. п.;
2. дополнительные элементы, позволяющие выполнять частые операции без
программирования. Например, создание элемента приложения, изменение
статуса, генерация документа и т. п.
Если вам необходимо выполнить какую-то операцию в бизнес-процессе, но вы не
нашли для неё готового графического элемента, то вы можете:
 воспользоваться элементом Сценарий и с помощью программного кода

реализовать эту операцию. Такой подход подойдёт для разовых операций;
 создать Действие в БП через Модуль, расширив перечень элементов
дизайнера бизнес-процессов. Такой подход подойдёт для
переиспользуемых операций.
4.1.5. Обработка данных

Обрабатывать данные в системе можно при помощи разных элементов. Ниже
приведены типовые сценарии обработки данных и способы их реализации.
Обработка данных по событию

Создание элемента приложения
Если вам необходимо выполнить автоматическую операцию или запустить

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

уровень приложения, а их обработка — это бизнес-процесс. Свяжем бизнес-процесс
обработки заказа с приложением. Теперь, когда пользователь создаст заказ, система
автоматически запустит бизнес-процесс его обработки.

Изменение статуса элемента приложения
Если в рамках выполнения бизнес-процесса вам необходимо дождаться перехода

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

отправить документ в систему ЮЗДО контрагенту и после получения информации о
подписании этого документа уведомить ответственного менеджера.
Для реализации такой задачи потребуется бизнес-процесс согласования и

подписания документа, а также модуль интеграции с ЮЗДО.
Разберём, как настроить взаимодействие:
1. Инициатор запускает бизнес-процесс, проходит этапы согласования и

подписания. После этого документ отправляется в систему ЮЗДО, и бизнес-
процесс останавливается на элементе Ожидание смены статуса.
2. Модуль интеграции с ЮЗДО работает независимо от бизнес-процесса и
периодически получает информацию о документах, обновляет их статусы.
3. Как только статус документа изменится на необходимый, бизнес-процесс
продолжит свою работу и отправит уведомление ответственному менеджеру о
том, что документ подписан.
Элемент Ожидание смены статуса следует использовать в бизнес-процессе в том случае,

если вам необходима непрерывная обработка одного элемента приложения в рамках одного
экземпляра бизнес-процесса.
Обработка данных по любым событиям
Если необходимо выполнять автоматические операции после возникновения

какого-то события в системе, воспользуйтесь обработкой событий в модуле. Она
позволяет выполнить сценарий или запустить бизнес-процесс сразу после
наступления события. Доступные события описаны в справке.
Например, чтобы уведомлять администратора системы об изменении

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

Регулярная обработка данных

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

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

Для обработки данных в бизнес-процессе используйте готовые элементы
дизайнера или сценарии.
Чтобы сохранить модульность решения и переиспользовать такие обработки:
1) реализуйте в модуле метод, который можно вызывать из сценариев бизнес-

процесса и сценариев интерфейсов. При необходимости внесите изменения в
метод: достаточно сделать это только в модуле.
2) реализуйте элемент дизайнера бизнес-процессов со своей логикой, для этого
создайте Действие в БП в модуле.
4.2. Хранение настроек

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

Дополнительные параметры позволяют хранить значения констант. С такими
параметрами можно работать в сценариях бизнес-процессов, сохраняя при этом
возможность изменения этих настроек через пользовательский интерфейс.

Например, нам нужно рассчитать размер суточных на основании длительности

командировки. Размер суточных принят в компании за X рублей и ни от чего не
зависит.
Длительность командировки — величина непостоянная и зависит от дат

конкретной командировки. Она будет храниться в контексте бизнес-процесса
Оформление командировки или в контексте приложения Командировка.
Размер суточных пока постоянный, но есть вероятность, что его могут изменить.
Чтобы администратор в дальнейшем мог менять его через интерфейс, не используйте
константу внутри сценария бизнес-процесса, а создайте дополнительный параметр
для его хранения.
4.2.2. Настройки модуля

Вы можете добавить параметры для настройки модуля.
Например, при реализации модуля интеграции с учётной системой нужно где-то

хранить параметры подключения к ней. Эти параметры можно вынести в настройки
модуля. В testing-среде в настройках модуля вы можете указать адрес для
подключения, логин и пароль от тестового сервера учётной системы.
4.2.3. Приложение
Если настройки необходимо хранить списком в разрезе каких-то элементов,
используйте приложение. В его контексте вы можете связать элементы другого
приложения с набором необходимых параметров.
Например, необходимо рассчитать размер суточных на основании длительности

командировки. Размер суточных зависит от места назначения. Так, для командировок
в Москву и Санкт-Петербург размер суточных — X рублей, а для остальных городов
России — Y рублей.
Чтобы хранить суточные для Москвы и Санкт-Петербурга, создадим приложение

Суточные по городам. В нём сделаем ссылку на элемент приложения Город и будем
хранить сумму суточных для него. Размер суточных «по умолчанию» (Y рублей) будем
хранить в дополнительных параметрах. В сценарии получения размера суточных
реализуем простую логику:
1) установить место назначения командировки;

2) найти его в приложении Суточные по городам:
a. если нашли, установить размер суточных;

b. если не нашли, получить размер суточных по умолчанию из

дополнительных параметров.
4.3. Интеграция
Для интеграции с другими системами используйте модули.
Модуль позволяет:
 создать настройки подключения к системе;

 создать новые элементы для дизайнера бизнес-процессов, чтобы
интеграцию было просто встроить в бизнес-процессы компании;
 создать методы для Web API, которые будут вызываться из интегрируемой
системы. Перед созданием методов проверьте, возможно, вам подойдут
уже существующие.
4.4. Хранение шаблонов документов

Для генерации печатных форм документов в системе используются шаблоны
документов. В зависимости от решаемой задачи способ хранения этих шаблонов
может отличаться.
4.4.1. Один шаблон на документ

Если для одного документа вы используете один шаблон для генерации, то
разместите его в приложении и выберите в бизнес-процессе в элементе Генерация
по шаблону.
Например, в организации для генерации приказа на материальную помощь

используется один шаблон. Он не зависит ни от каких параметров и всегда один.
4.4.2. Несколько шаблонов на документ

Если для одного типа документов используется несколько шаблонов, разместите
их в разделе Администрирование — Шаблоны документов или в отдельном
приложении.
Например, несколько дополнительных соглашений к трудовому договору требуют

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

Если необходимо генерировать договор, шаблон которого зависит от

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

Если для решения задачи необходимо подключить в систему стороннюю
библиотеку, можно использовать:
 сценарии в виджетах для подключения .js-библиотек, работающих в

браузере;
 собственные микросервисы для подключения любых библиотек (для On-
Premises).
4.5.1. Подключение .js-библиотек

В клиентских сценариях виджета можно обращаться к функциям библиотек,
написанных на языке JavaScript. Подключение такой библиотеки может
потребоваться для реализации сложных интерфейсов. Например, для визуализации
дерева с отображением структуры данных или для карусели картинок.
Чтобы подключить библиотеку, перейдите в дизайнере интерфейсов на вкладку

Файлы. Загрузите один или несколько файлов в формате .js. На вкладке Сценарии
в исходном коде скрипта подключите добавленные файлы с помощью инструкции
import.
Например, чтобы подключить библиотеку jQuery, перейдите на вкладку Файлы и

загрузите файл с актуальной версией библиотеки, например, jquery-3.6.0.min.js.
Перейдите на вкладку Сценарии в раздел клиентских сценариев и в начале сценария
добавьте инструкцию:
import $ from "jquery-3.6.0.min.js";
Теперь в коде сценария можно обращаться к функциям библиотеки.

4.5.2. Подключение любых библиотек On-Premises

Чтобы подключить любую библиотеку, воспользуйтесь возможностью создания
микросервиса и его подключения к модулю. Подробнее о собственных микросервисах
расскажем в следующем разделе.
4.6. Создание микросервиса On-Premises

Вы можете создать свой сервис и разместить его внутри оркестратора MicroK8S.
Это позволит расширить функциональные возможности системы. Например, можно
создать сервис для работы с файлами .xlsx. Он будет считывать строки и сохранять
их в приложения.
Создавать свой сервис нужно тогда, когда без него нельзя решить задачу.
Сценарии использования сервиса:
 реализация интеграции с внешней системой через непопулярные

интерфейсы. Например:
o интеграция с 1С через COM-Connector;
o интеграция напрямую с базами данных, например, Oracle;
 реализация сложных вычислений, например, распознавание документов;
 подключение библиотек, например, использование библиотеки Aspose для
работы с файлами MS Office в сценариях;
 сервис может быть написан на любом языке программирования, для
развёртывания его внутри ELMA365 требуется только Docker-образ.
Ознакомиться с детальным примером создания и подключения сервиса можно в
справке.

Уровни изоляции и обновление решений
Глава 5. Уровни изоляции и обновление

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

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

экспорта. Поэтому вы столкнетесь с ней в момент экспорта разработанного
функционала из среды разработки, для дальнейшего импорта в среду тестирования
или в продакшн. Подробнее о средах и организации разработки описано в главе
«Организация процесса разработки».
Изолированное решение означает, что у него нет связей с другими функциями

системы и оно может легко экспортироваться из одной среды и импортироваться в
другую.
В системе существует несколько типов выгружаемых и устанавливаемых пакетов.

Каждый тип соответствует уровню изоляции:
1. Приложение (namespace.app) — атомарный тип пакета. Содержит только одно

приложение и все, что с ним связано.
2. Раздел (namespace) — набор приложений и процессов. Раздел как правило

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

API. В модулях создаются переиспользуемые сущности, которые можно
применять в разных приложениях, интерфейсах, процессах. Другой ключевой
сценарий использования модулей — это создание интеграций и подключение
внешних систем/сервисов.
4. Решение (solution) — тип пакета для единовременной выгрузки одного или

нескольких разделов и модулей.

5. Конфигурация (global) — все разделы, модули, оргструктура и другие сущности

на уровне компании.
Элементы платформы и уровни изоляции

5.1. Изоляция на уровне приложения

Изоляция на уровне приложения содержит само приложение и всё, что с ним
связано. При экспорте приложения выгружаются:
 контекст приложения;
 интерфейсы на уровне приложения — формы и виджеты;
 настройки приложения, например, настройка названия элемента
приложения;
 бизнес-процессы;
 нумераторы;
 дополнительные параметры;
 шаблоны;
 веб-формы;
 группы и роли.
Изоляция на уровне приложения при решении бизнес-задач чаще всего не
используется, так как одного приложения для решения задачи обычно недостаточно.
Но изоляция на уровне приложения используется «под капотом», когда вы
экспортируете решение, в составе которого есть приложение из системного раздела.
Приложение из системного раздела включается в состав решения на этом уровне
изоляции.
5.2. Изоляция на уровне раздела

Изоляция на уровне раздела содержит раздел и всё его содержимое. При
экспорте выгружаются:
 приложения, и всё, что с ними связано;

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

5.3. Изоляция на уровне модуля

Изоляция на уровне модуля содержит модуль и всё его содержимое. При экспорте
выгружается целиком.
Используется в двух случаях:
1. Когда модуль самостоятельный. Рассмотрим пример интеграции с

телефонией, в которой реализуется системная точка расширения. В нём
необходимо настроить только подключение к телефонии, но не нужно
выполнять дополнительные настройки для встройки этого модуля в
решение.
2. Когда модуль универсальный. Например, интеграция с учётной системой, в
которой реализуются действия для бизнес-процессов. Эти действия можно
встроить в любой бизнес-процесс, но это потребует дополнительных
настроек для встройки модуля в решение.
5.4. Изоляция на уровне решения

Изоляция на уровне решения содержит разделы и модули, включённые в его
состав. В него могут быть добавлены:
 разделы со всем содержимым;

 модули со всем содержимым;
 приложения из системных разделов.
Такой уровень изоляции более предпочтителен для комплексных решений, в
состав которых будут входить и разделы с приложениями, и модули, которые уже
интегрированы в бизнес-логику решения. Кроме этого, изоляция на уровне решений
поддерживает зависимости от других решений. Это значит, что вы можете сослаться
на приложение из другого раздела, не входящего в решение. При этом другой раздел
должен быть включён в другое решение, тогда при экспорте будет возможность
установить зависимость.
5.5. Изоляция на уровне конфигурации

Содержит всю конфигурацию системы — все уровни изоляции, описанные выше,
оргструктуру, а также настройки реализованные на уровне компании. Например,
дополнительные параметры или группы. При экспорте выгружается в составе:
 всех разделов со всем содержимым;

 всех модулей со всем содержимым;

 бизнес-процессов на уровне компании;
 интерфейсов на уровне компании;
 шаблонов документов на уровне компании;
 групп и ролей на уровне компании;
 дополнительных параметров на уровне компании;
 оргструктуры.
Такой уровень изоляции подойдёт, если:
 разработка ведётся одним человеком и расширение команды не

планируется;
 разрабатывается только один контур и реализация других контуров не
планируется;
 в решении используется оргструктура;
 у вас уже есть решение, в котором нарушена изоляция и нет времени на его
рефакторинг.
5.6. Примеры
5.6.1. Кейс 1. Счёт

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

может быть таким:
1. Счета;
2. Контрагенты;
3. Назначения платежей;
4. Мои юридические лица.
Из указанных приложений два есть в системе всегда: CRM — Компании,
Системные справочники — Мои юридические лица. Для начала можно
использовать эти приложения, потому что на них можно ссылаться, не нарушая
изоляцию.

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

в этом кейсе лучше всего работать с разделом, с вытекающими экспортом, импортом
и обновлением именно раздела.
Всегда стоит учитывать будущие доработки. Например, могут добавиться новые

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

юридические лица:
 для этого будем использовать метод search();

 метод search() доступен из описания приложения;
 описание мы можем получить одним из двух способов:
o установив флажок Global и написав конструкцию типа
Global.ns._clients.app._companies.search();
o добавив в контекст страницы/приложения/процесса переменную
Компании с типом Приложение и написав конструкцию типа
Context.fields._companies.app.search().
Первый способ нарушит изоляцию, несмотря на то, что мы ссылаемся на
системное приложение. Это происходит потому, что в сценариях мы включили опцию
Global, которая не позволит экспортировать раздел.
Второй вариант не будет препятствовать экспорту, потому что опцию Global в

этом случае включать не понадобится.
Однако важно отметить, что если мы добавим в контекст приложение, которое не

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

В целом задача стоит такая же: автоматизация работы со счетами. Но в этом
кейсе нам также важно вести реестр платежей, чтобы оплачивать счета пачками.
Кроме того, при оформлении заявки на оплату необходимо указывать не только
контрагента и организацию, но и тип платежа, НДС, валюту, департамент, учётный
период и прочее. С валютами и НДС тоже есть особенность: заказчик работает с
контрагентами в разных странах, поэтому значения могут быть разными, а список
значений может меняться.

Не углубляясь в детальную архитектуру, становится очевидно, что будет много

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

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

настраивать доступ по группам пользователей, не ссылаясь на оргструктуру, чтобы не
нарушать изоляцию. Одним и тем же группам пользователей мы можем
давать/запрещать доступ на приложения в разных разделах.
Не имеет значения, где внутри решения будут созданы эти группы. Они также
могут использоваться, например, в оповещениях в бизнес-процессах, поэтому важно
использовать группы на нужном уровне изоляции.
5.6.3. Кейс 3. Большой проект

Если компания автоматизирует сразу несколько участков деятельности, над
проектом трудится команда специалистов, создавая сложную конфигурацию. Тогда
возникает вопрос, нужно ли экспортировать и импортировать конфигурацию целиком.
Как правило, конфигурация делится на контуры, а каждый контур может

реализовываться разделом или решением. В зависимости от методологии ведения
проекта результат может сдаваться по контурам или целиком. Над каждым разделом
или решением может работать отдельный человек или команда.
В таком случае рекомендуется иметь изолированные разделы, решения и модули:

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

глобальных групп, опция Global в сценариях. Поэтому можно руководствоваться
кейсами 1 и 2, чтобы избежать проблем при экспорте/импорте.
5.7. Как выбрать уровень изоляции

Выбирая какой уровень изоляции использовать для решения, опирайтесь:
 на размер команды, которая будет разрабатывать и развивать решение;

 на количество контуров, которые будут изменяться параллельно;

 на зависимость контуров друг от друга.
Чаще всего используется уровень изоляции на уровне разделов, модулей и
решений.
Рекомендации по выбору уровня изоляции в зависимости от размера команды

описаны в главе «Разработка решения командами разного размера».
5.8. Как сохранить изоляцию

Чтобы иметь возможность использовать оргструктуру и элементы платформы из
других разделов, но при этом сохранить изоляцию, следуйте следующим
рекомендациям.
5.8.1. Зависимости
При разработке решений вам может потребоваться приложение или бизнес-
процесс из другого раздела, но это нарушит изоляцию на уровне раздела. Чтобы
сохранить изоляцию, но использовать приложение, создайте два решения и добавьте
в него по одному разделу.
Изоляция на уровне решений поддерживает зависимости от других решений. Это

значит, что вы можете сослаться на приложение из другого раздела, не входящего в
это решение. При этом другой раздел должен быть включён в другое решение. Тогда
при экспорте будет возможность установить зависимость одного решения от другого.
Пример
Необходимо разработать функционал для HR-отдела: от подбора персонала и
найма до адаптации, обучения и увольнения. Запуск контуров будет
последовательный, но сроки сжатые, поэтому требуется вести разработку
параллельно.
Разбейте решение на контуры семантически:
1. Подбор персонала — вакансии, кандидаты, собеседования, офферы,

переход из кандидата в сотрудника;
2. Найм и увольнение — сотрудники, кадровые документы, штатное
расписание;
3. Адаптация и обучение — сотрудники, курсы обучения, аттестации, опросы
и т. д.

Для реализации трёх контуров из-за сжатых сроков потребуется подключить

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

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

справочники, в котором создайте все общие приложения. Затем создайте решение,
в составе которого будет только раздел Системные справочники.
Каждый контур следует реализовать решением: это позволит ссылаться на

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

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

бизнес-процессов и на уровне приложений и разделов для разграничения прав
доступа. Должности из оргструктуры добавляйте в группы и роли после импорта
разделов и решений в продакшн-среду. Это позволит вам сохранить изоляцию и
права доступа при перемещении сотрудников с должности на должность.
5.8.3. Интерфейс создания элементов приложений из других

разделов
Если вам необходимо создать единый интерфейс для пользователя, в котором в
составе разных решений будет организовано взаимодействие с приложениями,
используйте виджет Код.
В нём с помощью HTML-разметки можно отрисовать кнопки. Или, например, в тег

<a> вставить относительную ссылку на создание элемента приложения:

<a href="./(p:item/kedo/letter_of_resignation)">Оформить</a>
где:
 kedo — код раздела;

 letter_of_resignation — код приложения.
Такая реализация позволит нарисовать кнопку или ссылку Оформить в
интерфейсе. При нажатии на неё откроется форма создания элемента приложения. В
таком случае изоляция не нарушается, так как нет явной связи между разделами.
При использовании этого приёма вам придётся самостоятельно контролировать наличие

необходимых решений для их корректной работы.
5.9. Обновление решений

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

пакете и в целевой среде. Если в целевой среде изменения вносились вручную, то
при обновлении могут возникнуть конфликты. При обновлении происходит замена
существующих элементов платформы и добавление новых. Всё дополнительное не
удалится из среды, в которую импортируется решение.
Конфликт может быть двух типов:
1) уведомление с возможностью перезаписать конфликтующие элементы

конфигурации;
2) необратимый конфликт, который не позволит обновить решение.
Первый возникает, если вы внесли изменения на продакшн в существующие
элементы платформы в составе решения. Второй — если вы добавили элемент
платформы в решение вручную в среду разработки и также вручную на продакшн.

При разработке рекомендуется вносить изменения в решения только в среду разработки и

доставлять эти изменения в другие среды только с помощью процедуры импорта/экспорта или
утилиты для CI/CD.
5.9.1. Пример
Вы создали решение Управление договорами в среде разработки и перенесли
его в продакшн. В обеих средах есть идентичные решения.
Разберём пример решения со следующим составом:
 раздел Договоры:
o приложение Договор;
o приложение ДС к договору;
o бизнес-процесс Согласование договорных документов;
 модуль Интеграция с ЮЗДО:
o действие в БП Отправка документа;
o действие в БП Получение документа;
o бизнес-процесс Синхронизация статусов.
Рассмотрим разные варианты изменений и результат обновления со среды
разработки на продакшн:
 На продакшн добавили приложение Вид договора, в среду разработки —

приложение Тип договора.
Результат: при обновлении конфликта не возникнет, на продакшне будут оба
 На продакшн добавили приложение Вид договора, в среду разработки —
приложение Вид договора.
Результат: если их коды совпадают, то обновиться не получится; если коды
отличаются, то на продакшне будут оба приложения.
 На продакшне изменили форму приложения Договор.
Результат: при обновлении возникнет конфликт, и вы сможете:
o отменить обновление;
o перезаписать конфликтующие элементы.
Во втором случае форма приложения на продакшне заменится формой из
среды разработки, изменения будут утеряны.

 На продакшне создали новую форму для приложения Договор.

Во втором случае форма приложения на продакшне заменится формой из
среды разработки, но созданная форма сохранится и будет доступна для
выбора в настройках приложения.
 На продакшне изменили бизнес-процесс Согласование договорных

документов.
Во втором случае бизнес-процесс на продакшне заменится, изменения будут
доступны в предыдущей версии бизнес-процесса.
5.9.2. Если решение не обновляется

Если ваше решение не обновляется, воспользуйтесь следующими
рекомендациями:
 С организационной точки зрения: измените процедуру разработки и больше

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

Проектирование решения
Глава 6. Проектирование решения

Теперь разберёмся, как создать Low-code решение по требованиям заказчика.
Обычно их требования описывают не один процесс, настройку которого мы

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

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

ролей. Решение должно предоставить интерфейсы взаимодействия для каждой роли.
Например, интерфейсы взаимодействия с приложениями — это их формы, с бизнес-
процессами — формы задач.
Описав роли и их мотивы, мы сможем определить:
 перечень интерфейсов, с которыми они будут взаимодействовать;

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

Рассмотрим пример проекта автоматизации кадрового документооборота и

проектирование решения для него.
Цели:
 сократить расходы на бумажный кадровый документооборот;

 сократить время на подготовку, согласование и подписание кадровых
документов.
Задачи:
 перевести кадровый документооборот в электронный формат с

подписанием документов электронной подписью;
 автоматизировать процессы подготовки, согласования и подписания
кадровых документов.
Требования:
 создать личный кабинет сотрудника для взаимодействия с кадровой

службой;
 обеспечить возможность электронного подписания, а также бумажного в
случае, если сотрудник отказался от электронного взаимодействия;
 обеспечить приём, перевод, увольнение сотрудников;
 организовать работу с заявлениями сотрудников;
 организовать работу с отпусками;
 автоматизировать запрос справок, копий документов и дополнительной
информации (например, запрос количества дней отпуска);
 автоматизировать ЛНА и кадровые приказы;
 интегрировать целевую систему с учётной системой для передачи
информации о сотрудниках и документах.
Детализация требований на примере отпусков:
 обеспечить оформление отпуска по графику в соответствии с

законодательством;
 обеспечить оформление отпуска по заявлению;
 учитывать дни отпуска, начисленные за стаж и особые категории;
 в случае разделения отпуска подписывать с сотрудником согласие;
 рассчитывать длительность отпуска без учёта праздничных дней.

6.1. Ролевая модель решения
6.1.1. Роли
Всех пользователей решения опишем в виде ролей. Роль — это, например,
Согласующий, Бухгалтер или Менеджер по продажам. Ролью будет:
 участник бизнес-процесса, выполняющий отдельную функцию, например:

Инициатор, Руководитель инициатора, Согласующий, Подписант;
 бизнес-единица компании, использующая решение, например: Сотрудник
отдела кадров, HR-директор, Бухгалтер, Юрист, Генеральный
директор.
Опишем роли решения:
1. Сотрудник — любой сотрудник организации;

2. Руководитель — руководитель подразделения сотрудника;
3. Кадровый делопроизводитель — сотрудник отдела кадров;
4. Подписант — сотрудник, обладающий правом подписи кадровых
документов в организации сотрудника.
6.1.2. Мотивы
Для каждой роли определим её мотивы. Почему инициатор будет что-то делать?
И будет ли? Ответы на эти вопросы дадут понимание мотивов. Они помогут
реализовать такой интерфейс для взаимодействия с решением, который будет
достаточным и будет использоваться.
Случается, что у роли нет мотива взаимодействовать с решением, но это

взаимодействие важно для руководства организации. В таком случае необходимо
подумать о способах вовлечения роли во взаимодействие. Например:
 административно — приказом по организации;

 создать мотив для роли с помощью финансовой мотивации — привязать её
к показателям внутри решения.
Опишем мотивы для ролей:
1. Мотив сотрудника — зарабатывать деньги, для этого он трудоустроится на

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

образом, мотив сотрудника — воспользоваться кадровым сервисом в

организации максимально удобным способом;
2. Мотив руководителя — не отвлекаться от основной деятельности на
кадровый документооборот, но и не получить жалобу на его деятельность
от отдела кадров. Быть уверенным, что у сотрудников есть всё для
выполнения их работы и они не уйдут в отпуск в одно время, оставив
руководителя выполнять их задачи;
3. Мотив кадрового делопроизводителя — убедиться, что законодательство
соблюдается и в документах порядок;
4. Мотив подписанта — быть уверенным, что все документы согласованы, и
не тратить много времени на их подписание.
6.1.3. Сценарии взаимодействия

Далее рассмотрим сценарии взаимодействия роли с решением. Они описывают
точки контакта пользователя с системой.
Для роли Инициатор необходимо дать возможность быстро инициировать

бизнес-процесс, иметь актуальную информацию по ходу его движения и получить
результат его исполнения. Например, запустить договор на согласование, знать у кого
на согласовании он находится и получить подписанный договор.
Для роли Согласующий необходимо показать только то, что находится в его зоне
ответственности. Например, когда за разные пункты договора отвечают разные
подразделения, согласующему не нужно видеть весь текст договора, только часть, за
которую он отвечает. Кроме этого, ему нужна возможность получить экспертное
мнение от своего коллеги.
Опишем сценарии взаимодействия для ролей:
 Сотрудник:
o ознакомиться с документами приёма и подписать их;
o взять отпуск;
o посмотреть, согласован ли отпуск, и сумму отпускных;
o запросить пособие;
o узнать, сколько и когда начислят.
 Руководитель:
o согласовать отпуск;
o видеть отпуска сотрудников;
o знать, куда отправить сотрудника по кадровому вопросу.

 Кадровый делопроизводитель:
o трудоустроить сотрудника;
o контролировать этапы подготовки кадровых документов;
o найти документы по сотруднику;
o выгрузить документы сотрудника в архив.
 Подписант:
o подписать документ;
o найти нужный документ на подпись;
o подписать несколько документов.
6.2. Контуры решения

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

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

существующих систем. Сама по себе синхронизация пользователей не
несёт ценности, но является базой для реализации остальных контуров,
поэтому модуль синхронизации будет базовым техническим контуром;
 интеграция с 1С. На первом этапе решение может существовать без
интеграций, а на последующих этапах реализуются интеграционные
инструменты и встраиваются в существующее решение. Такой модуль будет
техническим контуром.
Контур решения может быть реализован и запущен в эксплуатацию отдельно от
других контуров, за исключением базовых технических контуров, без которых
невозможно реализовать важные требования к контуру решения. Первый контур
должен запускаться в эксплуатацию вместе с базовыми техническими контурами.
Технический контур становится базовым на основании специфики отрасли

решения, требований и приоритетов заказчика. Для одних интеграция с учётной
системой необходима сразу, а для других может подождать. Несмотря на то, что

контур — это отдельное мини-решение, он должен соответствовать требованиям,

предъявляемым к решению целиком.
6.2.1. Выделение контуров решения

Рассмотрим пример автоматизации кадрового документооборота. На основании
требований, описанных ранее, выделим явные контуры, которые решают бизнес-
задачи и объединяют функциональность по смыслу:
1. Приём, перевод, увольнение сотрудников — контур включает в себя

найм сотрудников, перевод между подразделениями и увольнения;
2. Отпуска — включает в себя подготовку графика отпусков, ознакомление с
графиком, перенос отпуска, уведомление о предстоящем отпуске;
3. Справки — включает в себя перечень доступных справок и процесс их
предоставления;
4. ЛНА — включает в себя подготовку, согласование, подписание ЛНА и
ознакомление сотрудников с ним.
За рамками этого списка остались требования, которые относятся ко всем или
нескольким контурам, указанным выше:
 Через личный кабинет сотрудники будут взаимодействовать с кадровой

службой как при трудоустройстве, так и при планировании отпуска,
ознакомлении с ЛНА и получении справки.
 Для приёма, переводов, увольнений, отпусков, ЛНА требуется возможность
электронного подписания.
 Для получения информации о существующих сотрудниках и обмена
кадровыми документами всем контурам необходима интеграция с 1С.
В связи с этим добавится ещё несколько технических контуров:
 Личный кабинет сотрудника будет базовым техническим контуром:

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

 Электронное подписание может быть как техническим контуром, так и

базовым техническим контуром в зависимости от приоритетности
требований;
 Интеграция с учётной системой может быть как техническим контуром, так
и базовым техническим контуром в зависимости от приоритетов.
Для решения автоматизации кадрового документооборота контурами будут:
 Технические контуры:
o Личный кабинет сотрудника;
o Модуль интеграции с 1С;
o Модуль электронного подписания.
 Приём, перевод, увольнение;
 Отпуска;
 Справки;
 ЛНА.
После разбивки решения на контуры необходимо детализировать сценарии
взаимодействия ролей по контурам. Детализируем сценарии для контура Отпуска:
 Сотрудник:
o запланировать отпуск на год;
o перенести отпуск;
o посмотреть, когда очередной отпуск;
o посмотреть, когда был отпуск в прошлом году;
o узнать, сколько дней отпуска осталось;
 Руководитель:
o согласовать график отпусков;
o видеть все пересечения в графике и иметь возможность внести
изменения;
 Кадровый делопроизводитель:
o контролировать этапы подготовки графика отпусков;
o видеть сотрудников, которые не ознакомились с графиком отпусков;
 Подписант:
o подписать документ;
o найти нужный документ на подпись;
o подписать несколько документов.

6.2.2. Состав контуров

Далее определим состав контуров решения и уровень изоляции. Какие именно
элементы платформы и уровень изоляции будут использоваться в решении. Чаще
всего контур реализуется на уровне изоляции раздела, модуля или решения. Это
позволяет реализовать необходимый функционал внутри контура и обеспечить его
изоляцию.
Разберём состав контуров решения автоматизации кадрового документооборота.
Личный кабинет сотрудника
Этот контур будет включать в себя основной интерфейс для сотрудника со всеми
кадровыми сервисами.
Для реализации личного кабинета нам потребуется:
1. Хранить информацию о сотрудниках и всё, что с ними связано, в

приложении Сотрудники.
2. Хранить информацию о штатном расписании в нескольких приложениях:
Организация, Подразделение, Должность. Для удобного отображения
потребуется отдельный интерфейс Штатное расписание, который будет
представлять информацию из этих приложений в виде иерархии.
3. Хранить справочную информацию в приложениях, например, Страны,
Регионы и Города.
4. Реализовать интерфейс для сотрудника, где он сможет воспользоваться
кадровыми сервисами. Технически это может быть страница для
сотрудников или внешний портал. В нашем примере мы будем
использовать портал, чтобы охватить максимум элементов платформы.
Состав контура:
1. Приложение Сотрудники;
2. Приложения для штатного расписания: Организация, Подразделение,
Должность;
3. Интерфейс Штатное расписание;
4. Приложения для справочных данных: Страна, Регион, Город и т. д.;
5. Контракт Кадровые документы;
6. Портал для сотрудников.
Уровень изоляции для контура: раздел в составе решения, так как от него будут
зависеть другие контуры.

Модуль интеграции с 1С
Функционал, закладываемый в модуль интеграции, будет зависеть от требований,

выбора мастер-системы и процесса взаимодействия двух систем.
Для нашего примера мы возьмём несколько сценариев:
1. Загрузка сотрудников из 1С;

2. Частичное обновление данных о сотрудниках, например, обновление
паспортных данных;
3. Создания кадровых документов;
4. Получения печатных форм.
1. Модуль интеграции с 1С:

a. Настройки подключения к 1С;
b. Бизнес-процесс Синхронизация сотрудников;
c. Действие в БП Обновление данных о сотруднике;
d. Действие в БП Создать документ;
e. Действие в БП Получить печатную форму по документу.
Уровень изоляции для контура: Модуль, входящий в состав Решения.
Модуль электронного подписания
Это готовый модуль, который уже есть в платформе, его не нужно разрабатывать,
мы просто используем его. При этом не нужно включать его в состав решения, т. к. он
входит в состав ELMA365 ECM. При этом наше решение будет зависеть от ELMA365
ECM.
Приём, перевод, увольнение
Контур, позволяющий нанимать, переводить и увольнять сотрудников. В нём

необходимо предусмотреть движение сотрудника по должностям, сохраняя
информацию о перемещениях. Этот контур плотно взаимодействует с сотрудником,
штатным расписанием и учётной системой.
1. Приложения типа Документ для трудового договора и дополнительных

соглашений;
2. Приложения типа Документ для приказов;
3. Приложения типа Документ для заявлений;

Организация процесса разработки
4. Бизнес-процессы для работы с документами.

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

оформлять отпуск за свой счёт, отпуск по нетрудоспособности и дополнительные
отпуска.
1. Приложение Отпуск;
2. Приложения типа Документ для отпусков: Приказ на отпуск, График
отпусков и т.п.;
3. Виджет График отпусков;
4. Бизнес-процессы для работы с отпусками.
Уровень изоляции для контура: Решение, так как требуется установить
зависимость от Решения с техническими контурами.
Справки и ЛНА
Эти контуры по своему составу и уровню изоляции будут похожи на контуры

Приём, перевод, увольнение и Отпуска.
После определения состава контуров и их взаимосвязи можно переходить к

созданию решения.
Глава 7. Организация процесса разработки
7.1. Роли в команде при разработке решений

В разработке решения участвуют разные роли:
 Заказчик — для кого создаётся решение, и кто формирует ключевые

требования к нему.
 Руководитель проекта — несёт ответственность за разработку решения в
срок и бюджет. Его задача — попасть в проектный треугольник, чтобы
Заказчик остался доволен.

 Архитектор — проектирует архитектуру решения на платформе ELMA365.

Его задача правильно применить платформу для решения задач
Заказчика, сохраняя расширяемость и поддерживаемость.
 Аналитик — выявляет и формулирует требования на основании
потребностей Заказчика и целей.
 Low-coder — настраивает систему с помощью Low-code инструментов.
 Разработчик — разрабатывает дополнительные модули к системе.
 Тестировщик — тестирует разработанный функционал.
 DevOps-инженер — обеспечивает инфраструктуру, развёртывание
системы в ней и её доступность.
 Технический писатель — отвечает за документацию решения.
7.2. Совмещение ролей

Роль — это не отдельный специалист в команде. В зависимости от объёма
команды и навыков специалистов в ней, один человек может исполнять функции
нескольких ролей.
7.2.1. Человек-оркестр
Разработкой решения может заниматься один человек, если:
 Решение состоит из одного контура или сроки на их реализацию позволяют

делать их последовательно и укладываются в возможности одного
человека;
 Пользователей решения не много, например:
o 1 заказчик;
o 2–3 ключевых пользователя;
o До 30-ти пользователей решения.
Совмещение ролей в человеке-оркестре

В таком подходе есть свои плюсы:
 Нет расходов на коммуникацию между ролями, так как они совмещаются в

одном человеке;
 Нет потери информации при передаче от одной роли к другой, так как
цепочка от потребителя решения до его разработчика короче;
 Время, потраченное на решение одной задачи меньше — имеются в виду
трудозатраты на реализацию, а не календарные сроки.
Но есть и минусы:
 Календарные сроки на реализацию решения будут больше, чем если бы это

решение делала команда из нескольких человек;
 Низкий bus factor: если человек-оркестр заболеет или уволится, разработка
решения не будет завершена в срок и может не завершиться вовсе. Так как
человек-оркестр обладает всеми знаниями о решении, которые чаще всего
нигде не фиксируются;
 Качество разрабатываемого решения непредсказуемо, т. к. зависит от
одного человека и не контролируется.
7.2.2. Команда: 3–7 человек

Такая команда подойдёт, когда:
 Решение состоит из нескольких контуров вокруг одной бизнес-задачи или

нужно реализовать несколько решений, а сроки позволяют реализовывать
их последовательно;
 Пользователей у решений будет больше, например:
o 1–5 заказчиков, т. к. решений может быть несколько;
o 5–15 ключевых пользователей;
o Тысячи пользователей решения.

Совмещение ролей в команде
Плюсы подхода:
 Часть знаний о решении документируется;

 Средний bus factor: если один из участников команды заболеет, решение не
будет под угрозой;
 Скорость на реализацию решения будет выше, так как работы могут вестись
параллельно;
 Качество решения предсказуемо.
Минусы:
 Появляются расходы на коммуникацию участников команды и

документирование;
 Могут быть потери информации при передаче от одной роли к другой;
 Время, потраченное на решение одной задачи, выше.
7.2.3. Большая команда или несколько команд

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

членами команды рекомендуется делиться на команды по 3–7 человек и
реализовывать ими отдельные бизнес-задачи или контуры. При этом важно, чтобы
над этими командами была единая система:
 Управления, чтобы команды шли к единой цели сохраняя эффективность;

 Архитектуры, чтобы в решениях сохранялся общий подход и команды не
изобретали велосипеды;
 Контроля качества, чтобы в результате у каждой команды был
предсказуемый результат;
 Документирования, чтобы знания о решении были формализованы в
едином формате.

Совмещение ролей в нескольких командах
Плюсы подхода:
 Знания о решении документируются;

 Высокий bus factor;
 Предсказуемое качество решения;
 Возможность параллельной разработки нескольких больших решений;
Но есть и минусы:
 Минусы те же, что для команды 3-7 человек;

 Срок на реализацию одного решения может быть ниже, чем у команды 3–7
человек, так как решения должны пройти через единую систему контроля
качества, архитектуры и документирования.

7.3. Разработка решения командами разного размера

В зависимости от объёма команды следует выбрать свой уровень изоляции и
окружения.
Под окружением здесь подразумевается инсталляция ELMA365. При разработке

решений используется несколько окружений:
 Develop — среда разработки решения;

 Testing — среда тестирования, на ней происходит функциональное
тестирование решения;
 Staging — среда тестирования обновления решения, на ней
разворачивается копия production и тестируется обновление;
 Production — среда, в которой решение используется конечными
пользователями.
7.3.1. Человек-оркестр
Если разработку ведёт один человек, то в практике встречается:
 Изоляция на уровне конфигурации;

 Разработка прямо в Production-среде.
Для возможности дальнейшего роста пользователей, решаемых задач и команды,
которая занимается разработкой, рекомендуем сразу начинать с:
 Изоляции на уровне разделов, модулей и решений;

 Использования двух сред:
o Develop — для разработки и тестирования изменений;
o Production — для пользователей;
 Перенос между средами через механизмы импорта/экспорта.
Наличие Testing и Staging сред в этом случае избыточно.
7.3.2. Команда: 3–7 человек

Для комфортной работы команды рекомендуется:
 Изоляция на уровне разделов, модулей и решений;

 Использование трёх сред:
o Develop для разработки;
o Staging для тестирования изменений и обновлений;
o Production для пользователей;

 Перенос между средами через механизмы импорта/экспорта или утилиту

для CI/CD.
7.3.3. Несколько команд

Для организации разработки нескольких команд рекомендуется:
 Изоляция на уровне разделов, модулей и решений;

 Использование четырёх сред:
o Develop отдельный для каждой команды или для каждого
разработчика;
o Testing для каждой команды или общий для всех;
o Staging общий для всех;
o Production для пользователей;
 Перенос между средами с помощью утилиты для CI/CD.

Документирование решений
Глава 8. Документирование решений

Ключевые потребители документации решения:
 Пользователи решения;
 Сотрудники поддержки, которые помогают пользователям работать с
решением;
 Администраторы, которые обеспечивают его доступность;
 Разработчики, которые его создали и развивают.
У каждого потребителя документации свои запросы. Например:
 Пользователям решения важно понять, как им взаимодействовать с

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

необходимый перечень документов для решения.
Бывает так, что документацию начинают писать в самом конце, когда решение уже
разработано и готовится к запуску в production-среде. Такой подход может создать не
мало проблем ещё в процессе разработки. Например, если один из участников
команды заболеет или уволится, важная информация о решении может быть
упущена. Поэтому рекомендуется своевременно формировать и обновлять
документацию, чтобы она не устаревала. Чем больше времени проходит от
изменения до документирования — тем больше трудозатрат потребуется на
актуализацию.
Перечень документов, которые могут быть сформированы по решению:

Документирование решений
1. Краткое описание решения: для чего оно и какие задачи решает. Такое
описание поможет любому потребителю быстро понять суть решения;
2. Настройка решения: как правильно настроить решение в начале и на что
влияют эти настройки;
3. Описание инфраструктуры: какие мощности используются для решения, как
контролировать его доступность и обслуживать сервера;
4. Инструкции по ролям — описание интерфейсов и сценариев
взаимодействия с решением для каждой роли;
5. Архитектура решения:
a. Состав решения — что в себя включает решение;
b. Взаимодействие элементов решения — как они взаимодействуют
между собой;
c. Возможности расширения решения — как правильно использовать
заложенные возможности расширения и дорабатывать
функциональность.

Оптимизация решений
Глава 9. Оптимизация решений

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

сотни тысяч записей ежедневно. Предположим, что обновление будет происходить за
несколько часов. Такой функционал можно реализовать фоновой операцией, которая
выполняется в нерабочее время. Несмотря на то, что обновление занимает часы —
это не критично, так как операция выполняется в нерабочее время и не влияет на
пользователей и правильную работу решения.
В другой ситуации это может быть критично, например, когда организация

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

Если вы в своём решении заметили длительную загрузку интерфейсов,
длительное выполнение сценариев или столкнулись с таймаутами — воспользуйтесь
рекомендациями ниже.
9.1.1. В интерфейсах
Воспользуйтесь вкладкой Network в инструментах разработчика в браузере и
обратите внимание на:
1. Количество синхронных запросов;

2. Время выполнения этих запросов.

9.1.2. В сценариях
Измерьте время выполнения сценария с помощью фиксации времени начала и
окончания.
9.2. Рекомендации
Пользователь взаимодействует с интерфейсом в режиме реального времени,
поэтому неоптимальная реализация заметнее именно здесь.
При настройке форм и интерфейсов:
1. Группируйте свойства и виджеты на формах во вкладки и панели — это

поможет пользователю проще ориентироваться в информации;
2. Используйте флаг Загружать содержимое асинхронно на вкладках и
панелях, чтобы не ждать загрузки всех вложенных виджетов при открытии
формы. Так пользователь быстро получит доступ к форме с основной
информацией, а остальные данные загрузятся позже автоматически или по
запросу пользователя;
3. Используйте пагинацию при работе с большим количеством элементов;
4. Поставьте флаг Поиск и сортировка по полю для полей приложений,
которые чаще всего используются при поиске. Но и не устанавливайте этот
флаг на все поля, так как при его установке создаются индексы в базе
данных.
При написании сценариев:
1. Откажитесь от серверных сценариев на формах, виджетах и интерфейсах

там, где это возможно. Клиентские сценарии выполняются прямо на
устройстве пользователя без обращения к серверу, поэтому занимают
меньше времени;
2. Если вы используете серверные сценарии в нескольких виджетах, которые
потом будут использованы на одной форме, виджете или интерфейсе, то
лучше откажитесь от нескольких виджетов в пользу одного. Иначе
серверные сценарии из каждого виджета будут исполняться
последовательно, что увеличит время выполнения;
3. При загрузке данных используйте фильтры, а не загружайте их целиком;
4. Объединяйте все await в Promise.all(). Это позволит выполнить запросы
параллельно, а не последовательно. Делайте это только тогда, когда
параллельное выполнение не нарушит бизнес-логику;

5. При работе с данными в цикле используйте Promise.all(). Это позволит

обработать все изменения параллельно, а не последовательно. Подробнее
об этом в TSSDK.
6. Объедините несколько последовательных сценариев в бизнес-процессах в
один, так они будут выполняться быстрее.
При настройке запуска бизнес-процессов по таймеру учитывайте существующие
фоновые операции и время их выполнения. Рекомендуется определить доступное
время запуска для таких операций и разнести их по времени в этом интервале, чтобы
они не мешали друг другу.
9.3. ON-PREMISES Высоконагруженные решения

Если ваше решение работает с большим объёмом данных или пользователей, то:
1. Разместите postgres и mongo на отдельных серверах с SSD;

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

Пять принципов хорошего решения
Глава 10. Пять принципов хорошего решения
10.1. Хорошее решение — какое оно?

Прежде чем создать хорошее решение нужно понять, хорошее — это какое?
10.2. 5 принципов
Ниже описаны ключевые принципы, которыми стоит руководствоваться при
создании решения.
10.2.1. Решает проблему заказчика

Прежде чем что-то решать, надо понять проблему. Например, автоматизация
документооборота — это не проблема, а задача. Проблема кроется глубже и для
коммерческих организаций считается в деньгах:
 Проблема либо создаёт убытки;

 Либо сокращает доходы.
Часто способ решения проблемы находится клиентом самостоятельно или с
помощью консультантов, так появляются задачи автоматизации.
«Зачем знать первичную проблему, если кто-то уже нашёл решение и спустился
на уровень задач?» — спросите вы. Чтобы выбрать оптимальный путь решения
задачи, который приведёт к достижению цели.
Оптимальный — приносящий максимальную пользу за минимальный бюджет.
Рассмотрим пример задачи: автоматизировать основной бизнес-процесс

предприятия.
Выясняем, какая цель за этим стоит. Уточняем, зачем нужна

автоматизация. Чтобы сократить время обработки клиентской заявки и повысить
стабильность обработки. Чтобы повысить конкурентоспособность и снизить
себестоимость обработки.
Уточняем, что именно сейчас мешает добиться этой цели:
 Сотрудникам приходится выполнять разные задачи в разных системах:

o сотрудники тратят на это много времени;
o обучение нового сотрудника занимает много времени;
o заявки могут теряться;

 Сотрудники вручную заносят данные в каждую из систем:

o появляются ошибки в данных, после чего может следовать
неправильная обработка заявки;
o сотрудники тратят на это время;
 Сотрудники формируют отчёты вручную:
o нет оперативной информации, т. к. отчёты формируются с большой
задержкой;
o сотрудники тратят на это много времени;
 Сотрудники не всегда знают, кому передать заявку в обработку:
o срок обработки заявки увеличивается, а конкурентоспособность
снижается;
o сотрудники тратят время.
10.2.2. Отвечает критериям качества заказчика

Все люди разные и заказчики тоже. Для разных задач — разные критерии
качества. Для разных заказчиков и одинаковых задач — тоже разные, хотя могут быть
похожи.
Необходимо определить критерии качества, по которым заказчик будет принимать

систему и проектировать решение исходя из этих критериев.
Критериями могут быть:
 Скорость отклика системы не более 1 секунды;

 Доступность системы 24/7 99,7% времени.
10.2.3. Хорошо документировано

Документации достаточно для:
 Использования — инструкции по ролям;

 Администрирования — инструкция администратора;
 Поддержки и адаптации — описание решения, из каких компонентов оно
состоит, как они взаимосвязаны и какие точки расширения в него заложены;
 Быстрого ввода нового человека на любую из ролей.
10.2.4. Просто поддерживается

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

состоит из переплетённых между собой бизнес-процессов и информационных

систем.
В хорошем решении есть:
1. «Хлебные крошки» — при возникновении ошибки в системе есть

возможность быстро понять её причину.
2. «Модульность» — функционал декомпозирован на отдельные блоки, что
позволяет переиспользовать одни и те же функции в разных частях
системы. Это даёт возможность внести изменения в одном месте, а они
применятся везде, где используется этот модуль.
Например, в решении реализована интеграция с 1С, в которой передаётся
информация о контрагенте из 1С в ELMA365, а о договорах контрагента из ELMA365
в 1С. Для прозрачности интеграционного взаимодействия необходимо хранить
информацию о:
1. Времени взаимодействия — в какое время началась и закончилась

передача данных;
2. Направлении взаимодействия — откуда и куда был отправлен запрос;
3. Субъекте и параметрах взаимодействия — что именно было в
интеграционном запросе. Например, загрузка данных о контрагенте.
Если передача данных осуществляется в рамках бизнес-процессов, то
сохранение информации о времени и направлении взаимодействия будет
происходить автоматически:
 Время взаимодействия — это время запуска и завершения экземпляра

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

например, модуль или отдельный бизнес-процесс, который будет использоваться в
тех местах решения, где требуется отправлять запрос в 1С. Выделение в отдельный
блок позволит:
 Вносить изменения в одном месте;

 Видеть историю запросов в одном месте.

10.2.5. Легко адаптируется

Во время использования решения заказчиком у него появляются новые
требования к изменению или расширению существующих функций. В связи с этим
требуется вносить изменения в решение. Для упрощения адаптации требуется:
 На этапе проектирования подумать о возможной расширяемости;

 Хорошая документация решения;
 Его модульность.

low-code-book-elma365

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

low-code-book-elma365

Загружено:

Авторское право:

Доступные форматы

Low-code book

Краткое руководство по созданию

Глава 1. Пример создания Low-code решения ....................................................... 10

1.1. Раздел ............................................................................................................. 11

1.3. Организационная структура ........................................................................... 24

1.4. Бизнес-процесс ............................................................................................... 26

1.4.1. Настройки доступа .................................................................................... 41

1.5. Запуск решения............................................................................................... 42

1.5.1. Создание отпуска ..................................................................................... 43

1.5.2. Согласование отпуска .............................................................................. 46

1.5.3. Оповещение о согласовании ................................................................... 47

1.5.4. Подготовка приказа .................................................................................. 48

Глава 2. Расширенная настройка Low-code решения ............................................ 49

2.1. Статусы отпуска .............................................................................................. 49

2.2. Автоматическая нумерация отпусков ............................................................ 54

2.3. Настройка главной страницы ......................................................................... 56

2.4. Настройка видов отпусков .............................................................................. 69

2.5. Настройка отпуска .......................................................................................... 73

2.5.1. Добавление нового свойства ................................................................... 73

2.5.2. Добавление динамических элементов на форму создания .................. 74

2.5.3. Изменение действий на форме ............................................................... 85

2.5.4. Изменение настроек приложения «Отпуск» ........................................... 88

2.6. Настройка бизнес-процесса ........................................................................... 90

2.6.1. Запись данных бизнес-процесса в элемент приложения ...................... 90

2.6.2. Учёт вида отпусков в бизнес-процессе ................................................... 92

Low-code book ELMA365 2

2.6.3. Контроль подписания приказа ............................................................... 106

2.7. Тестирование решения ................................................................................ 107

2.8. Экспорт решения .......................................................................................... 108

Глава 3. Элементы платформы ............................................................................. 114

3.1. Раздел ........................................................................................................... 115

3.2. Приложение................................................................................................... 116

3.2.1. Стандартное приложение ...................................................................... 116

3.2.2. Событие................................................................................................... 119

3.2.3. Документ ................................................................................................. 120

3.3. Интерфейс ..................................................................................................... 121

3.3.1. Страница ................................................................................................. 121

3.3.2. Виджет ..................................................................................................... 122

3.4. Бизнес-процесс ............................................................................................. 124

3.5. Группы и роли ............................................................................................... 125

3.6. Нумераторы................................................................................................... 126

3.7. Контракт ......................................................................................................... 126

3.8. Шаблоны документов ................................................................................... 127

3.9. Дополнительные параметры........................................................................ 128

3.10. Портал ......................................................................................................... 129

3.11. Модуль ......................................................................................................... 130

Глава 4. Как использовать элементы платформы................................................ 133

4.1. Работа с данными ......................................................................................... 133

4.1.1. Хранение данных .................................................................................... 133

4.1.2. Взаимодействие пользователя с данными ........................................... 133

4.1.3. Доступ к данным ..................................................................................... 134

4.1.4. Бизнес-процессы — движение данных ................................................. 135

4.1.5. Обработка данных .................................................................................. 135

4.2. Хранение настроек ....................................................................................... 137

Low-code book ELMA365 3

4.2.1. Дополнительные параметры ................................................................. 137

4.2.2. Настройки модуля .................................................................................. 138

4.2.3. Приложение ............................................................................................ 138

4.3. Интеграция .................................................................................................... 139

4.4. Хранение шаблонов документов ................................................................. 139

4.4.1. Один шаблон на документ ..................................................................... 139

4.4.2. Несколько шаблонов на документ ......................................................... 139

4.5. Использование сторонних библиотек ......................................................... 140

4.5.1. Подключение .js-библиотек ................................................................... 140