Difference between revisions of "HowTo:Provide system definitions with a custom plugin"
m |
|||
| Line 1,054: | Line 1,054: | ||
<!-- DO NOT REMOVE THIS -->{{Template:HowTo/End}}<!-- DO NOT REMOVE THIS --> | <!-- DO NOT REMOVE THIS -->{{Template:HowTo/End}}<!-- DO NOT REMOVE THIS --> | ||
| + | ==Plugin Initialization Timing== | ||
| + | The Plugin initialization and upgrade mechanism has been improved and stabilized.{{Version/ServerSince|5.2.0}} | ||
| + | |||
| + | Previously, each plugin was fully initialized one after another — meaning all initialization steps (system definitions, database schema update, content initialization) were completed for plugin A before plugin B was started. | ||
| + | As of this change, the initialization follows a phase-based approach: each phase is executed for all plugins before the next phase begins. The phases are: | ||
| + | |||
| + | * System Definitions – All MetaClasses, MetaProperties, Classifications, and SelectiveLists for all plugins are registered first. This ensures that all system meta definitions are known before any database or content work begins. | ||
| + | * Preprocess DB Update – Pre-processing of the database update runs for all plugins. | ||
| + | * Update DB Schema – The database schema is adapted for all plugins. | ||
| + | * Postprocess DB Update – Post-processing runs for all plugins. | ||
| + | * Initialize Content – System content is initialized and updated for all plugins. | ||
| + | |||
| + | Plugins are processed in dependency order — if Plugin A depends on Plugin B, Plugin B is always initialized first within each phase. | ||
| + | This approach prevents issues that previously occurred when a plugin tried to access MetaClasses or MetaProperties from another plugin that had not yet been initialized. | ||
==See also== | ==See also== | ||
Latest revision as of 07:15, 6 May 2026
This tutorial explains how to provide any kind of preconfigured UBIK® system definitions using a custom plugin (or more specific: module).
| It is now possible to generate a UBIK® Plugin C# Solution from a custom data model configured in UBIK® Studio. |
General concept
When rolling out a UBIK® customizing into a (productive) environment, there is always the challenge regarding the transportation of the data model and basic data. The sustainable solution is to deliver versioned packages of system definitions in plugins, because that allows for easy deployment and upgrade, and for the direct application of state-of-the-art software development strategies for plugin development.
UBIK® plugins are detected when an Environment is initialized, and the user is prompted with a database upgrade if necessary. The technical maintenance of the database is automatic and allows for arbitrary adaptations. The plugin developer can decide whether to make meta definitions immutable (as system design objects in the System namespace) or further customizable by the user (as regular content). Custom scripts can be executed every time the Environment is connected or just during an upgrade.
Prerequisites
To understand the code, knowledge about the UBIK® ER-model and the plugin injection mechanism is required.
Instructions
Plugin Initialization Timing
The Plugin initialization and upgrade mechanism has been improved and stabilized.
Previously, each plugin was fully initialized one after another — meaning all initialization steps (system definitions, database schema update, content initialization) were completed for plugin A before plugin B was started. As of this change, the initialization follows a phase-based approach: each phase is executed for all plugins before the next phase begins. The phases are:
- System Definitions – All MetaClasses, MetaProperties, Classifications, and SelectiveLists for all plugins are registered first. This ensures that all system meta definitions are known before any database or content work begins.
- Preprocess DB Update – Pre-processing of the database update runs for all plugins.
- Update DB Schema – The database schema is adapted for all plugins.
- Postprocess DB Update – Post-processing runs for all plugins.
- Initialize Content – System content is initialized and updated for all plugins.
Plugins are processed in dependency order — if Plugin A depends on Plugin B, Plugin B is always initialized first within each phase. This approach prevents issues that previously occurred when a plugin tried to access MetaClasses or MetaProperties from another plugin that had not yet been initialized.

