Remote Services: Data & Server Reverse Connections¶

Remote Services (RS) support reverse protocol routing, where apps residing on Devices in a Device Network may connect to server apps or data residing in a Service Network using customizable IP-based protocols. RS tags such protocols as "Data & Server".

Typical use cases are:

• Devices issue tickets with a ticketing system located in a Service Network such as a headquarter
• Devices access data storage location in a Service Networks such as a headquarter

Info: With reverse access Devices access apps or data in Service Networks. However, apps and data located on these acting Devices may still be accessed in parallel by apps residing in Service Networks, if the required Protocol Applications were setup and if necessary access rights were granted.

The following examples assume, that the required Devices named PC m01 or PC i02 were created and registered with RS. We further assume, that PC i02 runs a Device Endpoint and a client for a ticketing system. Similarly, PC m01 runs a Service Endpoint and a server of the used ticketing system. The underlying use case is PC i02 raising a ticket on PC m01.

Example: Administrator Creates Protocol Application Using "DTT Reverse"¶

With RS the Device PC i02 can already be reached from within a Service Network by standard protocols such as Remote Login. In order to also allow the Device to connect to apps or data located in a Service Network we leverage Dynamic Transparent Tunnel Reverse (DTT Reverse) for doing so.
First of all, an administrator has to create a new Protocol Application similarly to creating other such templates. This is done via RS V2 by selecting the blue box icon in the top left corner and then clicking on "Create New Protocol Application".

The RS Protocol Hub opens and displays all available protocol templates. The ones belonging to required "Data & Server Option" are tagged accordingly. Please select Dynamic Transparent Tunnel - Reverse.

In this step we assign the name Ticketing Server Access to the new DTT-R Protocol Application. We also select a Target Endpoint residing in a Service Network from the provided list. In this example we select PC i02.

Next, we assign the required port mapping and target host (here: localhost). Press "Save".

The created Protocol Application of type DTT-R and named Ticketing Server Access is now available in the catalogue and maybe assigned to Devices.

Example: Site Owner Assigns "DTT Reverse" to a Web Server Host¶

In our sample setup the PC m01 located at site Munich hosts a ticketing client. The responsible site owner now assigns it with the previously defined DTT-R Protocol Application Ticketing Server Access, which connects to Device PC i02 at site Istanbul and which hosts the corresponding ticketing server.

This is done via the hexagonal Device icon on the top left and then selecting PC m01 from the organizational tree. Click "Assign Protocol Application".

Select Ticketing Server Access from the list of available Protocol Applications. Then click the blue arrow icon next to it.

Now our device PC m01 was assigned with Ticketing Server Access. Click "Save".

The newly assigned Protocol Application Ticketing Server Access is now ready for use.

Example: User Connects Ticketing Client on Device to Ticketing Host¶

The RS user leverages RS V2 and selects the device menu via the hexagonal device button on the top left. Next the Device PC m01, which hosts the ticketing client, is selected. Press the blue chain icon next to Ticketing Server Access in order to establish a connection.

The client application on PC m01 at site Munich is used to create a ticket. Click "Submit".

A confirmation message indicates, that the ticket was received by the ticketing server (The window in the background displays diagnostic progress messages used in this demo setup).

The newly created ticket can then be displayed in your used ticketing server running on PC i02 at site Istanbul. The ticket may now be assigned to a service expert or other tools for further processing.