Hybrid Cloud Tutorial

Introduction

There is a need to integrate various systems and services both in-house and in the cloud.

Virtimo offers the INUBIT product for integrating in-house systems. IGUASU is available for connecting various systems and services from the cloud or the Internet.

It is now a good idea to connect these two worlds. The hybrid cloud connection exists precisely for this purpose. This connects INUBIT and IGUASU in an innovative, secure and easy-to-use way.

The IGUASU Connector in INUBIT and INUBIT Processors in IGUASU are available for this purpose.

Client-to-cloud initiated duplex connection

In order to ensure the highest possible security and at the same time minimize the configuration effort of the home network with regard to firewalls and Port activations, the connection between on-prem and cloud is always established by the on-prem system - i.e. INUBIT.

The connection in the form of a Secure Web Socket is then constantly maintained. If it is interrupted, it is immediately re-established by the on-prem side (INUBIT).

This connection can be used to start workflows/flows on the other system both from the on-prem side (INUBIT) and from the cloud (IGUASU).

Maximum security through the use of mTLS

The connection is necessarily always secured by mTLS/SSL. This means that both sides (IGUASU and INUBIT) prove their identity via certificates and the connection is secured via SSL.

The necessary certificates are generated by IGUASU. They are then downloaded for INUBIT and configured on the connection. They only need to be configured in IGUASU, as the necessary part is already available after generation.

Example use cases

As described above, processes of the other system can be started from both sides after the systems are connected. Possible scenarios that could be mapped with this are

INUBIT → IGUASU

A specific system in the cloud is to be called from a local workflow in INUBIT, for which IGUASU provides a simple connection
- Writing a message to an AWS system such as S3 or Kinesis
- Communication with a Kafka system - for example, writing to a Kafka topic and receiving messages from another topic, which then lead to calls to INUBIT workflows
Parts of the processes that have so far been implemented with INUBIT are to be dynamized so that they can map high load peaks via scaling flows in the cloud
- This could apply to parts that generally generate a particularly high load
- But also to areas that only place high demands on the load at certain times - such as shops at Christmas or Versions.E.g. stores at Christmas or the sending of notifications at certain times

IGUASU → INUBIT

The address for a customer is to be requested from a flow in the cloud, whereby the customer data is kept on-prem
- The individual data record can be requested in a very targeted manner. The database itself does not have to be on the Internet for this, but only the one date is transferred via the two securely connected integration products
An internal Service, which should not generally be on the Internet, is required in a cloud flow
The internal SAP or an AS/400 is to be accessed

Contents of this tutorial

To illustrate the interaction of a local INUBIT installation and IGUASU in the cloud, this tutorial will show you how to establish the connection between the two components.

With this tutorial you will learn how to create the required certificates in IGUASU and how they are used for secure communication between the applications. You will also learn how to set up the INUBIT-specific Processors in IGUASU so that messages can be received from INUBIT and data can be sent back to the on-premises installation.

The final flow of the two communication options is shown in the following figure.

Part 1: Configuration of the endpoint

Before you start creating the certificates, the correct endpoint must be configured in IGUASU. This endpoint is used by the IGUASU Connector in INUBIT to establish the connection to your IGUASU instance. Navigate to the endpoint configuration window in IGUASU.

To view the endpoint configuration window, you need the appropriate permissions in IGUASU. If you cannot see the configuration window in the settings, contact your administrator.

Configure an endpoint that has the following properties:

Externally available with TLS termination: The endpoint must be accessible from your INUBIT system and should have TLS termination for a secure connection.
SSL Passthrough Hostname: SSL Passthrough Hostname: The endpoint must be accessible from your INUBIT system and should have TLS termination for a secure connection SSL Passthrough Hostname: Select a suitable SSL Passthrough Hostname. This is the URL that the IGUASU Connector will use in INUBIT.

Part 2: Creating the required certificates and keys

To enable a secure connection between the two components, the corresponding certificates and keys must first be generated. To support this process, IGUASU provides an integrated Certificate managerwhich simplifies the generation of the required elements.

To call up the certificate manager, open the global menu and navigate to the settings in the menu. The menu on the left-hand side now contains the sub-item Certificates, which can be used to call up the manager

