Package dependencies. Basic application packages
Glossary Item Box
Introduction
Bpm’online application development follows the basic principles of software design, in particular the “don’t repeat yourself” (DRY) principle. In the bpm’online architecture, the concept of packages was built around this principle and is implemented using dependencies between packages. Each package contains certain application functionality, which should not be duplicated in other packages. If a package requires functions that are part of a different package, you will need to set up dependencies between the packages.
Dependencies and package hierarchy
Packages can have multiple dependencies. For example, package C (Fig. 1) depends on packages A and D. Thus, all the functionality of the packages A and D is available in the package C.
Fig. 1. Dependencies and package hierarchy
Package dependencies form a hierarchical chain. This means that if you add a package to the dependency of another package, the dependent package will contain all functionality of the added package as well as functionality of all packages that the added package depends on. The closest analogy of the package hierarchy is the inheritance hierarchy of classes in object-oriented programming. For example, package E (Fig. 1) contains not only package C functionality on which it depends, but also the functionality of packages A, B and D. In addition; package F contains the functionality of packages B and D.
How to add package dependencies
Dependencies can only be added to a custom package, and only after it has been created. To add dependencies, click the [Add] (1) button on the [Depends on packages] (Fig. 2) detail. In the opened dialog of the package lookup, select the required package (2) and click the [OK] button (3).
Fig. 2. Adding dependency to a custom package
The selected package will be displayed in the list of dependencies of the current package. The packages that have been added to the dependencies are not displayed in the package lookup (Fig. 3).
Fig. 3. Added package dependency
ATTENTION After creating a new package, add it to the dependencies of the pre-installed “Custom” package. |
The list of dependencies in the metadata
The list of package dependencies is stored in the package metadata in the DependsOn property of the object specified in the descriptor.json file. The DependsOn property is an array of objects that contain the package name, version and unique identifier by which the package can be identified in the application database. A descriptor.json file is created for each package version. Example of a descriptor.json: Example of descriptor.json:
{ "Descriptor": { "UId": "974305e3-b01c-4020-b511-6fe9ac644d95", "PackageVersion": "7.8.0", "Name": "UsrDependentPackage", "ModifiedOnUtc": "\/Date(1478766323000)\/", "Maintainer": "Customer", "Description": "Пример пакета, зависящего от других пакетов", "DependsOn": [ { "UId": "8bc92579-92ee-4ff2-8d44-1ca61542aa1b", "PackageVersion": "7.8.0", "Name": "UsrCustomPackage" }, { "UId": "0ece3a34-413f-415b-919b-7b29bb31701f", "PackageVersion": "7.8.0", "Name": "SalesEnterpriseSoftkey_RUS" } ] } }
Application package hierarchy
Use the package dependency diagram to explore the hierarchy and application package dependencies. This chart is located on the [Package dependencies] tab of the [Configuration] section (Fig. 4).
Fig. 4. A fragment of package dependency hierarchy
If you click the node element of the package name diagram, the animated arrows will display package dependencies. For example, in the English version of the SalesEnterpise product, the [SalesEnterpiseSoftkey_ENG] depends only on the [SalesEnterpise] package and all its dependencies (Fig. 4). The [Custom] and [UsrDependentPackage] packages also depend on the [SalesEnterprise] package.
In the package hierarchy, the [Custom] package must be the root package with direct dependencies from all packages of the system. For more information about the “Package [Custom]” package, please see the "[Custom] package” article.
Primary packages
The application’s primary packages include the packages that are always available in all products. A brief list of such packages is shown in table 1.
Table 1. Basic application packages
Package name | Contents |
---|---|
Base | Base schemas of the primary objects, sections and object schemas, pages or processes connected to them. |
Platform | Modules and pages of the section wizard, content designer, dashboard designer, etc. |
Managers | Client modules of the schema managers. |
NUI | Functionality connected to system user interface. |
UIv2 | Functionality connected to system user interface. |
DesignerTools | Schemas of designers and their elements. |
ProcessDesigner | Process designer schemas. |