The "apis" property is an array of objects that describes and controls FairCom's jsonAction APIs. It defaults to an empty object.

Each API is a service provided by the FairCom server.

Do not change the settings of the object properties unless you disable an unused API.

"./api"

The "applicationRoot" property is a string that specifies the location of web applications relative to <faircom>/server/ .

The default value of "./web/apps/" translates to the folder <faircom>/server/web/apps.

There is rarely a reason to change the "applicationRoot".

For information on how to add your own web applications, which can use any of FairCom's jsonAction APIs, contact FairCom.

"./web/apps/"

The optional "applications" property is an array of objects that describes and controls web applications that can run with the FairCom server. It defaults to an empty array which means no applications are configured to run.

FairCom and other custom web applications are single-page, browser-based applications served from folders in the default <faircom>/server/web/apps/ folder.

An app server is a backend service used by one or more web applications. It listens to HTTP and/or WebSocket requests and then returns results.

Contact FairCom for information on how to build and add your own app servers using C or C++.

The following "applications" properties should be considered for each web app:

applications

.enabled

applications

.folderName

The "folderName" property specifies the folder within the "applicationRoot" folder that contains the code the FairCom web server delivers to the browser. This folder contains all code-related files such as HTML, CSS, JavaScript files, and so forth.

Only when the "enabled" property in the same object is true will the FairCom web server deliver the folder's code to the web browser, as shown in the following example for FairCom's ACE Monitor application.

{
  "serviceName": "Ace Monitor",
  "folderName": "AceMonitor",
  "serviceLibrary": "ctmonitor.dll",
  "enabled": true
},

In this example, the web application will be stored in the <faircom>/server/web/apps/AceMonitor/ folder.

Note: Set the "enabled" property to false for each application you want to disable. In addition, the FairCom web server will not deliver any application if the "applications" property is missing or all application objects set "enabled" to false.

You may change the "enabled" setting to false or true for the FairCom built-in web applications but do not change the other settings

applications

.serviceLibrary

The optional "serviceLibrary" property is a string that specifies the filename of a dynamic library that provides the API used by the web application.

Library files are located in the <faircom>/server/web/ folder.

The full path includes the "serviceLibrary" value — for example, the Monitor app has a "serviceLibrary" name of ctmonitor.dll, and its full path in the file system is <faircom>/server/web/ctmonitor.dll.

applications

.serviceName

applications

.uriPath

The "approvedCorsConnections" property is an optional array that lists the external URLs that are approved to make cross-origin API requests.

services.json example:

{
	"applicationRoot": "./web/apps/",
	"approvedCorsConnections": [ "https://faircom.github.io" ]
}

When FairCom's App server receives an API request that includes an Origin header with a URL that is in the "approvedCorsConnections" array, the server adds the following HTTP headers to the response. This approves the CORS (Cross-Origin Resource Sharing) request.

Access-Control-Allow-Origin: https://faircom.github.io
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type
Content-Type: application/json

When an API call does not include an Origin header or the specified URL in the Origin header does not match a URL in this array, the server does not add these headers to the response. This denies the CORS request.

FairCom MQ and FairCom Edge let you enforce secure MQTT communications with the broker by letting you control how MQTT clients authenticate.

Use the "authenticationMethods" property in the services.json configuration file to control MQTT authentication.

"mqtt": {
  "authenticationMethods": ["none", "password", "clientCertificate"]
  }

Define the allowed MQTT authentication methods by including any combination of "none", "password", and "clientCertificate" in the "authenticationMethods" property. 

Examples

To allow MQTT clients to connect with or without authentication, include "none", "password", and "clientCertificate" in the list. This is the default setting in services.json.

To require MQTT clients to connect only with certificate authentication, include only "clientCertificate" in the list.

To require MQTT clients to connect only with a username and password authentication, include only "password" in the list.

To require MQTT clients to connect with a client certificate or a password, include "clientCertificate", and "password" in the list.

Best Security Practice

Remove "none" from the list to prevent non-authenticated clients from connecting.

