This page provides an overview of what a Verne product upgrade entails. It describes the various components that represent the Verne product, what is typically upgraded within that component and the impact that these upgrade changes may have on an existing implementation of Verne.
Further, it discusses some technical considerations that are occasionally introduced as a result of an upgrade, it touches on what would need to be considered if a Client’s implementation were to change from a database search to one using the configurable Elastic Search capability that Verne now provides.
Finally, it provides a general overview of the typical steps that a Client should undertake within their own configuration settings to take advantage of any new features and functionality that a Verne upgrade brings, and to ensure that the upgrade does not introduce any unwanted errors or changes.
This document should be read in conjunction with the Release and Version Management Policy.
What Is Upgraded?
When a Verne product upgrade is applied, all of the components that make up the product, namely the three areas identified in the previous section are upgraded. To many clients, this may not be visible, as they may not license all of the Registry (and hence Subject) Templates. However, in the event that their requirements change to require a new register-based on a new Registry/Subject Template, they would utilise the upgraded version.
As an example, if a client has a solution based on the OR Registry Template, an upgrade of the product would include the Core run time, the OR Template and all other Templates, regardless of whether they are utilised.
Upgrade of the Core Run Time
When upgrading the Verne product, part of the upgrade will be delivered via the Verne Core run time engine. Typically the upgrade of the core run time will deliver the following: –
- Bug fixes to enhance stability of the product;
- Any applicable fixes to improve or address Security issues;
- Fixes to enhance the performance of the product;
- New capability to deliver additional features and functions that can be activated via a Client’s configuration.
Accordingly, the introduction of an upgrade with respect to core run time should not introduce any significant change to a Client’s implementation, other than to remediate any specific bugs that were present in the previous release.
Any new features or functions that the run time engine can deliver are typically turned off by default within the corresponding upgraded template configuration, meaning that no unexpected features or functionality are introduced without due consideration and explicit introduction by the client, via their configuration set.
Note that this applies only to new features within the templates, and not to the other areas of the run time engine, as identified in the first three bullet points of the list above.
Upgrade of the Templates
When upgrading the Verne product, part of the upgrade will be delivered via the Registry and Subject templates. Typically the upgrade of the templates will deliver the following: –
- Any new templates that the Verne product has developed, such as a new variation of an Occupational register;
- Bug fixes to enhance stability of the templates;
- New business services, if applicable within an existing template;
- Configuration data that will implement any new capability that delivers additional features and functions. As stated previously, this will be turned off as a default within the template.
Accordingly, the introduction of an upgrade with respect to the templates should not introduce any significant change to a Client’s implementation, other than to remediate any specific bugs that were present in the previous release. However, it is in this area that the greatest opportunity to implement quality control around potential regression issues arises, to ensure that the existing Client configuration will not result in a conflict with upgraded template configuration.
It is worth noting that a Client’s implementation may be completely unaffected at the template level if the upgrades to the templates do not affect the templates that the Client’s implementation is based on. For example, if a Client’s implementation is based on the BR Registry template and the Companies Subject template, and no changes have been introduced to either of these templates as part of the upgrade, then the upgrade will have no impact on the Client’s implementation with regards to this component.
New Features
As mentioned previously, any new features or functionality that Verne delivers is typically introduced via a feature. This enables the functionality to be introduced to the appropriate template in a way that does not change a Client’s existing system.
There are two ways that a feature is introduced into a template:
- As a simple ‘on/off’ configuration element that when turned on within a Client’s implementation, introduces the functionality to the system. These features are usually embedded within the core run time engine and need no further configuration to take advantage of them.
- As an ‘on/off’ configuration element, allied with a configuration that is necessary to be introduced within the Client’s implementation. As an example, if a feature was introduced that allowed a Client to deliver notifications via Facebook, then some specific configuration at the Client implementation, such as the notification text, or any rules to control when the notifications were to be delivered (assuming such an option was available within the feature) would be required. To this end, the upgrade of the Verne product would also require a corresponding release of the Client implementation to synchronise the introduction of the new feature.
Accordingly, the introduction of a new feature should not introduce any significant change to a Client’s implementation. However, it should be recognised that some configuration work at the Client implementation level will be required if the feature is to be introduced.
New Modules
Verne upgrades can include new modules. A Verne module is a self-contained, and typically an autonomous set of functions that can be integrated into an existing solution via the ‘loosely-coupled‘ concept. Loose coupling means that the module’s functionality can be made available, and an association with existing data is established via data entries within the database that logically join the two.
This coupling is then complemented by specific configuration ‘hooks’ from the entity to the functional module within the Client implementation, or the turning on of the functionality via a feature. This loose coupling means that the existing entity data is unaffected by the new functionality.
An example of an autonomous, loosely-coupled module is the Verne Case Management functionality. Case Management can be run as a standalone service or can be coupled to any object (such as a company entity, or a Review Task) via the loose-coupling mechanism, the addition of some Client-specific configuration to leverage the Case Management function, and the turning on of the various features within Case Management that can be utilised.
Elastic Search
Verne now has Elastic Search embedded within the product as an option, but note that it is optional as to whether a Client leverages the functionality. However, there may be Client implementations that use a database search, who wish to change this to utilise the rich search functionality that Elastic Search brings. In order to do this, the search collections that Elastic Search will establish to mirror the database searching would require configuring, and a number of configuration elements amended or introduced. In addition, a review of the business services that implement the existing searches would require review and change. Clients need to be prepared for the fact that this may take some time to perform the analysis of requirements and subsequent configuration.
The changes would be made to the Client configuration, and a decision would be necessary to determine whether the default, automatic Elastic Search indexing process would be initiated or whether a manual process would be undertaken. Elastic Search requires a Java runtime of 1.7 or later, and the Elastic Search implementation needs to be 1.3.4 or later. Accordingly, there are a number of Verne functions, such as the Business Performance Dashboard, that would require the appropriate Java runtime to be installed.
Technical Considerations
Java
Verne versions Jennings 1.2 and later require version 1.7 or later of the Java runtime. If the Client’s environment does not have this, then this must be installed prior to applying the upgrade.
Third-Party Software
Verne uses a number of third party software tools to perform minor operations, an example being a utility that finds differences between two files. A list of these products can be found on the Verne for Clients space, available to all Foster Moore Verne clients.
Clients should, if they are concerned, review this list to see if there are any issues in relation to policies that their organisation may have about the use of such products.
Client Implementation Upgrade
As identified earlier in this document, a Verne product upgrade typically is synchronised with an upgrade to the Client’s implementation. This upgrade allows the introduction of new services, features and functions that the Client may wish to take advantage of.
Verne endeavours to be backward compatible with each upgrade, but in certain circumstances, there may be activities that have to be undertaken within the Client’s implementation or environment to integrate seamlessly with the product upgrade.
Some of the activities below have already been identified in the previous pages, but potential areas that may require consideration and work are as follows.
Client Configuration Changes
As discussed, the Client’s implementation will likely include upgrades to introduce new features and functionality that the Verne upgrade contains.
Environmental Changes
There may be environmental changes, in addition to the update of the Java runtime to be reviewed and considered. These changes will be identified as part of the Verne upgrade release notes.
Database Schema Changes
In some instances, changes (typically additions) to the database schema will be introduced. These are typically introduced as part of the upgrade via a series of scripts.
Data Conversion or Population
Correspondingly, some changes may require data conversion or population. These are typically introduced as part of the upgrade via a series of scripts.
Regression Testing
As discussed previously, regression testing is a prudent exercise and should be conducted in a pre-production environment, in a controlled and well-managed manner.
User Acceptance Testing
In a similar manner, any new functionality or new services introduced should undergo rigorous user acceptance testing to ensure that the changes introduced into the Client implementation are issue-free.
Portal Server
Any client that uses a portal may need to perform specific testing that ensures the system works as designed within that portal environment.
Training and Documentation
It may be that there is a need for training and documentation to be provided or updated to help users of the Client implementation to accept and use the new functionality.
Rollout and Notification Policies
Users of the system may require notification of the rollout process, in accordance with any policies that the Client has.
Enhanced Server Capability
Some changes introduced may result in a review and potentially an upgrade of the current server capability, such as increased memory.
Enhanced Storage Capability
Some changes introduced may result in a review and potentially an upgrade of the current storage capability, to accommodate upgrade actions such as the establishment of Elastic Search indexes.
Browser Considerations
Verne retains a policy of support for browsers, and a Verne upgrade may reflect the termination of support for a particular version of a browser. Accordingly a review of current browsers used by the Client might be required.
Work In Progress
Some new functionality may have an impact on existing services that are ‘in-flight’. For example, a new attribute may be made mandatory for submission, which would compromise any applications that have been submitted but not yet approved. Consideration as to whether there are instances of these should be given, and an appropriate policy to manage them put in place.
Breaking Changes in Business Logic
It may be that the upgrade introduces a feature or new functionality that compromises existing business logic or validation. For example, it might be that the upgrade introduces a restriction on the upload and storage of a certain file type to mitigate security concerns. This may compromise existing business logic that currently accepts the upload of such a file type.
