Important Notes When Upgrading from HVR 5

This section describes the underlying changes introduced in HVR 6 when compared to the HVR 5.x versions. The fundamental change is that HVRGUI in HVR 5 has been migrated to the web application that comes with a completely new user interface and REST API functionality. Major changes were also introduced to the process architecture, the structure of catalog tables (renamed as repository tables), CLI commands, actions, jobs, import and export system, etc.

• HVR version 6.x is not compatible with the versions 5.x and 4.x. So, ensure that HVR version 6.x is installed on the Hub machine and Agent machine.
• Only HVR Agent installation is supported on the Unix platforms (aix_6.1-powerpc-64bit, solaris_10-sparcv9-64bit).

For the instructions to upgrade from HVR 5 to HVR 6, see section Upgrading from HVR 5.

Functionality Removed in HVR 6

• Cloud-licensed agents (cloud-licensed hubs still exist).
• HVR hub on Unix (non-Linux).
• HVR for MacOS platform.
• Documentation set bundled inside our product.

Architecture

The following image shows the differences (highlighted in blue) between the process architectures in HVR 5 and HVR 6.

Licensing

In HVR5, applying an HVR license is a separate step performed after HVR installation. After receiving the license file by email, a user has to save into the HVR_Home/lib/ directory on a hub machine.

In HVR 6, applying a license file is part of the Hub System setup workflow (UI and CLI).

Installing HVR 6

In HVR5, there is only one workflow for installing HVR 6 as a hub or as remote agent.

In HVR 6, the redesigned installer for Windows splits the installation process into separate workflows:

• Installing HVR Hub

• Installing HVR Agent

• Neither: HVR can only be used for command-line control of a remote hub machine. For more information, see Remote CLI.

HVR Agent

In HVR 6, the agent configuration workflow is now a part of a unified system setup workflow that allows to easily configure a secure, encrypted and properly authenticated connection from a hub to an agent. This is implemented by introducing agent setup modes and agent authentication methods. For more information, see section HVR Agent.

Agent Authentication

The following agent authentication methods are available in HVR 6:

• Limiting access from hubs with only specific hub certificates, so that the agent only accept connection from a particular hub machine (this allows anonymous connections).

• Agent user authentication (using agent user credentials)

• Combination of the above two methods

For more information about agent authentication, see section Agent Connection Modes.

Agent Setup Mode

Agent setup mode is used for configuring the HVR Agent service. There are two types of agent setup mode:

• Time-based setup mode

• Token-based setup mode

For more information, see section Agent Setup Mode.

Catalog Tables

The HVR 5 'catalog tables' located inside a hub database are renamed as 'repository tables' located inside a repository database for HVR 6.

• The HVR 5 tables HVR_CONFIG_ACTION, HVR_JOB_RESOURCE*, and HVR_JOB_PARAM were removed in HVR 6.
• In HVR 6, because a repository database can include multiple hubs (multi-tenancy), a column called hub_name was added as a key column to almost all repository tables for distinguishing between jobs, database objects (channels, locations, tables, etc.) and files relating to a particular hub.
• All changes to the repository tables are tracked in the HVR_COUNTER table.
• New configuration tables are added, containing information about users (HVR_USER), user properties (HVR_USER_PROPERTY), user hub properties (HVR_USER_HUB_PROPERTY), repository properties (HVR_REPOS_PROPERTY), hub properties (HVR_HUB_PROPERTY), and location properties (HVR_LOCATION_PROPERTY).
• Each definition table (HVR_CHANNEL, HVR_TABLE, HVR_LOC_GROUP, HVR_LOCATION, HVR_COLUMN, HVR_ACTION, HVR_LOC_GROUP_MEMBER, HVR_LOCATION_PROPERTY) has two time-dimension columns insert_tstamp and delete_tstamp to better manage changes to the repository tables. This time dimensional model allows a user to make interactive changes to a channel definition without immediately introducing them into replication.

HVR 5 allows you to make changes to the definition tables directly using SQL statements, e.g. a user can insert a column into the HVR_COLUMN table. HVR 6 does not support direct modification of the definition tables using SQL statements. Instead, a user has three options for making such changes: through the User Interface, Command Line Interface (CLI), or REST API.