The corresponding authorizations in IGUASU are required to view the certificate manager. If you cannot see the certificate manager in the settings, please contact your administrator.

All existing certificates and keystores can now be seen in a tabular list in the certificate manager. As part of this tutorial, a keystore and a certificate are to be generated that can be used for communication between the IGUASU and the local INUBIT installation. The Add Keystore button can be used for this purpose, via which the Generate Private Key/Certificate option is to be selected in order to generate a new key and certificate.

You can set a password for the keystore. Please note, however, that no password should be set for the private key itself for use with the IGUASU Connector in INUBIT, as this is currently not supported.

The newly created keystore is then visible, via which the corresponding keys can be downloaded. The key button can be used to download the private key and the public key/certificate, via which both options are available.

The password that is defined in the first window is for the generated keys, but not for the keystore. This is defined in the second window within the keystore and is also not saved on the server. Keep it safe if you want to open the keystore again.

Both elements created are required when configuring the Services in IGUASU and the connectors in INUBIT, which is described in more detail in the following sections of the tutorial.

Part 3: Configuration of the websockets and SSL services

Once the private and public key or the certificate have been created, the Services required to use the INUBIT Processors can be configured. First of all, the standardRestrictedSSLContextService is required, in which the keystore information is retrieved to enable secure communication between the components.

To configure the keystore, the path in which it is stored must first be specified. To simplify this step, the Expression Language can be used to avoid having to specify the entire path. By calling ${IGUASU_KEYSTORES_PATH}, the stored keystore path is called up so that only the name of the keystore in the corresponding folder needs to be selected. The entry should therefore look like this at this point: ${IGUASU_KEYSTORES_PATH}/<Name des Keystores>.

In addition, the defined keystore password, which was previously defined in the keystore window, is required to call up the corresponding keys. If a key password, i.e. the optional password that is requested at the beginning of the creation of a keystore, was also previously stored, this must also be stored in the Service. In addition, the keystore type can also be stored in the Service. However, as the keystore was created in IGUASU, the default type PKCS12 can remain unchanged.

Once the SSL Context Service has been created, the HybridWebSocketServerController is also required to realize the web socket connection between the two systems. However, the configuration is relatively straightforward, as only the Listening Port and an SSL Context Service are required. The previously created Service can be selected from the drop-down menu as the SSL Context Service. However, the listening port required is the Port that was previously released by the administrator for communication between IGUASU and the INUBIT system. For the purposes of this tutorial, the Port is 9001, but this may be different for you.

With this information, the configured Service should look like this:

It is only necessary to release a Port for IGUASU. This step is not necessary for the INUBIT system.

With the creation of both Services, the Processors required for communication with INUBIT can then be configured.

Part 4: Communication INUBIT → IGUASU

This section explains how messages can be sent from INUBIT to IGUASU in the cloud.

4.1 Receiving data with the ListenInubit Processor

To enable communication between the two systems, the corresponding elements must first be created in IGUASU in order to receive and respond to the data. Data is received from an INUBIT system via the ListenInubit Processor, which will serve as the starting point of the flow in IGUASU.

Four properties are available for configuring the Processor. The first setting option is to define the Listener Identifier, which can be used to differentiate and identify the listeners.

A Listener Controller must also be defined. The previously created HybridWebsocketServerController Service is used for this setting option, which was used to configure the Ports, among other things.

A name must also be specified for the Processor, which is also used to identify the flow. The entry that is defined at this point is visible in INUBIT later on when configuring the IGUASU connector and thus makes it possible to find the correct entry point in the cloud.

In addition, a description must be stored, which is also visible in INUBIT and thus also makes it easier to find the correct listener in the other system.

With the completed configuration, the Processor should look like this:

4.2 Processing the data and the RespondInubit Processor

Once the data can be received by the ListenInubit Processor in IGUASU, processing can take place. At this point, it would be possible to create a complex flow, integrate external Services in a simplified manner and create various branches of processing. However, in order to keep it simple in the context of this tutorial, as the focus is increasingly on the communication between the two systems, only a simple processing step should take place.