codeServices

.enabled

The "enabled" property is an optional Boolean that specifies whether or not the feature is enabled. The example below enables the TLS feature.

        "tls": {
          "enabled": true,
          "caCertificateFilename": "ca.crt",
          "allowedCipherSuites": "",
          
          "clientCertificateEnabled": true,
          "clientCertificateFilename": "admin_client.crt",
          "clientPrivateKeyFilename": "admin_client.key"
        }

codeServices

.serviceLibrary

The "serviceLibrary" property is a string that specifies the filename of a dynamic library that provides the API used by the web application.

Library files are located in the <faircom>/server/web/ folder.

The full path includes the "serviceLibrary" value — for example, the Monitor app has a "serviceLibrary" name of ctmonitor.dll, and its full path in the file system is <faircom>/server/web/ctmonitor.dll.

codeServices

.serviceName

The "serviceName" property is a case insensitive, optional property that defaults to "javascript". It specifies the name of the code service that provides the programming language runtime environment.

The "serviceName" property maps to a section in the services.json file called "codeServices" that defines which programming languages are available in the product.

"codeServices": [
  {
    "serviceName": "javascript",
    "serviceLibrary": "v8transformservice.dll",
    "enabled": true
  }
],

In services.json, multiple code language services can be created with different "serviceName" properties, such as "javascript", "javascript2023", and "javascript2027". This allows the developer of a code package to do things like use "javascript" to specify the latest version of the JavaScript code service or target a specific version of the JavaScript engine using a more specific "serviceName".

Each service may use the same or different dynamic libraries (.dll, .so, or .dylib) to provide the programming language runtime. The same dynamic library may also be reused in other services, such as transform services.

The "connectionPoolFileIdleCloseSeconds" property specifies how long in seconds a table remains open in the connection pool used by the MQTT and REST API after the operation completes. This value must be an integer between -1 and 2147483647. When this property is set to a value of -1, the tables in the connection pool stay open indefinitely.

FairCom recommends using the REST API to make changes to tables and indexes because it is rarely affected by file block errors caused by open files in the connection pool. 

When the REST API alters a table (including adding or deleting its indexes), it uses the ctFILBLKX function to force the table to close in all other sessions. This action is the root cause for Errors -17008, 798, 799 in concurrent REST, SQL, ISAM, or CTDB operations. 

The "connectionPoolFileIdleCloseSeconds" property specifies how long in seconds a table remains open in the connection pool used by the MQTT and REST API after the operation completes. This value must be an integer between -1 and 2147483647. When this property is set to a value of -1, the tables in the connection pool stay open indefinitely.

FairCom recommends using the REST API to make changes to tables and indexes because it is rarely affected by file block errors caused by open files in the connection pool. 

When the REST API alters a table (including adding or deleting its indexes), it uses the ctFILBLKX function to force the table to close in all other sessions. This action is the root cause for Errors -17008, 798, 799 in concurrent REST, SQL, ISAM, or CTDB operations. 

The "integrationServices" property is an array of objects that describes and controls FairCom's integration services. It defaults to an empty array.

The default settings for the FairCom jsonAction APIs and browser-based applications are specified in the services.json file in the "jsonActionApiDefaults" property.

Use the Google Chrome browser for FairCom browser-based tools. Other browsers may cause unexpected behavior.

Example 1. Default settings for jsonAction APIs

"jsonActionApiDefaults": {
    "defaultApi": "db",
    "defaultBinaryFormat": "hex",
    "defaultVariantFormat": "json",
    "defaultDatabaseName": "faircom",
    "defaultDebug": "max",
    "defaultOwnerName": "admin",
    "defaultResponseOptions": 
    {
      "binaryFormat": "hex",
      "variantFormat": "json",
      "dataFormat": "objects",
      "numberFormat": "number"
    },
    "idleConnectionTimeoutSeconds": 3600,
    "idleCursorTimeoutSeconds": 600,
    "defaultRetentionPolicy":"autoPurge",
    "defaultRetentionPeriod":"4",
    "defaultRetentionUnit":"week"
  }

