createMqApiSession

Create a new MQ session

The "createMqApiSession" action creates a new MQ API session, which is a different type of connection than MQTT. An MQ API session uses the HTTP protocol, and an MQTT session uses the MQTT wire protocol. Thus, only an MQTT client using the MQTT protocol can create an MQTT session, and only software using the "createMqApiSession" action can create an MQ API session.  

You can use an MQ API session to publish a message to any MQTT topic, retrieve a message from any MQTT topic, and list, describe, configure, or delete any MQTT or MQ API session. This is because an MQ API session has the same properties and capabilities as an MQTT session. Thus, from either type of session, you can publish to, subscribe to, and retrieve messages from the same topics. Lastly, you can use the following MQ API actions with any MQTT or MQ API session: "alterMqSession",  "listMqSessions", "describeMqSessions", "deleteMqSession", "subscribeToMq", "getMessagesFromMqTopic", and "publishMessagesToMq". 

The value of the "clientName" property uniquely identifies the session. It is comparable to the Client ID property in MQTT. Because the client name is the unique identifier of a messaging session, an MQ API session cannot use the same client name as an MQTT session and vice-versa. 

The "createMqApiSession" action returns an error if "clientName" refers to any existing session. This behavior differs from MQTT, which disconnects an existing MQTT session when a new MQTT client uses the same Client ID. In addition, MQTT clients receive an error if they attempt to connect to a session created by the "createMqApiSession" action, and vice-versa.

You can create a permanent or temporary MQ API session. Once you create a permanent session, it persists until you run the "deleteMqSession" action. If you create a temporary MQ API session, the server automatically deletes it when the session times out because of a lack of session activity. Once you create a permanent MQ API session, it never expires, and you can use its "clientName" in any MQ API action.

Note

  • Only the "createMqApiSession" action can create an MQ API session. This is why the phrase "MqApi" is in the action's name. In contrast, clients using the MQTT protocol can create an MQTT session but not an MQ API session.  
  • There are two MQ API actions with "MqApi" in their names: "createMqApiSession" and "getMessagesFromMqApiSession". The "getMessagesFromMqApiSession" action has "MqApi" in its name because it only works with sessions created by the "createMqApiSession" action. The remaining MQ API actions work with both the MQ API and MQTT. For example, you can use "alterMqSession" to alter an MQ API session and an MQTT  session.

 

Temporary and Permanent sessions

 

Permanent sessions

A permanent session is ideal for the MQ API because you can do all message actions without worrying about your MQ session expiring. 

  • You can be disconnected from the server for an extended time and call the "getMessagesFromMqApiSession" action to receive all the unexpired messages since you last called it.
  • The server persists the state of a permanent session, including its settings, subscriptions, and subscription delivery queue.
  • Set the "temporarySession" property to false (the default) to create a permanent session.
    • When creating a permanent session, the server sets the "cleanSession" property to false, "keepAliveSeconds" to 0 so it never times out, and "sessionExpiryInterval" to 4294967296 to retain a session when the client is disconnected.

 

Temporary sessions

A temporary session is ideal for doing temporary message actions, and you want the server to clean up the session state automatically after the session expires.

  • Set the "temporarySession" property to true to create a temporary session.
    • When creating a temporary session, the server automatically sets the "cleanSession" property to true and sets the session expiry timer to the value of  "sessionExpiryInterval". 
  • The server retains a temporary session as long as the client performs an MQ Message action within the keep-alive timeout period, which is "keepAliveSeconds" x 1.5. Once there is no activity, the server starts the session expiry timer to remove the temporary session. If there is no session activity within the number of seconds specified in the "sessionExpiryInterval" property, the server removes the session. You can use the "pingSession" action to keep a temporary session alive.
  • You should use the "temporarySession" property to control session permanency rather than the "cleanSession" property because it has a more intuitive name. It is an error to include both and set them to opposite values.

 

Session actions

You can optionally set "sessionStatus" to "normal", "hidden", "banned", or "inactive" to hide its visibility in API results and dashboard views, ban a client from connecting, or mark a client as inactive. A banned session prevents clients from using the session to publish and subscribe to messages. When "sessionStatus" is omitted, it defaults to "normal".

To subscribe to and unsubscribe from topics, use the "subscribeToMq" action.

The "clientName" property is optional in "createMqApiSession". You can omit the "clientName" property, set it to null, or set it to "" to cause the action to generate a unique client name and create an MQ session for that client name. The response returns the new client name in the "clientName" property.

Note When you set the "binaryFormat" property to "utf8" or "json", the server automatically assigns the "willPayloadFormatIndiciator" property to "utf8" to indicate that the payload contains UTF-8 encoded characters, such as JSON.

 

Request examples

 

Minimal

