Hybrid Service Installation - the Best of On-Demand and On-Premise

We are very happy to introduce you to the new Hybrid Service deployment for RapidiOnline. With this release it got much easier to deploy the RapidiOnline Service as a Hybrid Service installation.

What is a Hybrid Service anyway

You may think of the Hybrid Service deployment as a combination of an on-demand Service and an on-premise installed product. With the RapidiOnline Hybrid Service, you get the best of both worlds - you get our on-demand configuration interface that you can access from anywhere and our centrally run monitoring and alerting features combined with a 1-click on-premise deployment of configuration changes and a deployment that runs totally independent of an internet connection.

Who would need the Hybrid Service

The Hybrid Service makes most sense if you have two or more locally installed systems that you need to integrate or replicate data between. With the Hybrid Service your data will not leave your network (provided that both source and destination are in your local network) and this of cause speeds up the transfers compared to the normal RapidiOnline Service. You can still use our RapidiConnector technology to compress and pack data if you have remote offices/installations that can be reached via a private VPN or even via the Internet.

If you have strict security rules that your data must not leave your local network, the Hybrid Service will also ensure this.

image 1: illustration of the hybrid service deployment with Microsoft Dynamics NAV systems

How is the Hybrid Service different from the normal deployment and what has changed

At RapidiOnline we have offered a Hybrid Service deployment option for a couple of years now and we have a number of customers using the Hybrid Service. The former Hybrid Service deployment option was based on that we would move the entire configuration database and the service engine to the customer's server. The MyRapidi interface was then directed to look in the local configuration database instead of a central one. This could lead to some delays when working with the MyRapidi interface.

Below are some highlights on how the Hybrid Service deployment differs from the normal RapidiOnline deployment and from the former Hybrid Service deployment:

• Most of the configuration (Connections, Transfers, Groups etc. are stored in a central configuration database - as with our normal deployment). This gives much faster response times when working with Transfers for example.
• The Log, Schedules, RTI are stored in a MySQL database on the customers server. This ensures good performance when running Rapidi and independency from the internet.
• The local Rapidi (Hybrid) service reads configuration information from a file in the local file system (the file contains all transfers, fields, connections, groups etc.)
• The "Activate Changes" process will save the central configuration to a file, download that file to your server, copy it over to the "active" config file and make the local Rapidi process reload the "active" file. This is generally fast - around 10 seconds.
• The configuration app (MyRapidi) remains the same (just faster to work with) - it will look in your local MySQL database for Schedules, Log, RTI and centrally for the rest.
• The Read Design process will do the read design locally, but sends the result to the central server and stores it in the central database. 
• It is now the Rapidi.exe (Rapidi64.exe) that can also run the local (hybrid) process locally.
• The Rapidi.exe can now be installed as a Windows Service (either 64 bit or 32 bit) using our new Rapidi Service Controller. The Rapidi Service controller handles installation of both Hybrid services and normal RapidiConnector services.
• The Rapidi.exe no longer needs to run with a Windows user that has Administrator rights. It can run under a normal Windows user account. Admin rights are only needed during installation and setup.

To achieve all of the above, we have made a number of changes. If you are interested in those technical details please read through the list below: 

1. When writing the configuration to a file (what we call a frozen configuration file), we now include the Configuration Database Type so that we know what field names to use/expect in the file.
2. We have updated the Frozen config file version to 2 (was 1) - this means that old versions of Rapidi will not be able to use the new configuration files. The new version of Rapidi can read both new and old configuration files.
3. We now pack and compress the configuration before writing it to the file. This has resulted in files that are in general approx. 7 times smaller (going from for example 3,3 MB to 0,5 MB). 
4. The "Activate Changes" feature will now work differently for Hybrid Services. It will write the centrally stored configuration to a file (with a file name including a timestamp - e.g. config_20161020134804.frz), then download that file to the locally installed Hybrid Service, and finally ask the locally installed Hybrid Service to use the new configuration file (copy it over to config.frz and load it as the new current configuration).
5. The configuration file contains an expire date - the service expire date that you see on the Dashboard. The expire date of a service is checked when running Transfers. After prolonging your service, you need to do "Activate Changes" in order to get the new expire date into the configuration file and allowing the Rapidi Service to continue to run Transfers and Schedules.
6. When loading a new configuration file, the Hybrid Service will first ask the Scheduler to stop and then wait for the Scheduler to finish any current job (and stop). It will wait for up to 30 minutes by default before giving up (messages will be shown during the waiting time). The default value of 30 minutes can be set in the Rapidi.cfg file (the parameter is called "ActivateChangesMaxWaitTimeSeconds" and the default value is 1800).
7. The "Read Design" feature now works differently for the Hybrid Services. It will ask the centrally installed service to do the ReadDesign. The centrally installed service will then ask the Hybrid Service to start the ReadDesign (either by itself or through a RapidiConnector). The Hybrid Server will return the design to the central Service which will then store it in the configuration database centrally.
8. There is a new start up parameter for a central service that should run as a Hybrid Service - its called "HybridCentral". When the central service is started in this way, it will omit starting the Log, Scheduler, RTI and LinkStorage interfaces and will also leave any passwords in encrypted state (it does not have the correct key to decrypt them anyway as passwords are encrypted by the local Hybrid Service). A central service started in this way can do ReadDesign, ActivateChanges and File Upload/download but will not run any Schedules or Transfers.
9. The Hybrid Service is now reporting the computer name and the Windows Service name back to MyRapidi. It is visible when using the "Get Status" feature on the Dashboard.
10. The Hybrid Service can now be installed using the Rapidi Service Controller. There is a check box on the "Install Service" page called "Hybrid Service". When you check this, the name of the service will be <serviceno>_HYBRIDSERV and the parameters in the Registry for the new Service will be adapted to let the Rapidi.exe run as a local Hybrid Service.
11. When the Hybrid Service is started first time right after the installation by the Rapidi Service Controller, it now accepts to start without the any configuration (including without the configuration file - config.frz). During installation with the Rapidi Service Controller, you should enter a username and password (normally HYBRIDSERV and a uniquely generated password that you get from RapidiOnline Support) and if there is no configuration to load, the Hybrid Service will accept connections with the above username and password. This allows for the central service to connect and download and activate the first configuration file (during the first "Activate Changes").
12. Both the Log and the Scheduler now uses UTC times no matter what timezone the server is set to use. This ensures that date and time fields are always shown and stored correctly as the MyRapidi interface assumes that all times are UTC and automatically converts these to local times using information from the MyRapidi users profile (select settings in the top right corner in MyRapidi to see your time zone settings).
13. RapidiOnline Support is able to remotely upgrade your installed Hybrid Service as well as any RapidiConnectors connected to your Hybrid Service (we will not upgrade anything unless you ask us to do it - please submit a support case to initiate this).
14. RapidiOnline Support is also able to run traces on the Hybrid Service and any connected RapidiConnectors to help you resolve any issues (tracing is only done after specific acceptance from your side). This helps ensure a quick resolution of any issues that you might encounter.

The new Hybrid Service installation is available now but you need to be using version 4.0.01f or later.

Please contact RapidiOnline Support to arrange an installation or upgrade to the new version. 

The Hybrid Service deployment is available in our Enterprise edition (either the RapidiOnline Cloud Integration or the Replicator 7.0).