The property names and values in "jsonActionApiDefaults" are identical to those in the "params" property of "createSession", "alterSession", and "describeSessions". Each FairCom product ships with different default settings that make sense for that product — for example, in FairCom DB, the "defaultAPI" property is set to "db", in FairCom MQ it is set to "mq", and in FairCom Edge it is set to "hub".

You can change the values of the properties in services.json, and all jsonAction APIs and browser-based user interfaces will use these properties as their default. If any of the properties in "jsonActionApiDefaults" are omitted from services.json, the property values may vary depending on the JSON action performed.

FairCom's core configuration file, ctsrvr.cfg, contains a SQL_DATABASE setting. You can set SQL_DATABASE to the name of a database and when the FairCom server starts, it creates a database with that name if it does not already exist.

By default, ctsrvr.cfg sets SQL_DATABASE to "ctreeSQL". If you change SQL_DATABASE to use another database name, it is a good practice to put the same name in the "defaultDatabaseName" property in services.json. This makes your newly created database the default database in all of FairCom's jsonActionAPIs and browser-based applications.

Example 2. Keeping SQL_DATABASE and "jsonActionApiDefaults" in sync
ctsrvr.cfg 

SQL_DATABASE my_new_database

services.json 

"": {
    "defaultApi": "db",
    "defaultBinaryFormat": "hex",
    "defaultDatabaseName": "my_new_database",
    "defaultDebug": "max",
    "defaultOwnerName": "admin",
    "defaultResponseOptions": 
    {
      "binaryFormat": "hex",
      "dataFormat": "objects",
      "numberFormat": "number"
    },
    "idleConnectionTimeoutSeconds": 3600,
    "idleCursorTimeoutSeconds": 600,
    "defaultRetentionPolicy":"autoPurge",
    "defaultRetentionPeriod":"4",
    "defaultRetentionUnit":"week"
  }

The "listeners" property is an array of objects that describes and controls FairCom's listeners. It defaults to an empty array.

listeners

.tls

The "tls" property is a JSON object that defines the public server certificate filename, the private key filename, the certificate authority filename, the cipher suites that are allowed, and whether the client certificate is required. This property is optional. It defaults to an empty object. 

"tls": { "serverCertificateFilename": "server.crt", "privateKeyFilename": "server.key", "caCertificateFilename": "ca.crt", "allowedCipherSuites": "AES256-SHA256" "requireClientCertificate": "true"
}

listeners

.tls

.allowedCipherSuites

The "allowedCiperSuites" property is an optional string that specifies an array of ciphers that the server will accept for communications with clients. It defaults to an empty string.

["AES256-SHA256", "AES256-GCM-SHA384", "DHE-RSA-AES256-SHA256"]

["!aNULL", "!eNULL", "!SSLv2", "!LOW", "!EXP", "!RC4", "!MD5", "@STRENGTH"]

["ALL", "!aNULL", "!eNULL", "!SSLv2", "!LOW", "!EXP", "!RC4", "!MD5", "@STRENGTH"]

listeners

.tls

.caCertificateFilename

The "caCertificateFilename" property is an optional string that specifies the name and optional path of the CA certificate file (such as "ca.pem"). It defaults to an empty string.

        "tls": {
          "enabled": true,
          "caCertificateFilename": "ca.crt",
          "allowedCipherSuites": "",
          
          "clientCertificateEnabled": true,
          "clientCertificateFilename": "admin_client.crt",
          "clientPrivateKeyFilename": "admin_client.key"
        }

listeners

.tls

.clientCertificateFilename

The "clientCertificateFilename" property is an optional string that specifies the name of the client certificate file. It defaults to an empty string.

        "tls": {
          "enabled": true,
          "caCertificateFilename": "ca.crt",
          "allowedCipherSuites": "",
          
          "clientCertificateEnabled": true,
          "clientCertificateFilename": "admin_client.crt",
          "clientPrivateKeyFilename": "admin_client.key"
        }

listeners

.tls

