General information about packages

A bpm'online package is a collection of configuration elements (schemas, data, scripts, additional libraries) that implement a particular block of functionality. In the file system, packages are directories with various subdirectories and files.

Any bpm’online product is a finite set of packages. To extend or change product functionality, you need to install the package in which all necessary changes are already implemented.

The bpm'online packages can be divided into two types:

• Pre-installed packages. Supplied with the system and are installed by default. These include packages with basic functionality (e.g., Base, NUI), packages that extend the functionality of the system (for example, 1C integration packages, telephony, etc.), and packages developed by third-party developers. These packages are installed from zip archives by using the WorkspaceConsole utility.
• Custom packages are created by the users of the system. These packages can be attached to the SVN repository.

Configuration elements of the pre-installed packages cannot be modified. You can develop additional functionality or modify the existing functionality only via custom packages

Flat package structure in the repository

Bpm'online uses flat package structure. The “branches” and “tags” directories that store different versions of the project are located inside the package root directory (Fig. 1). Thus, each package is a separate version repository of a development project.

Fig. 1. Previous structure of the version repository and the flat bpm’online package structure

In contrast to the previously used storage structure, the trunk directory is not used in bpm’online. The application only works with a specific package version that was specified during its creation or installation from the repository. Different package versions are stored in the branches directory.

Package version

One of the main characteristics of a package is its version.

The version is specified in the corresponding package mini-page field (Fig. 2). The package version can contain digits, Latin characters, "." and "_” symbols. The package version must begin with a numeric or alphabetic character.

Fig. 2. Package version in the package mini-page

In addition, the package version is stored in its metadata of the PackageVersion object specified in the descriptor.json file. The descriptor.json file is created for each package version. Example of descriptor.json:

{
  "Descriptor": {
    "UId": "8bc92579-92ee-4ff2-8d44-1ca61542aa1b",
    "PackageVersion": "7.8.0",
    "Name": "UsrCustomPackage",
    "ModifiedOnUtc": "\/Date(1477652941000)\/",
    "Maintainer": "Customer",
    "Description": "Пакет пользователя",
    "DependsOn": [
      {
        "UId": "e14dcfb1-e53c-4439-a876-af7f97083ed9",
        "PackageVersion": "7.8.0",
        "Name": "SalesEnterprise"
      }
    ]
  }
}

All elements of the package are of the same version as the package itself.

The application is updated by installing packages with the functionality of newer package versions.

Package structure

When you commit a package to the SVN, a folder with the package name is created, and the branches and tags directories are created inside it (Fig. 3).

Fig. 3. Package structure in the SVN

The branches directory contains all versions of this package. Each version is stored in a separate subfolder whose name matches the package version number in the system, for example, 7.8.0.

The tags directory stores tags. The tags in the version control system represent a "snapshot" of the project at a certain point in time, a static copy of the files required for saving some critical stage of development.

Working copies of the packages are stored locally in the file system. The path to the package repository is specified in the ConnectionStrings.config configuration file in the connectionString attribute of the defPackagesWorkingCopyPath element:

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

The directory containing the package name is created in this path. Its inner structure is shown in Fig. 4.

Fig. 4. The package directory structure in the file system

The package schemas are contained in the Schemas directory. External assemblies attached to the package, data and SQL scripts are contained in the Assemblies, Data and SqlScripts directories. All package text resources, translated into different languages, are stored in a separate Resources directory.

The descriptor.json file stores the package metadata in JSON format — ID, name, version, dependencies, etc.

The CommitLocker file is a utility file that is used in the package locking mechanism.