Общие принципы работы с пакетами

Любой продукт Creatio представляет собой определенный набор пакетов.

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

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

Типы пакетов:

• — предустановленные пакеты. Являются частью приложения и по умолчанию устанавливаются в рабочее пространство. Недоступны для изменения.

  Виды предустановленных пакетов:

  • Пакеты с базовой функциональностью (например, Base, NUI).
  • Пакеты сторонних разработчиков.

    Устанавливаются из *.zip-архивов с помощью Creatio IDE или с помощью утилиты WorkspaceConsole.

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

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

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

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

Пакет Custom 

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

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

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

Рекомендуемые варианты использования пакета Custom:

• Не предполагается перенос изменений в другую рабочую среду.

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

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

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

Пользовательский пакет 

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

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

При фиксации пакета в системе контроля версий в хранилище пакета создается папка с именем пакета.

Структура папки с именем пакета:

• Папка branches.

  Назначение — хранение версий текущего пакета. Версия пакета — отдельная вложенная папка, имя которой совпадает с номером версии пакета в системе (например, 7.18.0).

• Папка tags.

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

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

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

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

• Папка Schemas — содержит схемы пакета.
• Папка Assemblies — содержит внешние сборки, привязанные к пакету.
• Папка Data — содержит данные, привязанные к пакету.
• Папка SqlScripts — содержит SQL-сценарии, привязанные к пакету.
• Папка Resources — содержит локализованные ресурсы пакета.
• Папка Files — содержит файловый контент пакета.
• Файл descriptor.json — хранит метаданные пакета в формате JSON. К метаданным пакета относятся идентификатор, наименование, версия, зависимости и т. д.

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

Разработка приложения Creatio базируется на основных принципах проектирования программного обеспечения, в частности, принципа отсутствия повторений (DRY).

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

Виды зависимостей:

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

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

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

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

Иерархия и зависимости пакетов отображены на диаграмме зависимостей пакетов. Чтобы открыть диаграмму:

1. Перейдите в раздел Конфигурация (Configuration).
2. В выпадающем списке Действия (Actions) панели инструментов в группе Пакеты (Packages ) выберите Диаграмма зависимостей пакетов (Package dependencies diagram).

Диаграмма зависимостей будет открыта в новой вкладке.

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

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

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

Чтобы добавить зависимости:

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

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

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

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

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

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

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

Привязка данных к пакету 

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

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

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