See section Repository Tables.

The following diagram shows the changes that have been introduced in the repository tables. The tables and columns highlighted in brown are those migrated from HVR 5. The ones highlighted in blue are new tables and columns added in HVR 6.

HVR_CONFIG Reorganization

The following image shows the difference between the HVR_CONFIG directory structures in HVR 5 and HVR 6. Because of multi-tenancy architecture introduced in HVR 6, the HVR_CONFIG directory is now partitioned into hub sub-directories. The benefit of the new HVR_CONFIG structure is that it matches the REST API object naming structure.

HVR_HOME Reorganization

The following image shows the difference between the HVR_HOME directory structures in HVR 5 and HVR 6. One significant change is that the agent directory has been renamed to plugin in HVR 6. The plugin scripts are stored in the plugin_examples directory, and to activate them, you need to explicitly move them to the HVR_CONFIG/plugin/ directory.

User Interface

The “thick” graphical user interface (HVRGUI) has been replaced with a "thin" web-based user interface. The HVR 6 web-based user interface is designed to be visually appealing and intuitive providing a better user experience.

One advantage of the new user interface is that it assists both novice and expert users. In the HVR 5 GUI, both the essential features and advanced functionality appeared all at once, whereas in HVR 6, they were separated into two layers. A layer of essential functionality is initially visible to a user so that a novice user who has no experience in HVR product could quickly set up a replication channel ready for production. At the same time, for the expert users who have solid knowledge in HVR, the advanced functionality is smartly hidden below the essential features and can be expanded if needed.

Another feature that makes HVR 6 user interface easy to interact with is that certain input fields that are only required once a user has chosen a specific option or function remain hidden until the user has selected that option, they then expand underneath. This helps users to focus on the things they need to fill over things they might not need.

The HVR 6 user interface is very informative, it provides short descriptions of basic HVR concepts and options and explanatory workflow that aids a user in setting up a replication channel, creating a location, and understanding the HVR system as a whole.

See section User Interface.

Command Line Interface

In HVR 5, the command line requires user credentials to connect to a hub database (e.g. Hvrinit -h sqlserver -u myuser/pwd hubdb mychn). In HVR 6, options -h (database class) and -u (database user and password) were removed from all the commands that used to require them.

The HVR 6 command line interface includes two types of command lines:

• Direct command line - authentication to the HVR system is done using the credentials of an hvr user logged in to a hub machine). In this case, only the hub name is needed to run a command (e.g. hvractivate myhub mychn).
• Remote command line - authentication to the HVR system is done via the HVR's REST interface. In this case, a user needs to use command hvrlogin -R to log in, the authentication token is stored for a certain period of time in ~/.config/hvr. Option -R must be used to run commands (except hvrhubserver) though the remote command line.

New option --help along with an HVR command displays a short description of all options available for a specific command.

For more information, see section Command Line Interface.

Commands

The following commands were either removed or replaced with new commands:

Hvrmaint

The HVR 5 command Hvrmaint has been split into two parts in HVR 6:

hvralert

Runs outside HVR Hub Server (by hvralertmanager)

Set up inside the user interface or via the command line interface (hvralertconfig)

Alert messages have hypertext links

Latency SLAs defined inside a channel

• action Scheduling with parameter LatencySLA

hvrmaintjob

• Automatically rotates log files

The following are HVR 5 Hvrmaint options that have been converted or removed in HVR 6.

REST API Interface

HVR REST API is a completely new interface implemented in HVR 6 providing about 200 Rest API end-points grouped into about 20 'interfaces'. Most REST end-points accept and return JSON requests and responses.

An important purpose of the REST API is that it provides a security layer, as it is responsible for user authorization. Each REST interface is assigned an access level, e.g. you need a ReadExec access level on a hub to post a compare event.

Location Group Membership

In HVR 5, a location can be a member of multiple location groups in a channel.

HVR 6 imposes the following restrictions on the locations included in a channel:

• a location must be a member of a location group
• a location can only be a member of one location group.