.clientPrivateKeyFilename

The "clientPrivateKeyFilename" property is an optional string that specifies the name of the client private key file. It defaults to an empty string.

        "tls": {
          "enabled": true,
          "caCertificateFilename": "ca.crt",
          "allowedCipherSuites": "",
          
          "clientCertificateEnabled": true,
          "clientCertificateFilename": "admin_client.crt",
          "clientPrivateKeyFilename": "admin_client.key"
        }

listeners

.tls

.requireClientCertificate

The "requireClientCertificate" property is an optional boolean property. It defaults to false. If present, it must be set to true or false.

The "maxConnectionsPerIpAddress" property is the number of TCP/IP connections the app server will accept from a single TCP/IP address.

This feature is implemented at the FairCom App Server level to prevent the app server from being overwhelmed by a DoS attack. It protects against simultaneous DoS attacks across multiple protocols: HTTP, HTTPS, MQTT, MQTTS, WS, and WSS.

The default is 25 connections.

A value of 0 disables this protection.

This property can be added to the top level of the services.json file and/or to each listener object in the "listeners" array. At the top level, the property applies to all listeners. Within a listener, it applies only to that listener.

In the case that your connections are routed through a firewall or load balancer, you may need to disable this feature since the connections will come from the same IP address.

{
  "maxConnectionsPerIpAddress": 5,
    "listeners": [
    {
      "serviceName": "https8443",
      "description": "Port 8443 using TLS-secured HTTPS protocol for REST and Web Apps on all TCP/IP addresses bound to this server",
      "port": 8443,
      "protocol": "https",
      "enabled": true,
      "maxConnectionsPerIpAddress": 5,
      "tls": {
        "certificateFilename": "./web/fccert.pem"
      }
    }
  ]
}

The "maxJsonApiSessions" property is the total number of JSON API sessions the app server will accept. This setting ensures the server does not consume so many resources that it becomes unstable.

The default value is the maximum number of JSON API connections allowed by the license.

A value of 0 disables this protection and allows JSON API sessions up to the maximum number of connections allowed by the license file.

This property is added to the "jsonActionApiDefaults" object.

The "maxJsonApiSessionsPerIpAddress" property is the number of JSON API sessions the app server will accept from the same client IP Address.

The default value is 50.

The maximum possible number of connections is determined by the license file.

A value of 0 disables this protection and allows JSON API sessions with the same IP Address up to the maximum number of connections allowed by the license file.

This property is added to the "jsonActionApiDefaults" object.

In the case that your connections are routed through a firewall or load balancer, you may need to disable this feature since the connections will come from the same IP address.

Accordion BodyThe "maxJsonApiSessionsPerUsername" property is the number of JSON API sessions the app server will accept with the same username. Because of this, an application may use a different account for each JSON API session.

The default value is 50.

The maximum possible number of connections is determined by the license file.

A value of 0 disables this protection and allows unlimited sessions with the same username up to the maximum number of connections allowed by the license file.

If your application uses one account for all JSON API sessions, this feature will need to be disabled.

This property is added to the "jsonActionApiDefaults" object. See the example below.