For this purpose, the ReplaceText Processor is used to change the FlowFile content. The content should be changed completely, which is why the Replacement Strategy Always Replace should be used. The `Replacement Value' can be any text, as it is only used here to indicate the change by IGUASU in INUBIT. In this example, The IGUASU Response at was entered with the current time. A possible configuration can be seen in the following figure.

The RespondInubit Processor is used to resend the data to INUBIT at the end of processing or to generate a response in general. However, the configuration of this Processor is comparably simple, as only a Listener Controller needs to be defined. Similar to the ListenInubit Processor, the HybridWebsocketServerController Service is used here.

This completes the flow in IGUASU for receiving and processing the data from INUBIT.

4.3 Configuration of the IGUASU connectors in INUBIT

To send messages from a local INUBIT installation to IGUASU in the cloud, a workflow must first be created in INUBIT. To simplify communication between the two systems, INUBIT offers the IGUASU connector for this purpose, which can be used to establish the connection via websockets.

To configure the IGUASU connector in INUBIT, the URL via which IGUASU can be reached and the corresponding certificate and key created in section 1 are required. A comprehensive description of the configuration of these elements can be found in the INUBIT documentation in the IGUASU connectors section.

If no IGUASU listener is displayed when configuring the connector: Make sure that the Processor’s state is set to RUNNING so that it can be called. To achieve this, the Start command must be selected.

Now that the configurations in INUBIT have also been completed, the workflow can be started, which generates data in INUBIT. This information should then be received in IGUASU by the ListenInubit Processor, which is then visible as a FlowFile.

After the content has been changed by the ReplaceText Processor, the data is then returned to INUBIT, where it is displayed with the new text and the additional metadata that was added in the form of attributes in IGUASU.

At the end of the created flow, the data in IGUASU should look like the following figure:

Part 5: Communication IGUASU → INUBIT

While the third part of this tutorial dealt with communication that is started by INUBIT and in which a response was sent back by IGUASU, it is also possible to initiate a workflow through IGUASU.

5.1 IGUASU connector as listener

In order to map processes in which IGUASU calls an INUBIT workflow, the system also offers an individual Processor. However, to receive this data from IGUASU, an IGUASU connector must first be created in INUBIT to which the data generated in IGUASU can be sent. As before, you can find all information on configuration in INUBIT in the IGUASU connectors section.

5.2 Transferring data with the InvokeInubit Processor

Once the configuration in INUBIT has been completed and a listener is available to which data can be transferred, the configuration in IGUASU can be carried out. The InvokeInubit Processor can be used to send requests from IGUASU to INUBIT. To demonstrate this in this tutorial, data must first be generated in IGUASU that can be transferred to the INUBIT system.

As in other tutorials, the GenerateFlowFile Processor can be used to create a simple FlowFile. In order to fully map the transfer of data, a unique content and an attribute should be created for the corresponding FlowFile.

Therefore, the Custom Text option is configured, in which, for example, the following text can be inserted: This is the text from IGUASU at ${now()}.

In addition, an attribute can be defined, which is also transferred to INUBIT as metadata and is then available in the system as a variable. For this purpose, a dynamic property can be used to create an attribute for this purpose. The unique ID of the FlowFile is suitable as an attribute, for example, so that Value with UUID: ${UUID()} can be entered.

The complete configuration of the GenerateFlowFile Processor then looks as follows:

Configuration of the GenerateFlowFile Processors

The InvokeInubit Processor is then created, with which this generated data can be transferred to INUBIT. A Listener Controller must first be defined again for the configuration, for which the previously created HybridWebSocketServerController is used again.

Next, the Choose Listener option must be configured, whereby two different options are available: On the one hand, the option Use 'Listener Identifier' field can be used to specify the ID of the listener in INUBIT to which the FlowFile is to be transferred.
However, if there is already a connection between the two systems, all listeners should be available in the drop-down menu of the listener identifier, where you can select the previously created listener.

If this listener selection is not available to you, it is recommended that you first complete part 3 of this tutorial - this is where a connection between the two systems is established. The previously created listener should then be available to you in the selection.

You can also optionally configure the Target unavailable setting, which allows you to define the behavior in the event of connection problems.
The Route in "unavailable" relation option can be used here to define a branch with further processing steps. For the purposes of this tutorial, only one Funnels is to be inserted at this point, which is to serve as the end point.

The final workflow then looks as follows:

If the GenerateFlowFile Processor is now executed with Run Once, the defined data is generated and then sent to the created listener in INUBIT.