Actions

In HVR 6, backslash has been removed before the parameter name of an action. For example,

• HVR 5: /IgnoreCondition in action Capture
• HVR 6: IgnoreCondition in action Capture

The HVR 5 action LocationProperties and its parameters, certain parameters of actions Capture and Integrate, as well as some environmental variables were converted to Location Properties in HVR 6. The complete list of changes are listed in the following sections below.

Action Scope

HVR 5 allows defining actions for a specific scope, e.g. actions can be defined for both a location and a location group, or a location group and a channel. In total HVR 5 allowed 24 combinations of action scopes. In HVR 6, this behavior is changed.

In HVR 6, the following action scopes are supported:

• Channel scope: all channels (*) or a specific channel
• Location scope: all locations (*) or a location group or a specific location
• Table scope: all tables or a table group or a specific table. Requires a specific channel to be selected in the channel scope.

Actions Capture and Integrate defined on a specific location will be effective in a channel only when the location is a member of the channel's location group.

Actions and Parameters

The section lists HVR 5 actions and action parameters that were either converted to the location properties, renamed, removed, or replaced with new parameters in HVR 6.

Data Types Changes

The change in data type for the following expression must be considered when upgrading from HVR5 to HVR6.

hvr_integ_tstamp

In HVR 5, the data type for hvr_integ_tstamp is inconsistent across different location types. However, in HVR 6, this inconsistency has been resolved by standardizing the data type to TIMESTAMP(3) WITH TIME ZONE or the closest equivalent if the database does not support this type.
For example:

• In BigQuery, the data type in HVR 5 is DATETIME, but in HVR 6, it is TIMESTAMP.
• In Oracle, the data type in HVR 5 is TIMESTAMP(6) WITH TIME ZONE, but in HVR 6, it is TIMESTAMP(3) WITH TIME ZONE.

Since the data type of hvr_integ_tstamp differs between HVR 5 and HVR 6, the action definition ColumnProperties /IntegrateExpression= hvr_integ_tstamp may no longer function in HVR 6. In such cases, you may need to perform casting operations or change the data type in the target column of HVR 6. For example, if the target column type in BigQuery is DATETIME and you are unable to change the column type to TIMESTAMP on the target side, you would need to use a cast operation similar to CAST({hvr_integ_tstamp} AS DATETIME) instead of simply using {hvr_integ_tstamp} in /IntegrateExpression in HVR 6.

Jobs

HVR job is a process that performs a certain task, such as activating replication, capturing/integrating changes, refreshing data, comparing data, etc.

Import and Export

HVR 6 import and export system offers a lot more flexibility and powerful features than that of HVR 5. For example, in HVR 6, you can download an action and reload it into a different channel, you can export a file containing properties to connect to a remote agent and share it with your colleagues, you can export changes made to a channel definition into a file and apply those changes to a different hub.

The following table reflects major changes to the HVR export/import system.

Environment Variables

The following HVR 5 environment variables were converted to the location properties in HVR 6.

Properties

Properties is a new concept in HVR 6 that specifies the characteristics/attributes of the HVR components:

• Agent Properties
• Alert Properties
• Hub Properties
• Hub Server Properties
• Location Properties
• Repository Properties
• User Properties

The following table shows the place where the properties for each HVR component are stored and the HVR commands for managing these properties.

Snapshots

HVR 6 allows you to create a snapshot of an HVR hub and save it to a zip file that stores all the data related to the hub, i.e. the hub snapshot metadata, information about channels, locations, location groups, tables, columns, actions and information from the HVR_CONFIG directory (log files, enroll files, capture state files, catalog cache files, etc.). The snapshot can be used to move the hub to a different repository, for reporting purposes, or for sharing with other users.

Smart Links

User interface dialogs contain links pointing to the relevant documentation pages, as well as links that can navigate you between different user interface pages.

The Log Viewer dialog displays smart links that can navigate you to the relevant UI pages. For example, clicking the name of a compare or refresh event will open the appropriate Event Details page.

Related Articles

• Migrating Channel from HVR Version 5

• Upgrading HVR from Version 5 to 6