"jsonActionApiDefaults":
{
  "maxJsonApiSessions": 500,
  "maxJsonApiSessionsPerIpAddress": 20,
  "maxJsonApiSessionsPerUsername": 20,
    "defaultApi": "hub",
  "defaultBinaryFormat": "hex",
  "defaultDatabaseName": "faircom",
  "defaultDebug": "max",
  "defaultOwnerName": "admin",
  "defaultResponseOptions":
  {
    "binaryFormat": "hex",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "idleConnectionTimeoutSeconds": 3600,
  "idleCursorTimeoutSeconds": 600,
  "defaultRetentionPolicy": "autoPurge",
  "defaultRetentionUnit": "week",
  "defaultRetentionPeriod": 4
}

mqtt

.authenticationMethods

The optional "authenticationMethods" property defines which authentication techniques are accepted by the MQTT broker. To enable an authentication technique, include it in the list. To disable an authentication technique, remove it from the list. For example, remove "none" and "password" from the list to require all clients to authenticate using only client certificates. The default value is "authenticationMethods": [ "none", "password", "clientCertificate" ], which causes the broker to accept all client authentication techniques.

The broker supports the following authentication techniques:

mqtt

.defaultDowngradeQoS

mqtt

.defaultMaxDeliveryRatePerSecond

mqtt

.defaultMaxInflightMessages

mqtt

.defaultMessageCommitFrequencyForQoS1

The optional "defaultMessageCommitFrequencyForQoS1" property specifies the default frequency for messages to be committed for QoS 1. The default value is 1000 to deliver all messages as quickly as possible. The "optimizeForQoS2" property automatically uses the value of this property to set the default value of the "messageCommitFrequencyForQoS1" property in the "configureTopic" action, which you can optionally assign to each topic. 

When most messages are QoS 0 or 1, in services.json, you can set "defaultMessageCommitFrequencyForQoS1" to a number greater than 0, such as 1000. It delays committing the delivery status to disk by the specified number of messages, which causes the MQTT broker to use volatile RAM to track delivery status. Delaying the persistence of delivery status increases delivery speed, but when the MQTT broker encounters unexpected downtime, the broker resends messages up to the number specified in this property, which is a problem for QoS 2 messages but not for QoS 0 and QoS 1 messages. When you need a specific topic to support QoS 2, use the "configureTopic" action to set the "MessageCommitFrequencyForQoS1": 0 to ensure previously sent QoS 2 messages are not resent while the server recovers from unplanned downtime. 

When most messages are QoS 2, you can add "defaultMessageCommitFrequencyForQoS1": 0 to services.json. This setting causes the server to commit each message's delivery status to disk, which ensures previously sent QoS 2 messages are not resent while the server recovers from unplanned downtime. When you need a specific topic to support QoS 0 or 1 for maximum performance, use the "configureTopic" action to set "MessageCommitFrequencyForQoS1" to a number greater than 0, such as 1000.

mqtt

.defaultMillisecondCommitFrequencyForQoS1

The optional "defaultMillisecondCommitFrequencyForQoS1" property specifies the default frequency in milliseconds to commit the delivery status for QoS 1. The "optimizeForQoS2" property automatically uses the value of this property to set the default value of the "MillisecondCommitFrequencyForQoS1" property in the "configureTopic" action, which you can optionally assign to each topic. The default value is 1000 to deliver all messages as quickly as possible. 

When most messages are QoS 0 or 1, in services.json, you can set "defaultMillisecondCommitFrequencyForQoS1" to a number greater than 0, such as 1000. It delays committing the delivery status to disk by the specified number of milliseconds, which causes the MQTT broker to use volatile RAM to track delivery status. Delaying the persistence of delivery status increases delivery speed, but when the MQTT broker encounters unexpected downtime, the broker resends messages, which is a problem for QoS 2 messages but not for QoS 0 and QoS 1 messages. When you need a specific topic to support QoS 2, use the "configureTopic" action to set the "millisecondCommitFrequencyForQoS1": 0 to ensure previously sent QoS 2 messages are not resent while the server recovers from unplanned downtime. 

When most messages are QoS 2, you can add "defaultMillisecondCommitFrequencyForQoS1": 0 to services.json. This setting causes the server to commit each message's delivery status to disk, which ensures previously sent QoS 2 messages are not resent while the server recovers from unplanned downtime. When you need a specific topic to support QoS 0 or 1 for maximum performance, use the "configureTopic" action to set "MillisecondCommitFrequencyForQoS1" to a number greater than 0, such as 1000.

mqtt

.defaultMqttPayloadType

mqtt

.defaultOptimizeForQoS2

mqtt

.defaultRetrySeconds

mqtt

.defaultValidateMqttPayload

mqtt

.disableThroughputStats

mqtt

.enforceQos2DuringRecovery

mqtt

.eventuallyPersistDeliveryInfo

Changing to true may cause you to lose QoS 1 and 2 messages. It also prevents you from implementing high availability. FairCom does not recommend using true.

Do not change this setting if you want to preserve your settings in FairCom MQ and FairCom Edge. To change this setting, you must shut down the FairCom server, delete the faircom xdatabase, change the setting's value, and restart the server to rebuild its delivery tracking tables.

The "eventuallyPersistDeliveryInfo" property determines whether the server will persist the delivery status of each message to disk. It defaults to false, which causes the server to persist the delivery status of each message to disk. FairCom recommends false because it allows FairCom's MQTT broker to support mission-critical QoS 2 messages – even when the server is recovering from unplanned downtime.

Set it to true for faster message delivery when you only want to support QoS 0 and 1. Setting it to true prevents FairCom's MQTT broker from supporting mission-critical QoS 2 messages because when the server is recovering from an unplanned downtime, it may resend QoS 2 messages, which violates the MQTT specification. 

In more technical terms, this setting controls whether the broker commits the delivery status of MQTT packets to the transaction log on disk or commits delivery status to volatile RAM using FairCom's PREIMG technology, where the server eventually writes the changes to disk.

mqtt

.historyRetentionPeriod

The optional "historyRetentionPeriod" property controls how long the server stores records that contain MQTT history. It is a positive integer number. For example, when you set "historyRetentionPeriod" to 5 and "historyRetentionUnit" to "day", the server retains records for five days, and, at the beginning of each day, the server removes records older than five days.

See "historyRetentionUnit".

mqtt

.historyRetentionUnit

The optional "historyRetentionUnit" property controls how often the server purges records containing MQTT history.

These records are in the following tables in the FairCom database:

You may set "historyRetentionUnit" to:

See "historyRetentionPeriod".

mqtt

.messageCommitFrequencyForQoS1

The optional "messageCommitFrequencyForQoS1" property sets the maximum number of messages the MQTT broker will send before it commits the delivery status to disk. A larger number increases the time between committed messages, which improves performance, but during recovery from unplanned downtime, it allows the broker to resend packets it has already sent. A non-zero number is a problem for QoS 2 messages, which should be sent only once.

When it is set to 1 or less, the delivery information for each message is committed when the message is delivered, and the "millisecondCommitFrequencyForQoS1" property is set to 0 to disable the timer because it is not needed.

When the "optimizeForQoS2" property is true, it sets the value of this property to 0 to support Qos 2 messages. This setting ensures the MQTT broker does not resend previously sent QoS 2 messages while recovering from unplanned downtime. Command and data change messages typically require QoS 2 because they must be delivered only once.

When the "optimizeForQoS2" property is false, it sets the value of this property to "defaultMessageCommitFrequencyForQoS1" unless you assign a value to the "messageCommitFrequencyForQoS1" property.

When a topic only supports QoS 0 and 1 messages, you may set the value to an integer number greater than 0, such as 1000. It delays committing the delivery status to disk by the specified number of messages, which causes the MQTT broker to use volatile RAM to track delivery status for faster message delivery. Many messages, such as telemetry, status, queries, birth notice, and death notice, use QoS 0 or 1 when the client can tolerate receiving the same message more than once.

The "messageCommitFrequencyForQoS1" and "millisecondCommitFrequencyForQoS1" properties work together to ensure no more than the maximum number of messages and milliseconds occur before the server commits the delivery status to disk.

mqtt

.millisecondCommitFrequencyforQoS1

The optional "messageCommitFrequencyForQoS1" property sets the maximum number of messages the MQTT broker will send before it commits the delivery status to disk. A larger number increases the time between committed messages, which improves performance, but during recovery from unplanned downtime, it allows the broker to resend packets it has already sent. A non-zero number is a problem for QoS 2 messages, which should be sent only once.

When it is set to 1 or less, the delivery information for each message is committed when the message is delivered, and the "millisecondCommitFrequencyForQoS1" property is set to 0 to disable the timer because it is not needed.

When the "optimizeForQoS2" property is true, it sets the value of this property to 0 to support Qos 2 messages. This setting ensures the MQTT broker does not resend previously sent QoS 2 messages while recovering from unplanned downtime. Command and data change messages typically require QoS 2 because they must be delivered only once.

When the "optimizeForQoS2" property is false, it sets the value of this property to "defaultMessageCommitFrequencyForQoS1" unless you assign a value to the "messageCommitFrequencyForQoS1" property.

When a topic only supports QoS 0 and 1 messages, you may set the value to an integer number greater than 0, such as 1000. It delays committing the delivery status to disk by the specified number of messages, which causes the MQTT broker to use volatile RAM to track delivery status for faster message delivery. Many messages, such as telemetry, status, queries, birth notice, and death notice, use QoS 0 or 1 when the client can tolerate receiving the same message more than once.

The "messageCommitFrequencyForQoS1" and "millisecondCommitFrequencyForQoS1" properties work together to ensure no more than the maximum number of messages and milliseconds occur before the server commits the delivery status to disk.

mqtt

.optimizeForQoS2

The optional "optimizeForQoS2" property ensures the specified topic either delivers maximum performance for QoS 1 messages when set to false or fully supports mission-critical QoS 2 messages when set to true. It defaults to false for maximum performance.

When false, the topic uses the value you specify in "MessageCommitFrequencyForQoS1". If omitted, "MessageCommitFrequencyForQoS1" is set to "defaultMessageCommitFrequencyForQoS1".

When false, the topic uses the value you specify in "MillisecondCommitFrequencyForQoS1". If omitted, "MillisecondCommitFrequencyForQoS1" is set to "defaultMillisecondCommitFrequencyForQoS1".

When true, it assigns the following property values to the topic and ignores any values you apply to these properties:

"MessageCommitFrequencyForQoS1": 1

"MillisecondCommitFrequencyForQoS1": 0

QoS 0 messages are unaffected by this property and always run at maximum performance.

When true, this setting causes the server to persist additional two-phase commit information for each sent message. This information is required for the server to know if it has already sent a message. Persisting this extra information slows message delivery but ensures the server correctly handles duplicate messages during a server restart after an unplanned downtime.

mqtt

.ownerName

mqtt

.pollingFrequencyMilliseconds

mqtt

.statsCollectionFrequencySeconds

mqtt

.statsPublishFrequencySeconds

The optional "statsPublishFrequencySeconds" property sets the frequency in seconds for the MQTT broker to publish MQTT messages containing statistics about connections, subscribers, and topics. Each message is a JSON object that includes extensive information about the current state of the MQTT broker. Do the following to turn off publishing these messages: omit the property, set it to null, or set it to a value <= 0. A smaller value increases the number of messages sent per second and slightly slows down the overall performance of the MQTT broker.

mqtt

.statsRetentionPeriod

The optional "statsRetentionPeriod" property controls how long the server stores records that contain MQTT statistics. It is a positive integer number. For example, when you set "statsRetentionPeriod" to 5 and "statsRetentionUnit" to "day", the server retains records for five days, and, at the beginning of each day, the server removes records older than five days.

This property applies to the mqtt_stats table and the integration tables created by the "connectionStatsTopicName", "subscriberStatsTopicName", and "topicStatsTopicName" properties.

See "statsRetentionUnit".

mqtt

.statsRetentionUnit

The optional "statsRetentionUnit" property controls how often the server purges records containing MQTT statistics in the mqtt_stats table.

You may set it to:

See “statsRetentionPeriod”

The "otherServices" property is an optional array of objects that describes and controls FairCom's other services. It defaults to the services connected when the server last started up.

"otherServices": [
  {
    "serviceName": "dbnotify",
    "serviceLibrary": "./dbnotify/fcdbnotify.dll",
    "enabled": false
  }
],

The "transformServices" property is an optional array of objects that describes and controls FairCom's transform services. It defaults to the services connected when the server last started up.

"transformServices" [
  {
    "serviceName": "siemensUDT2JSON",
    "serviceLibrary": "siemensudtservice.dll",
    "enabled": true
  }
],