Пакеты

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

Классификация пакетов 

Пакет Creatio — это совокупность конфигурационных элементов (схем, данных, SQL-скриптов, дополнительных библиотек), которые реализуют определенный блок функциональности. Физически пакет представляет собой каталог, содержащий определенный набор подкаталогов и файлов.

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

Пакеты Creatio условно можно разделить на два вида:

• Предустановленные пакеты. Поставляются вместе с системой и устанавливаются в рабочее пространство по умолчанию. К таким относятся пакеты с базовой функциональностью (например, Base, NUI), а также пакеты, созданные сторонними разработчиками. Такие пакеты устанавливаются из zip-архивов как приложения marketplace или с помощью утилиты WorkspaceConsole.
• Пользовательские пакеты — пакеты, создаваемые пользователями системы. Они могут быть привязаны к хранилищу SVN.

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

Структура пакета 

При фиксации пакета в систему контроля версий в хранилище пакета создается папка с именем пакета, а внутри нее — каталоги branches и tags.

В папке branches хранятся все версии данного пакета. Каждая версия хранится в отдельной вложенной папке, имя которой совпадает с номером версии пакета в системе, например, 7.8.0.

Каталог tags предназначен для хранения меток. Метки в системе управления версиями — это "снимок" проекта в определенный момент времени, статическая копия файлов, необходимая для фиксации определенного важного этапа разработки.

Рабочая копия пакета сохраняется локально в файловой системе. Путь для хранения пакетов задается в конфигурационном файле ConnectionStrings.config в атрибуте connectionString элемента defPackagesWorkingCopyPath

<add name="defPackagesWorkingCopyPath" connectionString="TEMP\APPLICATION\WORKSPACE\TerrasoftPackages" >

По этому пути создается папка с именем пакета.

Структура папки пакета в файловой системе

В каталоге Schemas хранятся схемы пакета. Привязанные к пакету внешние сборки, данные и SQL-сценарии содержатся, соответственно, в каталогах Assemblies, Data и SqlScripts. Все текстовые ресурсы пакета, переведенные на разные языки, вынесены в отдельный каталог Resources.

В файле descriptor.json хранятся метаданные пакета в формате JSON — его идентификатор, наименование, версия, зависимости и т.д.

Зависимости и иерархия пакетов 

Разработка приложения Creatio базируется на основных принципах проектирования программного обеспечения, в частности, принципа отсутствия повторений (DRY). В архитектуре Creatio этот принцип был применен к механизму пакетов и реализован с помощью зависимостей пакетов друг от друга. Каждый пакет содержит определенную функциональность приложения, которая не должна повторяться в других пакетах. Для того чтобы такую функциональность можно было использовать в любом другом пакете, необходимо пакет, содержащий эту функциональность, добавить в зависимости пакета, в котором она будет использована.

Пакет может иметь несколько зависимостей. Например, в пакете С установлены зависимости от пакетов А и D. Таким образом, вся функциональность пакетов А и D доступна в пакете С.

Зависимости пакетов формируют иерархические цепочки. Это означает, что в пакете доступна не только функциональность пакета, добавленного в зависимости текущего, но и функциональность всех пакетов, от которых зависит пакет, добавленный в зависимости текущего. Ближайшей аналогией иерархии пакетов является иерархия наследования классов в объектно-ориентированном программировании. Так, например, в пакете Е доступна функциональность не только пакета C, от которого он зависит, но и функциональность пакетов А, В и D. А в пакете F доступна функциональность пакетов B и D.

Добавление зависимостей пакета 

Зависимости можно добавить только в пользовательский пакет и только после его создания. Для этого необходимо в карточке пакета на детали Зависит от пакетов (Depends on packages) нажать на кнопку Добавить (Add) (1). В появившемся диалоге справочника пакетов необходимо выбрать нужный пакет (2) и нажать на кнопку OK (3).

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

После создания пакета он автоматически добавляется в зависимости предустановленного пакета Custom.

Список зависимостей в метаданных 

Список зависимостей пакета хранится в его метаданных в свойстве DependsOn объекта, определенного в файле descriptor.json. Свойство DependsOn является массивом объектов, в которых указывается имя пакета, его версия и уникальный идентификатор, по которому можно определить пакет в базе данных приложения. Файл descriptor.json создается приложением для каждой версии пакета. Пример файла descriptor.json:

{
  "Descriptor": {
    "UId": "51b3ed42-678c-4da3-bd16-8596b95c0546",
    "PackageVersion": "7.8.0",
    "Name": "UsrDependentPackage",
    "ModifiedOnUtc": "\/Date(1522653150000)\/",
    "Maintainer": "Customer",
    "DependsOn": [
      {
        "UId": "e14dcfb1-e53c-4439-a876-af7f97083ed9",
        "PackageVersion": "7.8.0",
        "Name": "SalesEnterprise"
      }
    ]
  }
}

Иерархия пакетов приложения 

Иерархию и зависимости пакетов приложения удобно исследовать, используя диаграмму зависимостей пакетов. Эта диаграмма расположена на вкладке Зависимости пакетов (Package Dependencies) раздела Конфигурация.

Если кликнуть по узловому элементу диаграммы с именем пакета, то с помощью анимированных стрелок отобразятся связи с пакетами, которые зависят от выбранного, и от которых зависит выбранный пакет. Например, для продукта SalesEnterpise, пакет UsrDependentPackage зависит только от пакета SalesEnterpise и всех его зависимостей. Также от него зависит пакет Custom.

Основные пакеты приложения 

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

Пакет Custom 

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

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

Особенности пакета Custom 

Как и все предустановленные пакеты, пакет Custom нельзя добавить в хранилище учета версий (SVN). Поэтому его схемы можно перенести в другое приложение только при помощи экспорта и импорта.

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

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

Пакет Custom и Мастер разделов 

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

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

Рекомендации 

Пакет Custom рекомендуется использовать в следующих случаях:

• Когда не предполагается перенос изменений в другое приложение.
• Если изменения выполняются при помощи мастеров или вручную, при этом объем изменений небольшой.
• Если нет необходимости использовать SVN.

При необходимости разработать значительный объем новой функциональности более целесообразным будет создание нового пользовательского пакета с использованием SVN.