Архитектура и системные требования / Экспорт и импорт структур в ELMA365

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

В этой статье разберем типы структур, которые можно выгружать и загружать, а также особенности экспорта и импорта в ELMA365.

Изоляция

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

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

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

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

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

Типы пакетов

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

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

Состав экспорта/импорта

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

 

  • Шаблоны

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

  • Виджеты

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

  • Группы

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

  • Меню

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

  • Процессы

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

  • Оргструктура

Экспортируется/импортируется только вместе с конфигурацией

  • Нумераторы

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

  • Приложения

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

  • Настройка прав

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

  • Настройки (Дополнительные настройки при импорте)

Список дополнительных параметров и настройки модуля в составе выгружаемого пакета. Значения параметров на момент написания статьи не выгружаются.

  • Расширения (Модули)

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

  • Решения

Системная информация о версии сервиса exchange (необходим для обратной совместимости со старыми решениями) и о списке решений в составе пакета. Основная функция совместимость и история версий.

  • События (Системная шина при импорте)

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

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

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

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

Кейс 1. Счет

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

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

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

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

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

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

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

  1. Для этого будем использовать метод search().
  2. Метод search() доступен из описания приложения.
  3. Описание мы можем получить одним из двух способов:
    1. Включив флаг Global и написав конструкцию типа Global.ns._clients.app._companies.search().
    2. Либо добавив в контекст страницы/приложения/процесса переменную с типом Приложение «Компании» и написав конструкцию типа Context.fields._companies.app.search().

Вариант «a» нарушит изоляцию, даже при том, что мы ссылаемся на системное приложение, потому что мы включили флаг Global в скриптах, а он экспортировать раздел не позволит. Однако вариант «b» не будет препятствовать экспорту, потому что флаг Global в этом случае включать не понадобится.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Немного об обновлении

На момент написания статьи обновление поддерживается для разделов и решений.

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

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

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

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

  1. При обновлении добавляется новое/изменяется конфликтующее. Ничего не удаляется. Например, если мы удалили поле на исходной площадке, а на целевой оно все еще есть, то при обновлении оно не удалится с целевой.
  2. Лучше всего не вносить изменений на целевой (production) площадке, как бы сильно не хотелось. Четкое разделение тестовой и прод площадок значительно упростит доставку изменений и поддержку вашего решения в долгосрочной перспективе.

К слову об удалении

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

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

Заключение

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