{
  "api":       "mq",
  "action":    "createMqApiSession",
  "params":    {},
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Maximal

{
  "api": "mq",
  "action": "createMqApiSession",
  "params":
  {

    "clientName": "a unique MQ API client identifier or empty string",
    "cleanSession": true,
    "temporarySession": false,
    "sessionStatus": "normal | hidden | banned | inactive",
    "mqttProtocol": "5.0 | 3.1.1",

    "keepAliveSeconds": 60,

    "userProperties": [
      {
        "key": "some key",
        "value": "some value"
      }
    ],

    "binaryFormat": "utf8",

    "sessionExpiryInterval": 4294967296,
    "receiveMaximum": 1024,
    "maximumPacketSize": 1024,
    "topicAliasMaximum": 0,
    "requestProblemInformation": true,
    "requestResponseInformation": false,

    "willTopic": "some/Topic/Name/",
    "willQoS": 2,
    "willPayload": "This message is sent when client disconnects.",
    "willRetain": true,
    "willContentType": "IanaMediaType or a CustomType",
    "willCorrelationData": "any JSON value up to 65500 bytes",
    "willPayloadFormatIndicator": "none | utf8",
    "willExpirySeconds": 60,
    "willDelaySeconds": 60,
    "willResponseTopic": "topic/name/for/subscriber/to/respond/to",
    "willUserProperties": [
      {
        "key": "some key",
        "value": "some value"
      }
    ],

    "label": {
      "group": "group name",
      "name": "label name"
    },

    "minHealthySendRatePerMinute": 10,
    "maxHealthySendRatePerMinute": 1000,
    "maxHealthyBacklogRatePerMinute": 10,
    "minHealthySubscribedTopicFiltersCount": 10,
    "maxHealthySubscribedTopicFiltersCount": 1000,

    "metadata": {}
  },
  "debug": "max",
  "requestId": "optionalUniqueRequestIdFromTheClient",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Response example

{
  "authToken": "GcKIH09dV3rcatEkEQStNN8nmP2Qqh7LSuXIGfV8N7ILy20NDezxm1S9nVXdp1Sf",
  "result": {
    "clientName": "client1",
    "sessionStatus": "normal",
    "username": "ADMIN",
    "ipaddress": "127.0.0.1",
    "port": 64283,
    "mqttProtocol": "3.1.1",
    "keepAliveSeconds": 0,
    "connectionStatus": "connected",
    "connectionDateTime": "2025-09-17T16:24:41",
    "defaultBinaryFormat": "hex",
    "defaultVariantFormat": "json",
    "defaultResponseOptions": {
      "binaryFormat": "hex",
      "variantFormat": "json",
      "dataFormat": "objects",
      "numberFormat": "number"
    },
    "sessionType": "mqApi",
    "willTopic": "some/Topic/Name/",
    "willQoS": 2,
    "willPayload": "This message is sent when client disconnects.",
    "willRetain": true,
    "metadata": {},
    "sessionPresent": false
  },
  "requestId": "00000003",
}
  

 

"params"

createMqApiSession "params" property summaries
Property Description Default Type Limits (inclusive)
binaryFormat (optional) specifies how the "payload" property is encoded "hex" string One of the following: "base64", "hex", or "byteArray".
cleanSession (optional) synonymous with "temporarySession" false Boolean
true
false
clientName (optional) specifies the unique name that identifies the client to the FairCom MQ engine "" string 0 to 65,550 bytes
keepAliveSeconds (optional) specifies the number of seconds before the server removes the session 0 integer  
label (optional) assigns a label to the object using the label's group and name. null object
"label": {
  "group": "group name",
  "name": "label name"
}
label
.group
(optional) identifies a label using its group description. "" string 0 to 64 bytes
label
.name
(optional) identifies a label using its name. "" string 0 to 64 bytes
labelID (optional) assigns a label to the object using the label's ID. null integer 0 to 4294967296
maxHealthyBacklogRatePerMinute (optional) specifies the maximum number of backlog messages per minute for a session to be considered healthy 0 integer  
maxHealthySendRatePerMinute (optional) specifies the maximum number of sent messages per minute for a session to be considered healthy 0 integer  
maxHealthySubscribedTopicFiltersCount (optional) specifies the maximum number of topic filters for a session to be considered healthy 0 integer  
maximumPacketSize (optional) specifies the maximum size of a single packet that the session can receive 1024 integer  
minHealthySendRatePerMinute (optional) specifies the minimum number of sent messages per minute for a session to be considered healthy 0 integer  
minHealthySubscribedTopicFiltersCount (optional) specifies the minimum number of topic filters for a session to be considered healthy 0 integer  
mqttProtocol (optional) specifies the version of MQTT protocol to use in your session 5.0 string enum
"3.1.1"
"5.0"
receiveMaximum (optional) specifies the maximum number of QoS 1 and QoS 2 publish messages that the MQTT client is willing to process concurrently 1024 integer 1 to 65535
requestProblemInformation (optional) specifies whether or not to include problem information in the response true Boolean
true
false
requestResponseInformation (optional) specifies whether or not to include request information in the response false Boolean
true
false
sessionExpiryInterval (conditional) specifies the number of seconds that a temporary MQTT session can be inactive before the server deactivates it If "temporarySession" is true, "sessionExpiryInterval" defaults to 0 to ensure the temporary session expires when the JSON session does. If "temporarySession" is false, it defaults to 4294967296 because a permanent session never expires. integer 0 to 4294967296
sessionHealth specifies the status of the session's health Required - No default value enum
"healthy"
"unhealthy"
"offline"
sessionStatus (optional) specifies the status of an MQTT or MQ API session "normal" string enum
"normal"
"hide"
"ban"
temporarySession (optional) specifies whether or not the session will be permanent or temporary false Boolean
true
false
topicAliasMaximum (optional) specifies the maximum number of topic aliases that the MQTT client can support 0 integer 0 to 65535
userProperties (optional) assigns key-value pairs to MQTT 5 messages null array  
willContentType (optional) specifies the content type of the last will message "" string
IanaMediaType
CustomType
willCorrelationData (optional) unique user-defined value used to correlate request-response messages "" JSON 0 to 65,500 bytes
willDelaySeconds (optional) specifies the number of second the server will wait before sending the last will message 60 integer  
willExpirySeconds (optional) specifies the number of seconds before the last will message expires 60 integer  
willPayload contains the payload of the last will message Required - No default value JSON  
willPayloadFormatIndicator (optional) specifies the payload format for the last will message "none" ENUM
"none"
"utf8"
willQoS (optional) specifies the quality of service the publisher used when publishing the will 2 integer  
willResponseTopic (optional) specifies the topic for the last will message response "" string  
willRetain (optional) tells the FairCom server to retain the will message for automatically sending to new subscribers as the first message they receive false Boolean
true
false
willTopic (optional) specifies the topic that the FairCom server will use to publish the will message "" UTF-8 string  
willUserProperties (optional) assigns key-vale pairs to the last will messages [] array  

willUserProperties

.key
(optional)key-value specifies the value in a key-value pair in the userProperties of the last will message "" string n/a

willUserProperties

.value
(optional) specifies the value in a key-value pair in the userProperties of the last will mesage "" string n/a

 

"binaryFormat"

The "binaryFormat" property designates the formatof binary values embedded in JSON strings. The default value for "binaryFormat" is the "defaultBinaryFormat" defined in the "createSession" or "alterSession" actions. If it is omitted there, it defaults to the value of the "defaultBinaryFormat" property in the <faircom>/config/services.json file. If it is not there, the FairCom server defaults it to "hex". Prior to version 13.0.4, the server defaulted it to "base64".

Note Typically, response options apply only to the server’s response, but the "binaryFormat" property applies to both the request and the response.

  • The "binaryFormat" property may occur inside "params",  "responseOptions", "defaultResponseOptions", "result", and "mapOfPropertiesToFields".
    • It occurs in "params" when actions create or change values.
    • It occurs in "responseOptions" when actions return values.
  • When "binaryFormat" occurs in "params" it specifies how the sender represents binary values.
    • For example, when "binaryFormat" is set to "hex", the FairCom server expects the binary values of fields and keys to be represented in strings with hexadecimal format.
  • When "binaryFormat" occurs in "responseOptions" or "defaultResponseOptions" it specifies how the FairCom server should represent binary values in responses.
    • For example, when "binaryFormat" is set to "hex", the FairCom server represents binary values in strings with hexadecimal format.
  • When "binaryFormat" occurs in "result", it signifies how binary values are represented.
    • For example, when "binaryFormat" is set to "base64", the FairCom server represents binary values in the response in base64 format.
  • When "binaryFormat" occurs in "mapOfPropertiesToFields", it tells the server how to encode or decode the binary value in a JSON property.
    • For example, including "binaryFormat" in a "tableFieldsToJson" transform step controls how the server takes a raw binary field value and encodes it as a JSON property.
    • For example, including "binaryFormat" in a "jsonToTableFields" or "jsonToDifferentTableFields" transform step controls how the server decodes a binary value in a JSON property so it can store the raw binary value in a field.
  • The following are the possible values for each format.
    • "base64"
      • When the server reads and writes from a binary field, it represents the binary value as a base64 string.
      • Base64 is harder for people to read and convert to binary.
      • Base64 creates the smallest payload for the most efficient data transmission in JSON.
      • "base64" strings contain the characters 0 - 9 , A - Z, a - z, +, /, and =.
    • "hex"
      • When the server reads and writes from a binary field, it represents the binary value as a hexadecimal string.
      • Hexadecimal is easier for people to read and convert to binary.
      • Hexadecimal creates a 30% larger payload than "base64", which makes it less efficient for data transmission.
      • Hexadecimal strings contain the characters 0 - 9 and A - F.
    • "byteArray"
      • When the server reads and writes from a binary field, it represents the binary value as an array of bytes.
      • An array of bytes is easiest for a program to manipulate.
      • An array of bytes creates a larger payload than "base64" and "hex", which makes it less efficient for data transmission.
      • An array of bytes returns a JSON array containing one integer number between 0 and 255 for each byte in the binary value:
        • "aBinaryField": [ 255, 0, 255 ]

 

Example requests

 
Create a "binary_test" table

This example creates a table containing one binary field named "bin" with a fixed length of 5 bytes.

{
  "api": "db",
  "action": "createTable",
  "params": {
    "tableName": "binary_test",
    "fields": [
      {
        "name": "bin",
        "type": "binary",
        "length": 5
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Insert a record into the "binary_test" table using an array of bytes format

This example inserts a record with the ASCII characters "123" in the "bin" field. The value of "bin" is represented as an array of bytes.

{
  "api": "db",
  "action": "insertRecords",
  "params": {
    "tableName": "binary_test",
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "sourceData": [
      {
        "bin": [49,50,51]
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Insert a record into the "binary_test" table using hexadecimal format

This example inserts a record with the ASCII characters "123" in the "bin" field. The value of "bin" is represented as a string in hexadecimal format.

{
  "api": "db",
  "action": "insertRecords",
  "params": {
    "tableName": "binary_test",
    "dataFormat": "objects",
    "binaryFormat": "hex",
    "sourceData": [
      {
        "bin": "313233"
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Insert a record into the "binary_test" table using base64 format

This example inserts a record with the ASCII characters "123" in the "bin" field. The value of "bin" is represented as a string in base64 format.

{
  "api": "db",
  "action": "insertRecords",
  "params": {
    "tableName": "binary_test",
    "dataFormat": "objects",
    "binaryFormat": "base64",
    "sourceData": [
      {
        "bin": "MTIz"
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Retrieve a record with "binaryFormat" as an array of bytes

This example requests the first record in the "binary_test" table with the value of "bin" represented as an array of bytes.

{
  "api": "db",
  "action": "getRecordsByTable",
  "params": {
    "tableName": "binary_test",
    "maxRecords": 1
  },
  "responseOptions": {
    "binaryFormat": "byteArray",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Response examples

Note Our examples insert only 3 bytes into "bin". Because the "bin" field has a fixed length of 5 bytes, the server pads unused bytes with 0x00 and stores the result. When a record is retrieved, the server returns all 5 bytes.

{
  "result": {
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "fields": [
      { "name": "id",       "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": false, "primaryKey": 1 },
      { "name": "changeId", "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 },
      { "name": "bin",      "type": "binary", "length": 5,    "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 }
    ],
    "data": [
      {
        "bin": [49,50,51,0,0],
        "changeId": 50217,
        "id": 1
      }
    ],
    "moreRecords": true,
    "requestedRecordCount": 1,
    "returnedRecordCount": 1,
    "totalRecordCount": 3
  },
  "errorCode": 0,
  "errorMessage": "",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Retrieve a record with "binaryFormat" as hexadecimal

This example requests the first record in the "binary_test" table with the value of "bin" represented as a hexadecimal string.

{
  "api": "db",
  "action": "getRecordsByTable",
  "params": {
    "tableName": "binary_test",
    "maxRecords": 1
  },
  "responseOptions": {
    "binaryFormat": "hex",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Response
{
  "result": {
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "fields": [
      { "name": "id",       "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": false, "primaryKey": 1 },
      { "name": "changeId", "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 },
      { "name": "bin",      "type": "binary", "length": 5,    "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 }
    ],
    "data": [
      {
        "bin": "3132330000",
        "changeId": 50217,
        "id": 1
      }
    ],
    "moreRecords": true,
    "requestedRecordCount": 1,
    "returnedRecordCount": 1,
    "totalRecordCount": 3
  },
  "errorCode": 0,
  "errorMessage": "",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}


 

Retrieve a record with "binaryFormat" as base64

This example requests the first record in the "binary_test" table with the value of "bin" represented as a base64 string.

{
  "api": "db",
  "action": "getRecordsByTable",
  "params": {
    "tableName": "binary_test",
    "maxRecords": 1
  },
  "responseOptions": {
    "binaryFormat": "base64",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Response
{
  "result": {
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "fields": [
      { "name": "id",       "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": false, "primaryKey": 1 },
      { "name": "changeId", "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 },
      { "name": "bin",      "type": "binary", "length": 5,    "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 }
    ],
    "data": [
      {
        "bin": "MTIzAAA=",
        "changeId": 50217,
        "id": 1
      }
    ],
    "moreRecords": true,
    "requestedRecordCount": 1,
    "returnedRecordCount": 1,
    "totalRecordCount": 3
  },
  "errorCode": 0,
  "errorMessage": "",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

"cleanSession"

The "cleanSession" property is a synonym for "temporarySession" (see temporarySession). It exists for name compatibility with MQTT. Use "temporarysession" because its name is more intuitive.

This property is an optional Boolean property. It defaults to false when omitted or set to null. When true, the MQ engine resets the current session, and when the client disconnects, the engine removes the session's settings, subscriptions, and message position. Because you normally want the engine to remember your message position between sessions, you rarely set "cleanSession" to true.

 

"clientNames"

The "clientNames" property is an optional array containing 0 or more "clientName" strings. It is the client identifier (or clientId) in the MQTT protocol. It uniquely identifies an MQ session, which contains information about a client's subscriptions, settings, and queue position of each topic to which the client is subscribed. The FairCom MQ engine stores this information and retrieves it when an MQTT or MQ API client connects.

Connection authorization is done using an account name with a password or a client certificate.

The "clientName" property does not authorize an MQTT or MQ API session. Another authentication technique authorizes the connection, such as an account name and password or a client certificate. Thus, any account may be used to authorize an MQ connection. Each account is assigned to roles that authorize access to specific topics, client names, actions, etc.

The MQ API allows multiple processes to simultaneously use the same client name to manage sessions, subscribe to topics, send messages to topics, and retrieve messages from topics. 

The MQTT protocol allows only one connection per client identifier because each connection is stateful. If another client with the same "clientName" is already connected, the FairCom server disconnects the other client and vice-versa.

 

"keepAliveSeconds"

The "keepAliveSeconds" property is an optional integer that specifies how often (in seconds) the broker expects a message to be sent. The server will retain a temporary session as long as the client performs an MQ Message action within the keep alive timeout period, which is "keepAliveSeconds" x 1.5. Once there is no activity, the server starts the session expiry timer to remove the temporary session. If there is no session activity within the number of seconds specified in the "sessionExpiryInternal" property, the server removes the session.

 

"label"

The optional "label" property assigns a label to an object. The "label" object contains "group" and "name" properties that uniquely identify a label. If you omit the "group" and "name" properties, they default to the empty string, "", which is a valid group and name for a label.

A label is a tag that you can add to some objects, such as an MQTT topic or session. You can use list actions such as "listTopics" and "listMqSessions" to find objects with a specific label.

The "label" property is mutually exclusive from the "labelId" property.

 

Example

"label": {
 "group": "group name",
 "name": "label name"
}

 

"group"

The optional "group" property is a child of the "label" property. It defaults to "", which is a valid group name.

A label's "group" and "name" properties work together to uniquely identify a label. If you omit the "group" and "name" properties, they default to the empty string, "", which is a unique and valid natural identifier for a label.

The "labelId" property is another way to uniquely identify a label.

 

Example

"label": {
  "group": "group name",
  "name": "label name"
}

 

"name"

The optional "name" property is a child of the "label" property. It defaults to "", which is a valid label name.

A label's "group" and "name" properties work together to uniquely identify a label. If you omit the "group" and "name" properties, they default to the empty string, "", which is a unique and valid natural identifier for a label.

The "labelId" property is another way to uniquely identify a label.

 

Example

"label": {
  "group": "group name",
  "name": "label name"
}

 

"labelId"

The optional "labelId" property assigns a label to an object. The "labelId" property uniquely identifies a label.

A label is a tag that you can add to some objects, such as an MQTT topic or session. You can use list actions such as "listTopics" and "listMqSessions" to find objects with a specific label.

The "labelId" property is mutually exclusive with the "label" property.

 

Example

"labelId": 423

 

"maxHealthyBacklogRatePerMinute"

The "maxHealthyBacklogRatePerMinute" property sets the maximum number of backlog messages per minute for a healthy session. A backlog message is one the server has not yet published to subscribers. The backlog of a topic grows when the incoming message rate exceeds the outgoing. You can set it to any positive integer or whole number, such as 10 or 0.1. The default value is 0, which sets no upper bound.

A connected session is healthy when its message backlog rate does not exceed the maximum. The "describeMqSessions" action returns the "maxHealthyBacklogRatePerMinute" property and the "sessionHealth" property to report the health of a session.

 

"maxHealthySendRatePerMinute"

The "maxHealthySendRatePerMinute" property sets the maximum number of messages per minute for a healthy session. You can set it to any positive integer or whole number, such as 10 or 0.1. The default value is 0, which sets no upper bound.

A connected session is healthy when its message send rate does not exceed the maximum. The "describeMqSessions" action returns the "maxHealthySendRatePerMinute" property and the "sessionHealth" property to report the health of a session.

 

"maxHealthySubscribedTopicFiltersCount"

The "maxHealthySubscribedTopicFiltersCount" property sets the maximum number of topic filters for a healthy session. You can set it to any positive integer, such as 10. The default value is 0, which sets no upper bound.

A connected session is healthy when it has subscribed to at most the maximum number of topic filters. The "describeMqSessions" action returns the "maxHealthySubscribedTopicFiltersCount" property and the "sessionHealth" property to report the health of a session.

A topic filter may include MQTT wildcard characters, which allows one topic filter to subscribe to many topics. The "maxHealthySubscribedTopicFiltersCount" property does not limit the number of topics.

 

"maximumPacketSize"

The "maximumPacketSize" property is an optional integer that specifies the maximum size of a single packet that the session can receive.

 

"minHealthySendRatePerMinute"

The "minHealthySendRatePerMinute" property sets the minimum number of messages per minute for a healthy session. You can set it to any positive integer or whole number, such as 10 or 0.1. The default value is 0, which sets no lower bound.

A connected session is healthy when its message send rate exceeds the minimum. The "describeMqSessions" action returns the "minHealthySendRatePerMinute" property and the "sessionHealth" property to report the health of a session.

 

"minHealthySubscribedTopicFiltersCount"

The "minHealthySubscribedTopicFiltersCount" property sets the minimum number of topic filters for a healthy session. You can set it to any positive integer, such as 10. The default value is 0, which sets no lower bound.

A connected session is healthy when it has subscribed to at least the minimum number of topic filters. The "describeMqSessions" action returns the "minHealthySubscribedTopicFiltersCount" property and the "sessionHealth" property to report the health of a session.

A topic filter may include MQTT wildcard characters, which allows one topic filter to subscribe to many topics. The "minHealthySubscribedTopicFiltersCount" property does not limit the number of topics the wildcards match - rather, it establishes a lower bound on the number of subscribed topic filters an MQ Session is allowed to have.

 

"mqttProtocol"

The "mqttProtocol" property is an optional enumerated string that specifies the version of MQTT protocol to use in your session. This property currently accepts the following values:

  • "5.0"
  • "3.1.1"

 

"receiveMaximum"

The "receiveMaximum" property is an optional integer that specifies the maximum number of QoS 1 and QoS 2 publish messages that the MQTT client is willing to process concurrently.

 

"requestProblemInformation"

The "requestProblemInformation" property is an optional Boolean that specifies whether or not to include problem Information in the response.

 

"requestResponseInformation"

The "requestResponseInformation" property is an optional Boolean that specifies whether or not to include response information in the response.

 

"sessionExpiryInterval"

The "sessionExpiryInterval" property specifies the number of seconds that a temporary session can be inactive before the server deactivates it. This property defaults to 0 when "temporarySession" is true and to 4294967296 when "temporarySession" is false. When a temporary session expires, the server removes its subscriptions and message delivery queue. 

The "sessionExpiryInterval" property has no effect on a permanent session because it does not expire. 

  • Set "sessionExpiryInterval" to 0 to expire a temporary session when the JSON action session closes.
  • Set "sessionExpiryInterval" to a value between 0 and 4294967296 to expire the session when it has been inactive for the specified number of seconds.
  • Set "sessionExpiryInterval" to 4294967296 to never expire the session.

The "temporarySession" property sets the value of the "sessionExpiryInterval" property.

  • If "temporarySession" is true, the server defaults "sessionExpiryInterval" to 0 so that a temporary session expires by default when the JSON session expires.
  • If "temporarySession" is false, the server sets "sessionExpiryInterval" to 4294967296.

 

"sessionHealth"

The "sessionHealth" property is included in the response to the "describeMqSessions" action. It is an enumerated string with the following values: "healthy", "unhealthy", and "offline":

The server excludes a metric from the calculation when it is set to the default value of 0.

The session health properties include: 

  • "minHealthySendRatePerMinute" 
  • "maxHealthySendRatePerMinute" 
  • "maxHealthyBacklogRatePerMinute" 
  • "minHealthySubscribedTopicFiltersCount" 
  • "maxHealthySubscribedTopicFiltersCount"

 

"sessionStatus"

The "sessionStatus" property specifies the status of an MQTT or MQ API session as "normal", "hidden", "banned", or "inactive" to hide its visibility in API results and the dashboard views, ban a client from connecting, or mark a client as inactive. A banned session prevents clients from using the session to publish and subscribe to messages. When "sessionStatus" is omitted, it defaults to "normal".

  • "normal" resets a client to its default normal state. The client is not hidden in API results and dashboard views and may connect, publish, and subscribe to messages. The engine preserves all information about the client. Use it to unhide, unban, and activate a client.
  • "hidden"  hides a client from most API results and dashboard views while allowing the client to connect, publish, and subscribe to messages. The engine preserves all information about the client. Use it to hide administrative client connections.
  • "banned"  prevents a client from connecting in the future while preserving all information about the client. Use it to prevent unwanted clients from connecting again using the session's "clientName" to publish and subscribe to messages.
  • "inactive" marks a client session as inactive while allowing the client to connect, publish, and subscribe to messages. The server does not remove an "inactive" session's data so that historical message data sent and received by the client can continue to be associated with the deleted client. If a client connects to an inactive session, the server changes the session to "normal".
    • Use the "deleteMqSession" action to permanently delete the session which removes all session information. The server can no longer associate sent and received messages with the client. The client can reconnect in the future to establish a new session, but this will create a new session. It is common to permanently delete temporary client connections created during testing and troubleshooting.

 

"temporarySession"

The "temporarySession" property is an optional Boolean property that defaults to false when omitted or set to null. It is used in the "createMqApiSession" and "alterMqSession" actions to make a session temporary or permanent. When set to true, the session is temporary; otherwise, it is permanent.

When true, the MQ engine resets the current session, and when the client disconnects, the engine removes the session's settings, subscriptions, and message position. Because you normally want the engine to remember your message position between sessions, you rarely set "temporarySession" to true.

Use the "temporarySession" property to control session permanency rather than the "cleanSession" property because its name is more intuitive. The server returns an error if you include both and set them to opposite values.

 

"topicAliasMaximum"

The "topicAliasMaximum" property is an optional integer that specifies the maximum number of topic aliases that the MQTT client can support.

 

"userProperties"

The "userProperties" property is optional in the "publishMessagesToMq" action and defaults to null. When present, it is an array of key-value objects. A key-value object contains a "key" property and a "value" property with string values. You can assign multiple key-value pairs to an MQTT 5 message; the server includes them in the messages it delivers to subscribers. The server may process specific key-value pairs as instructions that modify its behavior.

"userProperties": [
  {
    "key": "some key",
    "value": "some value"
  }
]

 

"willContentType"

The "willContentType" property is an optional string that specifies the content type of the last will message.

 

"willCorrelationData"

The "willCorrelationData" property is an optional JSON value that can be used to set will request-response messages.

 

"willDelaySeconds"

The "willDelaySeconds" property is an optional integer that specifies the number of seconds the server will wait before sending the last will message.

 

"willExpirySeconds"

The "willExpirySeconds" property is an optional integer that specifies the number of seconds before the last will message expires.

 

"willPayload"

The "willPayload" property is required when a will message is present. It contains the payload of the last will message. You can set it to any JSON value, including binary values embedded in a JSON string or array.

 

"willPayloadFormatIndicator"

The "willPayloadFormatIndicator" property is an optional enumerated value that specifies the payload format for the last will message.

 

"willQos"

The property "willQoS" is reserved. The server sets it to 2.

 

"willResponseTopic"

The "willResponseTopic" property is an optional string that specifies the topic for the last will message response.

 

"willRetain"

The "willRetain" property is optional. It defaults to false. When true, it tells the FairCom server to send the will message to new subscribers as the first message they receive when subscribing to a topic.

 

"willTopic"

The "willTopic" property is optional. It is a UTF-8 string containing the topic that the FairCom server will use to publish the will message. If you set it to an empty string, "", null, or omit it, the FairCom server will not add the will message to the connection.

 

"willUserProperties"

The "willUserProperties" property is an optional array that assigns key-value pairs to the last will messages.

 

"result"

For a list and detailed description of the common properties in the response message, see jsonAction response. Properties that are contained in both "params" and "result" will appear in the "params" table above.

createMqApiSession "result" property summaries
Property Description Type Limits (inclusive)
connectionStatus indicates if and how a client is connected to an MQ session. string
"disconnected"
"connected"
"connectedTemporarily"
dataFormat specifies what format the results will be returned in. string
"arrays"
"objects"
defaultBinaryFormat specifies the default value for the "binaryFormat" property, which tells the server how to parse binary data from the client, making it useful when the binary format is not specified in the action request. string
"base64"
"hex"
"byteArray"
defaultVariantFormat specifies the default value of the "variantFormat" property when a JSON Action request does not include it. string  
defaultResponseOptions specifies a default value for "responseOptions" that is used by default in all other action calls object
"numberFormat"
"dataFormat"
"binaryFormat"
"variantFormat"
defaultResponseOptions.
binaryFormat
specifies the format in which binary values are returned string
"base64"
"hex"
"byteArray"
defaultResponseOptions.
variantFormat
specifies the format in which variant fields are returned string
"variant"
"base64"
"hex"
"utf8"
defaultResponseOptions.
dataFormat
specifies what format the results will be returned in string
"default"
"arrays"
"objects"
defaultResponseOptions.
numberFormat
specifies how numbers are formatted in the JSON response message string
"number"
"string"

label

.deprecated
specifies whether a label is deprecated or not. Boolean
true
false
null

label

.description
describes a label. string 1 to 65,500 bytes

label

.enum
assigns an integer number to a label. smallint -32768 to 32767

label

.Id
uniquely identifies a label. integer 0 to 65500

label

.metadata
assigns metadata to a label. JSON 0 to 65,500 bytes

label

.sequence
specifies the numerical order of labels within a group. double Any floating point or integer number

label

.value
assigns a value to a label. JSON 0 to 65,500 bytes
numberFormat specifies how numbers are formatted in the JSON response message string
"number"
"string"
sessionPresent specifies whether or not the broker will use a previously stored session state, which includes the client's previous descriptions. Boolean
false
true
sessionType specifies which type of session the requested client is currently running. string
"mqApi"
"mqtt"
"both"
username specifies the account name of a user or application. string 1 to 64 bytes
variantFormat specifies the format in which variant fields are returned string
"variant"
"base64"
"hex"
"utf8"

 

"connectionStatus"

The "connectionStatus" property is returned by the "describeMqSessions" action to indicate if and how a client is connected to an MQ session. It has the following values:

  • "disconnected" indicates no device or software is connected to the MQ session.
  • "connected" indicates a device or software has established a permanent connection to the MQ session.
  • "connectedTemporarily" indicates a device or software has established a temporary connection to the MQ session. When the device or software disconnects, the server removes the data associated with the MQ session.

 

"defaultBinaryFormat"

The "binaryFormat" property designates the formatof binary values embedded in JSON strings. The default value for "binaryFormat" is the "defaultBinaryFormat" defined in the "createSession" or "alterSession" actions. If it is omitted there, it defaults to the value of the "defaultBinaryFormat" property in the <faircom>/config/services.json file. If it is not there, the FairCom server defaults it to "hex". Prior to version 13.0.4, the server defaulted it to "base64".

Note Typically, response options apply only to the server’s response, but the "binaryFormat" property applies to both the request and the response.

  • The "binaryFormat" property may occur inside "params",  "responseOptions", "defaultResponseOptions", "result", and "mapOfPropertiesToFields".
    • It occurs in "params" when actions create or change values.
    • It occurs in "responseOptions" when actions return values.
  • When "binaryFormat" occurs in "params" it specifies how the sender represents binary values.
    • For example, when "binaryFormat" is set to "hex", the FairCom server expects the binary values of fields and keys to be represented in strings with hexadecimal format.
  • When "binaryFormat" occurs in "responseOptions" or "defaultResponseOptions" it specifies how the FairCom server should represent binary values in responses.
    • For example, when "binaryFormat" is set to "hex", the FairCom server represents binary values in strings with hexadecimal format.
  • When "binaryFormat" occurs in "result", it signifies how binary values are represented.
    • For example, when "binaryFormat" is set to "base64", the FairCom server represents binary values in the response in base64 format.
  • When "binaryFormat" occurs in "mapOfPropertiesToFields", it tells the server how to encode or decode the binary value in a  JSON property.
    • For example, including "binaryFormat" in a "tableFieldsToJson" transform step controls how the server takes a raw binary field value and encodes it as a JSON property.
    • For example, including "binaryFormat" in a "jsonToTableFields" or "jsonToDifferentTableFields"  transform step controls how the server decodes a binary value in a JSON property so it can store the raw binary value in a field.
  • The following are the possible values for each format.
    • "base64"
      • When the server reads and writes from a binary field, it represents the binary value as a base64 string.
      • Base64 is harder for people to read and convert to binary.
      • Base64 creates the smallest payload for the most efficient data transmission in JSON.
      • "base64" strings contain the characters 0 - 9 , A - Z, a - z, +, /, and =.
    • "hex"
      • When the server reads and writes from a binary field, it represents the binary value as a hexadecimal string.
      • Hexadecimal is easier for people to read and convert to binary.
      • Hexadecimal creates a 30% larger payload than "base64", which makes it less efficient for data transmission.
      • Hexadecimal strings contain the characters 0 - 9 and A - F.
    • "byteArray"
      • When the server reads and writes from a binary field, it represents the binary value as an array of bytes.
      • An array of bytes is easiest for a program to manipulate.
      • An array of bytes creates a larger payload than "base64" and "hex", which makes it less efficient for data transmission.
      • An array of bytes returns a JSON array containing one integer number between 0 and 255 for each byte in the binary value:
        • "aBinaryField": [ 255, 0, 255 ]

 

Example requests

 

Create a "binary_test" table

This example creates a table containing one binary field named "bin" with a fixed length of 5 bytes.

{
  "api": "db",
  "action": "createTable",
  "params": {
    "tableName": "binary_test",
    "fields": [
      {
        "name": "bin",
        "type": "binary",
        "length": 5
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Insert a record into the "binary_test" table using an array of bytes format

This example inserts a record with the ASCII characters "123" in the "bin" field. The value of "bin" is represented as an array of bytes.

{
  "api": "db",
  "action": "insertRecords",
  "params": {
    "tableName": "binary_test",
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "sourceData": [
      {
        "bin": [49,50,51]
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Insert a record into the "binary_test" table using hexadecimal format

This example inserts a record with the ASCII characters "123" in the "bin" field. The value of "bin" is represented as a string in hexadecimal format.

{
  "api": "db",
  "action": "insertRecords",
  "params": {
    "tableName": "binary_test",
    "dataFormat": "objects",
    "binaryFormat": "hex",
    "sourceData": [
      {
        "bin": "313233"
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Insert a record into the "binary_test" table using base64 format

This example inserts a record with the ASCII characters "123" in the "bin" field. The value of "bin" is represented as a string in base64 format.

{
  "api": "db",
  "action": "insertRecords",
  "params": {
    "tableName": "binary_test",
    "dataFormat": "objects",
    "binaryFormat": "base64",
    "sourceData": [
      {
        "bin": "MTIz"
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Retrieve a record with "binaryFormat" as an array of bytes

This example requests the first record in the "binary_test" table with the value of "bin" represented as an array of bytes.

{
  "api": "db",
  "action": "getRecordsByTable",
  "params": {
    "tableName": "binary_test",
    "maxRecords": 1
  },
  "responseOptions": {
    "binaryFormat": "byteArray",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Responses

Note Our examples insert only 3 bytes into "bin". Because the "bin" field has a fixed length of 5 bytes, the server pads unused bytes with 0x00 and stores the result. When a record is retrieved, the server returns all 5 bytes.

{
  "result": {
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "fields": [
      { "name": "id",       "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": false, "primaryKey": 1 },
      { "name": "changeId", "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 },
      { "name": "bin",      "type": "binary", "length": 5,    "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 }
    ],
    "data": [
      {
        "bin": [49,50,51,0,0],
        "changeId": 50217,
        "id": 1
      }
    ],
    "moreRecords": true,
    "requestedRecordCount": 1,
    "returnedRecordCount": 1,
    "totalRecordCount": 3
  },
  "errorCode": 0,
  "errorMessage": "",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 
Retrieve a record with "binaryFormat" as hexadecimal

This example requests the first record in the "binary_test" table with the value of "bin" represented as a hexadecimal string.

{
  "api": "db",
  "action": "getRecordsByTable",
  "params": {
    "tableName": "binary_test",
    "maxRecords": 1
  },
  "responseOptions": {
    "binaryFormat": "hex",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}
 
Response
{
  "result": {
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "fields": [
      { "name": "id",       "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": false, "primaryKey": 1 },
      { "name": "changeId", "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 },
      { "name": "bin",      "type": "binary", "length": 5,    "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 }
    ],
    "data": [
      {
        "bin": "3132330000",
        "changeId": 50217,
        "id": 1
      }
    ],
    "moreRecords": true,
    "requestedRecordCount": 1,
    "returnedRecordCount": 1,
    "totalRecordCount": 3
  },
  "errorCode": 0,
  "errorMessage": "",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}


 
Retrieve a record with "binaryFormat" as base64

This example requests the first record in the "binary_test" table with the value of "bin" represented as a base64 string.

{
  "api": "db",
  "action": "getRecordsByTable",
  "params": {
    "tableName": "binary_test",
    "maxRecords": 1
  },
  "responseOptions": {
    "binaryFormat": "base64",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}
 
Response
{
  "result": {
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "fields": [
      { "name": "id",       "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": false, "primaryKey": 1 },
      { "name": "changeId", "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 },
      { "name": "bin",      "type": "binary", "length": 5,    "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 }
    ],
    "data": [
      {
        "bin": "MTIzAAA=",
        "changeId": 50217,
        "id": 1
      }
    ],
    "moreRecords": true,
    "requestedRecordCount": 1,
    "returnedRecordCount": 1,
    "totalRecordCount": 3
  },
  "errorCode": 0,
  "errorMessage": "",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

"defaultVariantFormat"

The "defaultVariantFormat" property sets the default value of the "variantFormat" property when a JSON Action request does not include it.

 

"defaultResponseOptions"

The "defaultResponseOptions" property is a "responseOptions" object. It defines a default value for "responseOptions" that is used by default in all other action calls. It defaults to an empty object.

JSON NAV allows you to choose how your program detects errors. By default, all error properties are included in each response – unless you override this behavior as shown in the example.

The example omits the error object in all responses which makes it easier for statically typed languages, such as C, C++, Java, C#, and VB, because they prefer properties to always be present. To help these languages, the "errorCode", "errorMessage", and "errorData" properties are always present whether there is an error or not.

Example

 "defaultResponseOptions": {
      "binaryFormat": "hex",
      "dataFormat": "objects",
      "numberFormat": "number",
      "variantFormat": "json"
    }

 

"binaryFormat"

The "binaryFormat" property designates the format of binary values embedded in JSON strings. The default value for "binaryFormat" is the "defaultBinaryFormat" defined in the "createSession" or "alterSession" actions. If it is omitted there, it defaults to the value of the "defaultBinaryFormat" property in the <faircom>/config/services.json file. If it is not there, the FairCom server defaults it to "hex". Prior to version 13.0.4, the server defaulted it to "base64".

Note Typically, response options apply only to the server’s response, but the "binaryFormat" property applies to both the request and the response.

  • The "binaryFormat" property may occur inside "params",  "responseOptions", "defaultResponseOptions", "result", and "mapOfPropertiesToFields".
    • It occurs in "params" when actions create or change values.
    • It occurs in "responseOptions" when actions return values.
  • When "binaryFormat" occurs in "params" it specifies how the sender represents binary values.
    • For example, when  "binaryFormat" is set to "hex", the FairCom server expects the binary values of fields and keys to be represented in strings with hexadecimal format.
  • When "binaryFormat" occurs in "responseOptions" or "defaultResponseOptions" it specifies how the FairCom server should represent binary values in responses.
    • For example, when "binaryFormat" is set to "hex", the FairCom server represents binary values in strings with hexadecimal format.
  • When "binaryFormat" occurs in "result", it signifies how binary values are represented.
    • For example, when "binaryFormat" is set to "base64", the FairCom server represents binary values in the response in base64 format.
  • When "binaryFormat" occurs in "mapOfPropertiesToFields", it tells the server how to encode or decode the binary value in a JSON property.
    • For example, including "binaryFormat" in a "tableFieldsToJson" transform step controls how the server takes a raw binary field value and encodes it as a JSON property.
    • For example, including "binaryFormat" in a "jsonToTableFields" or "jsonToDifferentTableFields"  transform step controls how the server decodes a binary value in a JSON property so it can store the raw binary value in a field.
  • The following are the possible values for each format.
    • "base64"
      • When the server reads and writes from a binary field, it represents the binary value as a base64 string.
      • Base64 is harder for people to read and convert to binary.
      • Base64 creates the smallest payload for the most efficient data transmission in JSON.
      • "base64" strings contain the characters 0 - 9 , A - Z, a - z, +, /, and =.
    • "hex"
      • When the server reads and writes from a binary field, it represents the binary value as a hexadecimal string.
      • Hexadecimal is easier for people to read and convert to binary.
      • Hexadecimal creates a 30% larger payload than "base64", which makes it less efficient for data transmission.
      • Hexadecimal strings contain the characters 0 - 9 and A - F.
    • "byteArray"
      • When the server reads and writes from a binary field, it represents the binary value as an array of bytes.
      • An array of bytes is easiest for a program to manipulate.
      • An array of bytes creates a larger payload than "base64" and "hex", which makes it less efficient for data transmission.
      • An array of bytes returns a JSON array containing one integer number between 0 and 255 for each byte in the binary value:
        • "aBinaryField": [ 255, 0, 255 ]

 

Example requests

 
Create a "binary_test" table

This example creates a table containing one binary field named "bin" with a fixed length of 5 bytes.

{
  "api": "db",
  "action": "createTable",
  "params": {
    "tableName": "binary_test",
    "fields": [
      {
        "name": "bin",
        "type": "binary",
        "length": 5
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Insert a record into the "binary_test" table using an array of bytes format

This example inserts a record with the ASCII characters "123" in the "bin" field. The value of "bin" is represented as an array of bytes.

{
  "api": "db",
  "action": "insertRecords",
  "params": {
    "tableName": "binary_test",
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "sourceData": [
      {
        "bin": [49,50,51]
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Insert a record into the "binary_test" table using hexadecimal format

This example inserts a record with the ASCII characters "123" in the "bin" field. The value of "bin" is represented as a string in hexadecimal format.

{
  "api": "db",
  "action": "insertRecords",
  "params": {
    "tableName": "binary_test",
    "dataFormat": "objects",
    "binaryFormat": "hex",
    "sourceData": [
      {
        "bin": "313233"
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Insert a record into the "binary_test" table using base64 format

This example inserts a record with the ASCII characters "123" in the "bin" field. The value of "bin" is represented as a string in base64 format.

{
  "api": "db",
  "action": "insertRecords",
  "params": {
    "tableName": "binary_test",
    "dataFormat": "objects",
    "binaryFormat": "base64",
    "sourceData": [
      {
        "bin": "MTIz"
      }
    ]
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Retrieve a record with "binaryFormat" as an array of bytes

This example requests the first record in the "binary_test" table with the value of "bin" represented as an array of bytes.

{
  "api": "db",
  "action": "getRecordsByTable",
  "params": {
    "tableName": "binary_test",
    "maxRecords": 1
  },
  "responseOptions": {
    "binaryFormat": "byteArray",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Response examples

Note Our examples insert only 3 bytes into "bin". Because the "bin" field has a fixed length of 5 bytes, the server pads unused bytes with 0x00 and stores the result. When a record is retrieved, the server returns all 5 bytes.

{
  "result": {
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "fields": [
      { "name": "id",       "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": false, "primaryKey": 1 },
      { "name": "changeId", "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 },
      { "name": "bin",      "type": "binary", "length": 5,    "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 }
    ],
    "data": [
      {
        "bin": [49,50,51,0,0],
        "changeId": 50217,
        "id": 1
      }
    ],
    "moreRecords": true,
    "requestedRecordCount": 1,
    "returnedRecordCount": 1,
    "totalRecordCount": 3
  },
  "errorCode": 0,
  "errorMessage": "",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Retrieve a record with "binaryFormat" as hexadecimal

This example requests the first record in the "binary_test" table with the value of "bin" represented as a hexadecimal string.

{
  "api": "db",
  "action": "getRecordsByTable",
  "params": {
    "tableName": "binary_test",
    "maxRecords": 1
  },
  "responseOptions": {
    "binaryFormat": "hex",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Response
{
  "result": {
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "fields": [
      { "name": "id",       "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": false, "primaryKey": 1 },
      { "name": "changeId", "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 },
      { "name": "bin",      "type": "binary", "length": 5,    "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 }
    ],
    "data": [
      {
        "bin": "3132330000",
        "changeId": 50217,
        "id": 1
      }
    ],
    "moreRecords": true,
    "requestedRecordCount": 1,
    "returnedRecordCount": 1,
    "totalRecordCount": 3
  },
  "errorCode": 0,
  "errorMessage": "",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}


 

Retrieve a record with "binaryFormat" as base64

This example requests the first record in the "binary_test" table with the value of "bin" represented as a base64 string.

{
  "api": "db",
  "action": "getRecordsByTable",
  "params": {
    "tableName": "binary_test",
    "maxRecords": 1
  },
  "responseOptions": {
    "binaryFormat": "base64",
    "dataFormat": "objects",
    "numberFormat": "number"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

Response
{
  "result": {
    "dataFormat": "objects",
    "binaryFormat": "byteArray",
    "fields": [
      { "name": "id",       "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": false, "primaryKey": 1 },
      { "name": "changeId", "type": "bigint", "length": null, "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 },
      { "name": "bin",      "type": "binary", "length": 5,    "scale": null, "autoTimestamp": "none", "defaultValue": null, "nullable": true,  "primaryKey": 0 }
    ],
    "data": [
      {
        "bin": "MTIzAAA=",
        "changeId": 50217,
        "id": 1
      }
    ],
    "moreRecords": true,
    "requestedRecordCount": 1,
    "returnedRecordCount": 1,
    "totalRecordCount": 3
  },
  "errorCode": 0,
  "errorMessage": "",
  "authToken": "replaceWithAuthTokenFromCreateSession"
}


 

"dataFormat"

The "dataFormat" property is a case-insensitive string enum that defines the format of the "data" property. The default format is an array of arrays. The alternative is an array of objects. The default for "dataFormat" can be changed during a "createSession" action by assigning a different value to the "dataFormat" property in "defaultResponseOptions".

There are three different (but similar) versions of the "dataFormat" property:

Two of those versions occur in a request, and another occurs in a response. They all indicate how data is formatted.

  • "dataFormat" in the request in "responseOptions" determines how the "data" property in the response is formatted.
    • Possible values include:
      • "arrays"
        • This is the default and causes the server to return results as an array of arrays, which is the most efficient.
      • "objects"
        • This returns results as an array of objects. This is less efficient but is simpler to generate, read, and troubleshoot.
  • "dataFormat" in the request in the "params" object notifies the server how the "sourceData" property is formatted in the request. This version is rarely used because of the default "autoDetect" behavior.
    • Possible values include:
      • "arrays"
        • This causes the server to return results as an array of arrays, which is the most efficient.
      • "objects"
        • This returns results as an array of objects. This is less efficient but is simpler to generate, read, and troubleshoot.
      • "autoDetect"
        • This is the default, and the server automatically detects the format of the data in the "sourceData" property.
  • "dataFormat" in the response shows the client how the server formatted the "data" property.
    • Possible values include:
      • "arrays"
        • This is the default and causes the server to return results as an array of arrays, which is the most efficient.
      • "objects"
        • This returns results as an array of objects. This is less efficient but is simpler to generate, read, and troubleshoot.

 

"variantFormat"

The "variantFormat" property tells the server how to format the values of variant fields in its response to your request.

The "variantFormat" property has one of the following values: "binary", "json", "string", and "variantObject". It tells the server how to store and return values stored in variant fields. 

The server applies the "variantFormat" property to all variant fields affected by a JSON action, such as all variant fields inserted by the "insertRecord" action or all variant fields returned by the "getRecordsByIndex" action. If you want more control, set the "variantFormat" property to "variantObject" and you can use variant objects to independently set the variant type and encoding of each variant field in a JSON action.

A variant field is a flexible, strongly-typed field. It is flexible because each variant field in each record can store any type of data. It is strongly typed because each variant field in each record stores the type of value it contains.

A variant field's type can currently be set to "binary", "json", "string", and "boolean" values. In the future, you will be able to set it to other values, such as "jpeg", "xml", and user-defined types.

The following sections describe each value of the "variantFormat" property.

 

"variantFormat": "binary"

  • Use the "variantFormat": "binary" setting to store and return variant field values as binary values embedded in JSON strings.
  • The "binary" variant type ensures maximum compatibility and performance across all FairCom APIs, including JSON DB, SQL, CTDB, and ISAM.
  • When "variantFormat" is "binary", the server sets the variant's type to "binary" and stores raw bytes in the variant field.
  • The binary value can be any sequence of bytes.
  • The server does not validate the binary value.
  • The "binaryFormat" property specifies how the client and server format binary value. For example, the "hex" value embeds hexadecimal numbers in a JSON string.

 

"variantFormat": "json"

  • Use the "variantFormat": "json" setting to store and return variant field values as JSON values.
  • The "json" variant type provides maximum convenience in FairCom's JSON APIs.
  • The server validates JSON before it assigns it to a variant field.
  • The server converts a variant field to valid JSON before it returns the value of a variant field.
    • The "binaryFormat" property specifies the format of a binary variant value embedded in a JSON string.
    • The "numberFormat" property causes the server to return numbers as JSON numbers or JSON strings containing embedded numbers. All languages and JSON parsers work well with strings containing embedded numbers – even extremely large and small numbers.
  • When "variantFormat" is "json", the server sets the variant's type to "json" and stores a JSON value in the variant field.
    • The server does not store a JSON null; instead it marks the variant field as NULL. If the field is not nullable, the API returns an error.
    • The server stores a JSON string in the variant field as is. It includes the double quotes before and after the string's value and stores escaped characters without decoding them. For example, the server stores the JSON string, "my // string",  as "my // string". The server returns a JSON string exactly as it stores it.
    • The server stores a JSON number in the variant field as is. A number consists of the following ASCII characters 1234567890+-.eE. For example, the server stores the JSON number -123.45 as the ASCII characters -123.45. The server returns a JSON string exactly as it stores it.
    • The server stores a JSON true and false in the variant field as is. It stores and returns the ASCII characters true or false.
    • The server stores a JSON object and array as is. When it validates the JSON, it minimizes whitespace while preserving the ASCII characters representing the actual object or array. For example, the server stores the array [1,2,3]  as the ASCII characters [1,2,3].

 

"variantFormat": "variantObject"

  • Use the "variantFormat": "variantObject" setting to store and return variant field values as a variant object.
  • The variant object defines everything the server and client need to know about a variant, including its type, value, value encoding, and storage encoding.
  • The "variantObject" variant type provides maximum flexibility across all FairCom APIs and programming languages.
  • A variant object is a JSON object containing the following properties: "schema", "value", "valueEncoding", and "type". The "schema" property must have the value "jsonaction.org/schemas/variantObject".
  • When "variantFormat" is "variantObject", the server parses the variant object and uses its properties to determine how to store the variant value.
    • The "value" property contains the variant field's value .
    • The "valueEncoding" property specifies how the value is encoded so the server and client can decode the value. For example, assigning "hex" to "valueEncoding" indicates the "value" property contains a binary value embedded in a string as hexadecimal characters. The server decodes the value before storing it in the variant field. In FairCom's JSON APIs, the "binaryFormat" property in the "responseOptions" object specifies how the server encodes the binary value before returning it.
    • The "type" property specifies the variant's type, such as "json", "binary", and "string". In the future, the FairCom server will support additional types, such as "jpeg", "xml", and user-defined types.
  • When the "insertRecords" and "updateRecords" actions have "variantFormat": "variantObject" in "params", you must assign a variant object to each variant field.
  • A JSON action returns a variant object for a variant field value when you put "variantFormat": "variantObject" in "responseOptions".

 

Variant object examples

 

Binary value in a variant object

Add "binaryFormat": "base64" to "responseOptions" to tell the server to encode the variant value as Base64.

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": "ewogICJrZXkiOiAidmFsdWUiCn0=",
  "valueEncoding": ["base64"],
  "type": "binary"
}

 

Number in a variant object

Add "numberFormat": "string" to "responseOptions" to tell the server to embed the number in a string.

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": "123.45",
  "valueEncoding": ["string"],
  "type": "number"
}

 

Add "numberFormat": "number" to "responseOptions" to tell the server to encode the number as a JSON number.

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": 123.45,
  "type": "number"
}

 

Boolean in a variant object

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": true,
  "type": "boolean"
}

 

String in a variant object

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": "A JSON string with embedded \" double quote.",
  "type": "string"
}

 

JSON in a variant object

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": [1,"2",{"key": "value"}],
  "type": "json"
}

 

"numberFormat"

The "numberFormat" property is an optional, case-insensitive string enum. It defines the format of JSON numbers. The default value for "numberFormat" is the "defaultNumberFormat" defined in the "createSession" or "alterSession" actions. If it is omitted there, it defaults to the value of the "defaultNumberFormat" property in the <faircom>/config/services.json file.

When "numberFormat" occurs in "mapOfPropertiesToFields", it tells the server how to encode or decode a number assigned to a JSON property.

For example, including "numberFormat" in a "tableFieldsToJson" transform step controls if the server encodes a number in a JSON property as a number or a number embedded in a string.

Possible values:
  • "number"
    • This causes the server to return numeric values as JSON numbers, such as -18446744073709551616.000144722494 .
    • This is most efficient.
    • JSON represents numbers are base-ten numbers that may have any number of digits.
    • Large numbers, such as 18446744073709551616.000144722494 are known to cause problems with JSON parsers and some programming languages, such as JavaScript, which are limited to the smaller range and binary rounding errors of IEEE floating point numbers.
  • "string"
    • This returns the server to embed numeric values in JSON strings, such as "18446744073709551616.000144722494".
    • This is slightly less efficient because it includes two extra double quote characters
    • Returning numbers embedded in strings ensures JSON parsers and programming languages will not automatically convert the number to a numeric representation that loses precision, introduces rounding errors, truncates values, or generates errors. This allows your application to control how numbers are processed.
  • Omitted or set to null
    • This defaults to "number".

 

Example request

{
  "action": "someAction",
  "responseOptions":
  {
    "numberFormat": "string"
  },
  "authToken": "replaceWithAuthTokenFromCreateSession"
}

 

"sessionType"

The "sessionType" property specifies which type of session the requested client is currently running. This property can return "mqApi", "mqtt", or "both".

 

"sessionPresent"

Boolean that specifies whether the broker will use a previously stored session state, including the client's previous descriptions. 

 

example

"result": {
  "sessionPresent": false
},

 

"username"

The "username" property is a required string from 1 to 64 bytes. It is the account name of a user or application.

It is required by the "createSession" action for authentication.

All API actions are performed in the context of the account identified by "username". For example, all tables created by an account are owned by the account. All queries use tables owned by the account.

In JSON DB API and JSON Hub API, use the "ownerName" property to cause an action to use a different account name than the value of "username". This allows an account to use tables created by another account and to create tables that are owned by another account.

Unlike other property names, such as "databaseName", "username" is all lowercase.

A zero-length username is invalid.

Note See System limits for requirements of this and all other system properties.

 

"variantFormat"

The "variantFormat" property tells the server how to interpret the variant data included in a JSON Action request.

The "variantFormat" property has one of the following values: "binary", "json", "string", and "variantObject". It tells the server how to store and return values stored in variant fields. 

The server applies the "variantFormat" property to all variant fields affected by a JSON action, such as all variant fields inserted by the "insertRecord" action or all variant fields returned by the "getRecordsByIndex" action. If you want more control, set the "variantFormat" property to "variantObject" and you can use variant objects to independently set the variant type and encoding of each variant field in a JSON action.

A variant field is a flexible, strongly-typed field. It is flexible because each variant field in each record can store any type of data. It is strongly typed because each variant field in each record stores the type of value it contains.

A variant field's type can currently be set to "binary", "json", "string", and "boolean" values. In the future, you will be able to set it to other values, such as "jpeg", "xml", and user-defined types.

The following sections describe each value of the "variantFormat" property.

 

"variantFormat": "binary"

  • Use the "variantFormat": "binary" setting to store and return variant field values as binary values embedded in JSON strings.
  • The "binary" variant type ensures maximum compatibility and performance across all FairCom APIs, including JSON DB, SQL, CTDB, and ISAM.
  • When "variantFormat" is "binary", the server sets the variant's type to "binary" and stores raw bytes in the variant field.
  • The binary value can be any sequence of bytes.
  • The server does not validate the binary value.
  • The "binaryFormat" property specifies how the client and server format binary value. For example, the "hex" value embeds hexadecimal numbers in a JSON string.

 

"variantFormat": "json"

  • Use the "variantFormat": "json" setting to store and return variant field values as JSON values.
  • The "json" variant type provides maximum convenience in FairCom's JSON APIs.
  • The server validates JSON before it assigns it to a variant field.
  • The server converts a variant field to valid JSON before it returns the value of a variant field.
    • The "binaryFormat" property specifies the format of a binary variant value embedded in a JSON string.
    • The "numberFormat" property causes the server to return numbers as JSON numbers or JSON strings containing embedded numbers. All languages and JSON parsers work well with strings containing embedded numbers – even extremely large and small numbers.
  • When "variantFormat" is "json", the server sets the variant's type to "json" and stores a JSON value in the variant field.
    • The server does not store a JSON null; instead it marks the variant field as NULL. If the field is not nullable, the API returns an error.
    • The server stores a JSON string in the variant field as is. It includes the double quotes before and after the string's value and stores escaped characters without decoding them. For example, the server stores the JSON string, "my // string",  as "my // string". The server returns a JSON string exactly as it stores it.
    • The server stores a JSON number in the variant field as is. A number consists of the following ASCII characters 1234567890+-.eE. For example, the server stores the JSON number -123.45 as the ASCII characters -123.45. The server returns a JSON string exactly as it stores it.
    • The server stores a JSON true and false in the variant field as is. It stores and returns the ASCII characters true or false.
    • The server stores a JSON object and array as is. When it validates the JSON, it minimizes whitespace while preserving the ASCII characters representing the actual object or array. For example, the server stores the array [1,2,3]  as the ASCII characters [1,2,3].

 

"variantFormat": "variantObject"

  • Use the "variantFormat": "variantObject" setting to store and return variant field values as a variant object.
  • The variant object defines everything the server and client need to know about a variant, including its type, value, value encoding, and storage encoding.
  • The "variantObject" variant type provides maximum flexibility across all FairCom APIs and programming languages.
  • A variant object is a JSON object containing the following properties: "schema", "value", "valueEncoding", and "type". The "schema" property must have the value "jsonaction.org/schemas/variantObject".
  • When "variantFormat" is "variantObject", the server parses the variant object and uses its properties to determine how to store the variant value.
    • The "value" property contains the variant field's value .
    • The "valueEncoding" property specifies how the value is encoded so the server and client can decode the value. For example, assigning "hex" to "valueEncoding" indicates the "value" property contains a binary value embedded in a string as hexadecimal characters. The server decodes the value before storing it in the variant field. In FairCom's JSON APIs, the "binaryFormat" property in the "responseOptions" object specifies how the server encodes the binary value before returning it.
    • The "type" property specifies the variant's type, such as "json", "binary", and "string". In the future, the FairCom server will support additional types, such as "jpeg", "xml", and user-defined types.
  • When the "insertRecords" and "updateRecords" actions have "variantFormat": "variantObject" in "params", you must assign a variant object to each variant field.
  • A JSON action returns a variant object for a variant field value when you put "variantFormat": "variantObject" in "responseOptions".

 

Variant object examples

 

Binary value in a variant object

Add "binaryFormat": "base64" to "responseOptions" to tell the server to encode the variant value as Base64.

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": "ewogICJrZXkiOiAidmFsdWUiCn0=",
  "valueEncoding": ["base64"],
  "type": "binary"
}

 

Number in a variant object

Add "numberFormat": "string" to "responseOptions" to tell the server to embed the number in a string.

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": "123.45",
  "valueEncoding": ["string"],
  "type": "number"
}

 

Add "numberFormat": "number" to "responseOptions" to tell the server to encode the number as a JSON number.

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": 123.45,
  "type": "number"
}

 

Boolean in a variant object

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": true,
  "type": "boolean"
}

 

String in a variant object

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": "A JSON string with embedded \" double quote.",
  "type": "string"
}

 

JSON in a variant object

{
  "schema": "jsonaction.org/schemas/variantObject",
  "value": [1,"2",{"key": "value"}],
  "type": "json"
}