Managing Productions (PRI component type)
Overview
InterSystems Interoperability Productions are defined in a single monolithic class definition. A production can contain many hundreds or thousands of configuration items. This presents a problem if there are multiple developers working on different business hosts within the same production simultaneously. For large productions, containing many configuration items, simultaneous development is almost inevitable but is difficult to manage due to the monolithic nature of the single class that defines all production settings.
Deltanji addresses this problem by increasing the granularity with which items can be managed. Instead of versioning a single class definition containing all the configuration items, this component driver allows individual configuration items to be managed separately. Each configuration item has its own versioning and revision history and can be checked-out, checked-in and deployed independently of any other items in the same Production.
The diagram on the right illustrates how a monolithic class definition is split up so that, for source control purposes, the settings for each configuration item can be managed separately.
Because each configuration item within a production class is managed by Deltanji as a first-class component in its own right, Deltanji provides all the source control, versioning and workflow capabilities that it provides for any other component.
Configuration Items
Each individual configuration item within a production is exposed as a separate component in Deltanji's component view. These are grouped by the production class name and where the configuration item name contains dots these are used to group them in a tree structure.
Component Naming Each configuration item is identified by the name of the production it belongs to
suffixed with the name of the configuration item's class or suffixed with the configuration
item's name if it has been given one. For example ADT.Production.EnsLib.XML.FileService. If the configuration item has been named then the item's class name is also included
enclosed in square brackets. For example, ADT.Production.EnsLib.REST.GenericService would be displayed as ADT.Production.EnsLib.REST.GenericService. But if it has been named Loan Requests then it would appear in the Deltanji component view as ADT.Production.Loan Requests [EnsLib_REST_GenericService].
Grouping By default each configuration item is registered as a separate Object, however for large productions that can lead to a very large number of items that need to be managed.
There are three methods of dealing with a large number of items. The first approach groups a number of items together statically. The second approach is to group items together using a change request which means that the grouping can change from one project to the next as required. And the third approach, which is the most dynamic, is to use multi-select, either in the Deltanji Portal or on the Production Configuration screen, to group items. Whichever method is used, and they can each be used in combination, allows a set of configuration items to be operated on by Detanji as a single operation.
For static grouping a single Object can be created containing several configuration items or components of other types. This allows a closely related set of configuration items (for example, a Service, a Process and an Operation that are designed to work together) to be treated, for source control purposes, as a single versioned entity that is indivisible. Likewise a Service class and the configuration item that implements it could be grouped together as a single indivisible entity.
Once registered, Objects can also be grouped using a Change Request enabling sets of related changes to multiple configuration items to be checked-in, transferred and deployed as a single operation.
Finally, within the Production Configuration screen, or within the Deltanji Portal, multiple configuration items can be selected using shift+click or ctrl+click and then checked-in, transferred or deployed as a single operation.
Deployment When a configuration item is deployed into an existing production, if there is an item in that production with a matching item name and class name then that item will be replaced, otherwise the configuration item will be added to the production.
Deltanji leverages the Ens.Deployment.Deploy method to deploy a related set of configuration item changes into a production. This manages the updating of running productions, disabling and re-enabling each business process as necessary, and performs an automatic rollback if the deployment is unable to be completed.
Information about each deployment is recorded in the Production's Deployment History as well as being recorded in Deltanji's own audit trail.
The enabled/disabled state of the item is part of the item's definition, so if the master copy of the item is enabled then it will be enabled when it is first deployed.
Production Class
The settings that apply to the production as a whole (for example, the Actor Pool Size and the Shutdown Timeout) are managed as part of the production class itself and is managed by Deltanji as a normal CLS component. When the Production Settings tab is selected in the Production Configuration screen then source control operations will operate on the production class which includes all production settings, class methods, parameters and other content of the production class, but excludes all configuration items.
In addition to the ProductionDefinition XData block that contains the definition of each configuration item, the production class itself may contain class methods, parameters and even other XData blocks. To allow this content to be source controlled the production class can be registered and managed just like any other class. However, when it is manipulated by Deltanji the configuration items (<Item> elements) within the ProductionDefinition XData block will be ignored.
When a production class is checked-in its ProductionDefinition XData block will not include any configuration items apart from production settings. When it is deployed the configuration items contained in the XData block of the class at the destination will be preserved and not overwritten.
Production classes that were previously managed by Deltanji using older versions of Deltanji's CLS component driver will automatically switch to the new behavior when the Configuration Item component driver is enabled. Any source control operation of a Production class will only affect the class methods, properties and Production Settings defined in the class. Configuration Items will not be affected by any operation.
Configuration Items that were previously considered to have been part of a Production class will show as being unregistered. These should be registered as new Configuration Item components and their Objects marked as active in all locations where the Production class was previously active.
Monolithic Mode Configuration Items contained in old versions of the Production class will not be directly accessible once the Configuration Item component driver has been enabled. Should access to configuration items an older version of a Production class be required then the CLS component driver can be temporarily switched back to monolithic mode using the following setting:
set ^%vcct("CLS","settings","monolithic")=1
While the CLS component driver is set to monolithic mode Deltanji can still be used to perform source control operations on Configuration Items as normal, this setting only affects the manipulation of Production classes using the CLS component driver.
Care should be taken while monolithic mode is enabled as it is possible to overwrite registered Configuration Items without the normal checks and controls that are usually carried out by Deltanji. This setting should be set back to 0 as soon as possible to avoid unexpected conflicts with the management of Configuration Items.
Client Integration
Deltanji provides a specific client integration for the Production Configuration page in the IRIS Portal. This allows source control operations to be carried out on Configuration Items directly while configuring a production.
Source Control Button When the client integration is installed and enabled, a source control button will be shown in the top-left corner of the settings panel. When a Configuration Item is selected then the color of the source control button indicates the current state of the selected item. For unregistered items it will be colored red, for registered items amber and for checked-out items it will be colored green.
If the selected Configuration Item is not registered but not checked out then its properties will be read-only. The Enabled property is an exception to this rule. A Configuration Item can be enabled or disabled regardless of whether it is checked-out or not.
Clicking on the source control button will launch the standard Deltanji Transfer dialog screen and this can be used to register, check-out, check-in or transfer the selected Configuration Item.
If the Production Settings are selected then color of the source control button will indicate the source control status of the Production class itself. Clicking on the source control button will allow source control operations to be performed on the Production class using the standard Deltanji Transfer dialog screen.
Color Coding Configuration Items are color coded based on their source control status. If an item is unregistered to Deltanji then it will be colored red. If it is checked-out, and therefore editable, then it will be colored green.
Selection To perform a Deltanji source control operation on a Configuration Item simply select the item by clicking on it and then click on the Deltanji icon at the top of the properties panel to invoke the standard Deltanji Transfer dialog screen. Multiple items can be selected using shift+click or ctrl+click.