5. Check upgraded data
It is highly recommended to back up each environment once it has been upgraded.
 
The standard installation and upgrading process takes care of all the conversions that can be automated. Technically speaking, conversion success is guaranteed by:
1. The correct execution of the environment automatic upgrade processing.
If errors are met at this step, the migration process must be stopped so that a diagnosis is made. Carefully check the Mega error log.
2. The correct execution of all mandatory conversions for the system database.
If errors are met at this step, the migration process must be stopped so that a diagnosis is made.
3. The correct execution of all mandatory conversions for each data repository.
If errors are met at this step, the migration process must be stopped so that a diagnosis is made.
 
After complete execution of the migration process, it is highly recommended to check data and customizations through:
First control of migration: run a quick tour to check that data looks correct.
Check of data consistency: run utilities to enforce rules regarding data structure.
Other checking indications.
 
5.1. Check conversion log
When environment is upgraded and conversions are run, error can occur.
A log megaerrYYYYMMDD.txt is generated in %ProgramData%\MEGA\Logs.
Read the log for the date/time of environment upgrade to detect possible errors.
 
5.2. First control of migration
It is highly recommended to run a quick tour and check that upgraded data looks correct. Of course, this kind of check cannot be exhaustive, but it usually enables to have a first feedback and quickly identify certain migration issues.
 
Example of scenario:
1. Open a private workspace (ex-transaction).
2. Browse through objects using query tools, navigation trees and diagrams.
3. Perform insignificant updates (ex: change a character in a comment value, slightly move an object in a diagram...).
4. Dispatch private workspace.
 
5.3. Check data modelling consistency
In previous versions, many things were tolerated, although not recommended. In order to ensure better consistency, there is a need for a thorough review of the repository content and, potentially, some cleaning and tidying tasks to perform. This should be considered as a separate project.
 
5.4. Other checking indications
If extensions were made to the metamodel, they must be reviewed regarding the structuring rules described above.
 
If customizations have been made (property pages layer, diagram configuration layer, templates, programs based on script APIs…), a specific check is required based on initial customization specifications. As customizations are often based upon standard layers, they may not be ready to use, and they may have a different look and feel. This check requires functional and platform development skills.
 
The below list is not exhaustive.
 
Topic
Comment
Archimate
From HOPEX V5.0, Archimate V3.1 is mandatory. A module 'Archimate V3.1' must be installed and data need to be converted.
Compilation of environment
It is essential for consistency of data and performances that all layers (metamodel, technical data and permissions) are compiled. If you have a doubt about compilation (warning, slow performance) recompile the three layers (metamodel, technical data and permissions) together.
Custom API script code (1)
It is now recommended to use web services (REST API)
API script are fully supported in HOPEX V5.0.
If several HAS instances exist on a machine, only one can run components using Administration API script at a given moment.
Before each execution of components using Administration API script, it is required to reference Mega.Application
This is done using a powershell script (HOPEX-regserver.ps1) installed at the root folder of the HAS Instance.
Besides it is recommended to review the customized macros and applications using API script, in particular for Administration APIs. Review should be based on initial functional specifications.
Custom authentication (1)
It is required to review authentication in case of fully customized authentication provider. Review should be based on initial functional specifications.
Custom questionnaire templates converted to Standard Mode (questionnaire builder) (1)
Custom questionnaire templates are automatically converted to new format
It is necessary to check if converted templates are fully compatible. A specific report enables to understand this. If ever specifications of custom questionnaire templates cannot be fully converted automatically, a change of customization will be required on project resources.
See document ' How to Migrate to Questionnaire Builder ' for more details.
Display of report in property pages, tiles,widgets
To prepare a future compatibility with a Content Security Policy (CSP), it is highly recommended to review MetaPropertyPage/Tile/Widget objects displaying reports. Load is reduced for a developer. A document 'Updating Virtual reports HOPEX V5' is available in the online documentation
Edition of Report Templates
It is no longer possible to run Report in Windows Front-End. Use Web Front-End and profile HOPEX Customizer Publisher instead.
GraphQL
Deployment of GraphQL is different
Core GraphQL modules are installed by default with bundle HOPEX. GraphiQL is an optional module named HOPEX GraphQL IDE. Authentication mode is different. An API key is required instead of bearer token.
Calls to GraphQL queries are different in HOPEX V5.0. It is required to review calls in third party applications.
HTTP deployment
Each new deployment should be made in HTTP/SSL mode (communication between HTML browser and HOPEX Front-end). This is a standard security practice.
MEGA is not committed to investigate all errors met with HTTP mode.
If no SSL certificate is available when installing, installation can be made temporarily in HTTP mode. It must be configured to HTTPS/SSL mode before switch to production.
MetaAttribute format (1)
With recent versions, a control checks that Physical Format (set on SQL Server column) matches Meta Format (set on MetaAttribute). When a mismatch is detected, an error is usually displayed such as Inconsistent format for MetaAttribute "EA4430554424043A" (304630847021378116). Physical Format (X). Meta Format (L).
Previously, code was tolerant to mismatch.
See KB 00009355 in MEGA Community for more details
Profiles management (1)
It is recommended to review the profile execution for custom profiles. Review should be based on initial functional specifications.
Certain Profiles have been removed in HOPEX V5.0.
Public/Private workspace
From HOPEX V5.0, all web desktops are configured with public workspaces except the one used by profile HOPEX Customizer (required for customizations).
Behavior of a desktop varies with its configuration
Public workspace: updates are made public automatically so that users share the same vision.
Private workspace: end user has its private vision and can decide to refresh, discard or dispatch it.
Report Templates (1)
Certain standard report templates (HTML) are removed from standard: they are no longer maintained by MEGA.
Situation varies with the history of the environment.
See KB 00008963 in MEGA Community for more details.
Searchable Metaclass
List of MetaClass available with tool Search by Object Type can be different as filtering using 'Technical level' (option 'Metamodel access') setting is no longer considered. Tuning of profiles can be required using permission CRUDS (searchable).
See online documentation: HOPEX Administration (Web) > Managing objects > Managing UI Access (Permissions) > Object UI Access Values.
Technical Metaclass
List of MetaClass available with certain tools can be different as filtering using 'Technical level' (option 'Metamodel access') setting is no longer considered. Tuning of metamodel can be required using property 'Meta Usage' (Business, Technical) on MetaClass.Option ‘Display Technical Metamodel' enabled to display systematically MetaClass flagged as 'Technical'.
See online documentation: Common Features > Querying Objects > Advanced Search > Configuring the Search Tools
Web Desktops (1)
It is highly recommended to switch to Universal Desktop V2 configuration
When developing new desktops/profiles
When migrating data to HOPEX V4 or higher
Web services
It is required to review web services execution. Review should be based on initial functional specifications.
Information Architecture
If you do not use the Solution 'HOPEX Data Governance' in HOPEX V5.0 (compatibility with 'HOPEX Information Architecture' only), it is necessary to run the utility MEGA Repository - Conversion of Profile 'Data Asset Manager' to 'Data Architect'.
Then use profile 'Data Architect' instead of profile 'Data Asset Manager' used in HOPEX V4.0)
 
(1) If the above indications lead to different changes in customizations (resource and/or code), it is necessary to rebuild a customization package with a new version and deploy it again in the HAS instance.