Configure a remote client
You can configure a remote client after you have installed and run a remote client for the first time.
After that you can configure the remote client:
The remote output client can be configured by modifying the file
<INTERFORMNG2_HOME>/profiles/default/settings/remote_output_settings.jsonThe file is created automatically when the service is started for the first time. The default configuration is:
{
"protocol" : "https",
"host" : "localhost",
"port" : 8086,
"tenant" : "home",
"locationId" : "Default",
"username" : "default",
"password" : "password",
"notifier" : null,
"chunkedDownload" : false,
"chunkSizeBytes" : 16384,
"maxChunkErrors" : 10,
"dualMode" : false
}Protocol
"protocol" can be "http" or "https" and this should match how the main application web interface is accessed.
Host and Port
"host" and "port" should match the host and port for the main application web interface.
NOTE: You should probably change the value into 8086, to match the port number used for InterformNG2.Tenant
"tenant" must be the name of the tenant to connect to. This is required when using notifications. If notifications are not used and the user only has access to one tenant, then it can be left out.
LocationId
If multiple remote output clients (for the same tenant) are installed in different locations, and should pick up different outputs, then the "locationId" should specify the location of this remote client. Only outputs sent to this location id will be picked up by the client.
If only one remote output location is needed, then this is best left at "Default".
Username and password
"username" and "password" must be the username and password of the user that will be used to authenticate with the main application (as described above). That means, that this user and password need to be defined on the InterformNG2 host on the selected tenant. This user need to be specified on the tenant of the host with the user role, web service.
LocationId
If multiple remote output clients (for the same tenant) are installed in different locations, and should pick up different outputs, then the "locationId" should specify the location of this remote client. Only outputs sent to this location id will be picked up by the client.
If only one remote output location is needed, then this is best left at "Default".
- ChunkedDownload
If the remote client is used on a network that is know to be unstable, then chunked download can be enabled by setting chunkedDownload to true. With this feature enabled, the output items will be downloaded from the server in a number of smaller chunks rather than fetching the entire item in one go. Any failed chunks will be retried individually. On an unstable network, this can increase the likelihood of an output item being successfully transferred. However, enabling this feature will have a negative performance impact, so it should only be enabled when really needed. The size of the chunks can be adjusted with setting chunkSizeBytes. A lower value will increase the likelihood of individual chunks being transferred successfully, but will also make the overall download time longer. The number of times that a chunk will be retried can be set with maxChunkErrors. Retries happen with exponentially increasing delay. After one failure, a retry is done after 1 second. After 10 failures a retry is done after 29 seconds. The maximum time between retries is 30 seconds.
- dualMode
The default value for dualMode is false, which indicates, that this options is disabled. If you change the value into true, then the client will use both notifications (if setup) as well as pulling. With this setting the client will use a bit more bandwidth, but will allow more stable printing on unstable connections. This was added to solve a case with a faulty VPN connection, that simply "hanged" the notification making the remote client believe it was still alive.
- Notifications
Without notifications the remote client will poll the InterformNG2 host every 30 seconds to verify if there are any pending output requests. If you activate notifications the connection between the host and the client will be held and the client will react instantly to a output for the designated output client.
If notifications are enabled on the main application and on the tenant that this client connects to, then the client needs to be configured with notifier settings.
Notifications for socket based notifications
If the remote client is to
After "notifier", replace null (in the example above) with: {
"host": "localhost",
"port": 8100,
"accessPassword": "password",
"keystorePath": "internal:remoteoutput.jks",
"keystorePassword": "password"
}
Host
"host" should be the same as above (maybe we can remove this, since it seems to be duplicate).
Port
"port" should be the port that was configured as notifier port in the main application settings.
AccessPassword
"accessPassword" should be the password configured as remote output notifier access password on the tenant settings.
KeystorePath and password
"keystorePath" and "keystorePassword" should point to the same keystore as the main application system settings for notifications. Regarding the keystorePath: Please note that internal: is to be used only for the internal keystores of InterformNG2. If you want to use your own keystore, then you need to specify the full path to your keystore e.g. C:\Program Files\InterFormNG2\keystore\mykeystore.jks.
Notifications for Azure Service BusIf you want to use Azure Service Bus for notifications, then you should use these instructions.First you need to create a namespace on the Azure Service Bus. Within the namespace, create a topic for each locationId that you are going to use. The topic must have the same name as the locationId. Note that topics have to be all lower-case on Azure Service Bus, and must be written in all lower case in InterFormNG2 as well. Within the topic, create a subscription for each remote client instance that you wish to use to read from that location.
The connection to Azure Service Bus can be configured with either an Entra ID app registration (recommended) or a connection string.
To use Entra ID app registration, follow the instructions in the section Azure Service Bus configuration. The remote client only needs read access to the service bus.
In the configuration file, after "notifier", replace null with:
{
"type": "azureSB",
"azureSubscription": "<SUBSCRIPTION_NAME>",
"appRegistration": {
"clientId": "f32dda31-efe8-4a29-8f5a-cfecd1eb2838",
"msTenantId": "c111d3c8-10b3-1204-6521-14650911efbf",
"secret": "h1X2Q~PDnzXS5R~WiOPdDwozRx-N3lX.jFjsyczr",
"namespace": "<NAMESPACE>.servicebus.windows.net"
}
}
Replace <SUBSCRIPTION_NAME> with the actual subscription created for this client and replace <NAMESPACE> with the correct namespace for the service bus.
To use connection string instead, in the remote client configuration file, you need to state the connection string for connecting to the topic. You can use the root access key, but it is recommended to create a new access key that only has send/listen access to the namespace.
In the configuration file, after "notifier", replace null with:
{
"type": "azureSB",
"azureSubscription": "<SUBSCRIPTION_NAME>"
"azureConnectionString": "Endpoint=sb://<NAMESPACE>.servicebus.windows.net/;SharedAccessKeyName=AppAccessKey;SharedAccessKey=<GENERATED_KEY>",
}
Replace <SUBSCRIPTION_NAME> with the actual subscription created for this client, replace <NAMESPACE> with the correct namespace for the service bus and replace <GENERATED_KEY> with the correct access key.
After changing the settings, the remote output client service may need to be restarted (if it failed to connect with the previous settings, it will actually automatically retry with the new ones).
Check the log to verify that the remote client is able to connect to the host.
Hint for First In First Out processing with a remote client