Экспорт и импорт структур в ELMA365

В этой статье рассматриваются особенности экспорта и импорта структур в ELMA365.

Изоляция

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

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

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

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

Прежде чем мы перейдём к задачам, которые решает экспорт/импорт, давайте рассмотрим, что можно экспортировать, импортировать и обновлять.

Типы пакетов

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

1. Приложение (namespace.app). Атомарный тип пакета. Содержит только одно приложение и всё, что с ним связано.
2. Раздел (namespace). Набор приложений и процессов. Раздел, как правило, является логической единицей, решающей ряд связанных задач.
3. Модуль (namespace). Набор виджетов, пользовательских блоков и методов API. В модулях создаются переиспользуемые сущности, которые можно применять в разных приложениях, интерфейсах, процессах. Другой ключевой сценарий использования модулей — это создание интеграций и подключение внешних систем и сервисов.
4. Решение (solution). Тип пакета для единовременной выгрузки одного или нескольких разделов и модулей.
5. Конфигурация (global). Все разделы, модули, оргструктура и другие сущности на уровне компании.

Экспортируемые и импортируемые структуры

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

Рассмотрим состав структур при экспорте/импорте:

• Шаблоны — шаблоны документов, используемые в процессах для генерации файлов, а также шаблоны листов ознакомления и согласования в составе выгружаемого пакета;
• Виджеты — виджеты и страницы, созданные в интерфейсах приложений, разделов, компании, а также формы в составе выгружаемого пакета;
• Группы — группы и роли приложения/раздела/компании в составе выгружаемого пакета;
• Меню — страницы в составе выгружаемого пакета.

Важно: под страницами в данном случае подразумеваются не виджеты типа Страница. Речь идёт о страницах, из которых состоит меню (главное или раздела). Каждое приложение и каждый раздел также имеет свою страницу. Поэтому на данном шаге экспорта/импорта загружается вся структура раздела/решения. Соответственно, если, например, прервать импорт после этого шага (или он прервётся из-за ошибки), раздел будет отображаться в системе, но страницы не будут загружаться, так как не импортированы приложения и виджеты;

• Процессы — бизнес-процессы и пользовательские блоки из модулей в составе выгружаемого пакета;
• Оргструктура — экспортируется/импортируется только вместе с конфигурацией;
• Нумераторы — нумераторы разделов и приложений в составе выгружаемого пакета. Нумераторы приложений и разделов только импортируются, их нельзя обновить, если они уже настроены в компании;
• Приложения — описание приложений, т. е. поля, настройки приложения, например условия отображения, настройки кнопок приложения, а также ссылки на бизнес-процессы, настройки канбан-доски, плиток, таблицы и прочее в составе выгружаемого пакета;
• Настройка прав — настройки прав доступа каждого приложения в составе выгружаемого пакета;
• Настройки (Дополнительные настройки при импорте) — список дополнительных параметров и настройки модулей в составе выгружаемого пакета. На момент написания статьи выгрузка значений параметров не предусмотрена;
• Расширения (Модули) — описание модулей и их состава.

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

• Решения — системная информация о версии сервиса exchange (необходим для обратной совместимости со старыми решениями) и о списке решений в составе пакета. Основная функция — совместимость и история версий;
• События (Системная шина при импорте) — обработчики событий, которые создаются в модулях, выгружаются в составе пакета;
• Переносимые сервисы — настройки подключения к переносимым сервисам модуля. Выгружается только настроечная часть. Образы переносимых сервисов не участвуют в переносе;
• Локализация — файлы с переводами, загруженные в экспортируемый раздел в составе выгружаемого пакета;
• Токены OAuth2/OIDC — шаблоны и уровни доступа к элементам системы. Выданные разрешения не переносятся, т. к. являются частью системы безопасности платформы;
• Портал — страницы внешнего портала, а также его настройки брендирования. Портал привязан к разделу и экспортируется вместе с ним в составе выгружаемого пакета;
• Отчеты — формы отчётов, созданные на основе приложений и бизнес-процессов (источников отчёта), включая данные по их настройкам, таким как связь между источниками, колонки отчёта;
• Контракты — описание контрактов: список полей, настройки источников и т. д.

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

Импорт такого раздела или решения в случае отсутствия приложений-источников пройдёт без ошибок, но связи контракта с источниками не будет;

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

В экспорте/импорте конфигурации также участвуют настройки листов согласования и ознакомления;

• Проекты — описание типов проектов, создаваемых в разделе Администрирование > Типы проектов. Выгружается при экспорте конфигурации, раздела Проекты и решений, содержащих в своём составе раздел Проекты;

Важно: шаблоны проектов (элементы приложения), включённые автоматически при создании типа проекта, при экспорте/импорте структур не переносятся;

• Веб-формы — веб-формы приложений в составе выгружаемого пакета.

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

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

Состояния импортированного решения

Импортированное решение имеет несколько состояний:

1. Заблокировано.

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

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

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

2. Платное.

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

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

В зависимости от состояния решения (заблокировано/разблокировано, платное/бесплатное) доступ к экспорту и обновлению разделов, а также управлению модулями различается. Ниже приведены схемы доступа.

Модули

Разделы

Зависимости решений

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

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

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

Кейсы

Теперь рассмотрим несколько кейсов настройки ELMA365 и переноса результатов работы между компаниями. Для разных целей экспорта/импорта лучше подходят разные типы пакетов.

Кейс 1. Счёт

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

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

1. Счета.
2. Контрагенты.
3. Назначения платежей.
4. Мои юридические лица.

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

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

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

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

1. Для этого будем использовать метод search().
2. Метод search() доступен из описания приложения.
3. Описание мы можем получить одним из двух способов:

• включив константу Global и написав команду Global.ns._clients.app._companies.search().
• добавив в контекст страницы/приложения/процесса переменную с типом Приложение > Компании и написав команду Context.fields._companies.app.search().

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

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

Кейс 2. Счета с особенными требованиями

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

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

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

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

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

Вопрос: где правильнее создать эти группы. Ответ очень прост: не имеет значения, главное — внутри решения (помним про принципы изоляции).

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

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

Кейс 3. Большой проект

Часто в компании нужно автоматизировать несколько участков. Для этого создаётся сложная конфигурация.

Экспортировать и импортировать можно конфигурацию целиком. Но стоит ли? Давайте разберёмся.

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

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

Почему бы тогда при такой вариативности не пользоваться просто экспортом/импортом конфигурации?

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

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

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

Обновление

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

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

Во время обновления может возникнуть одна из двух ситуаций:

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

По своей механике обновление не отличается от импорта, но нужно обратить внимание на следующие моменты:

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

Мягкое обновление решений

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

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

Если решение частично заблокировано, то связи с компонентами из заблокированного раздела игнорируются, и компоненты в заблокированном разделе обновляются при мягком обновлении.

Удаление

Удаление — серьёзное действие. Жёстко в ELMA365 практически ничего не удаляется, а лишь помечается удалённым. Тем не менее, при экспорте/импорте можно избавиться от ненужных контекстных переменных, они не выгружаются, если удалены жёстко.

Удалённые разделы, приложения и страницы переносятся вместе со всем остальным.

Была ли статья полезной?

Спасибо за ваш отзыв!

×

Ваш отзыв успешно отправлен!

Спасибо за обратную связь.

×

Уточните, почему:

Рекомендации не помоглиТекст трудно понятьНет ответа на мой вопросСодержание статьи не соответствует заголовкуДругая причина

×

Расскажите, что вам не понравилось в статье:

ДаНет

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