"createMqApiSession"(JSON Action)
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.
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 tofalse(the default) to create a permanent session.When creating a permanent session, the server sets the
"cleanSession"property tofalse,"keepAliveSeconds"to0so it never times out, and"sessionExpiryInterval"to4294967296to 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 totrueto create a temporary session.When creating a temporary session, the server automatically sets the
"cleanSession"property totrueand 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"
}{
"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"
}{
"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",
}
The createMqApiSession action is used to establish a new MQ session exclusively for MQ API interactions, uniquely identified by its clientName. You can create either permanent sessions, which persist until explicitly deleted and are ideal for continuous message operations, or temporary sessions, which are automatically removed after inactivity. While MQ API and MQTT sessions use different protocols, they can interact with the same topics, and their properties can be modified using alterMqSession. This action also allows for initial configuration of session status (normal, hidden, banned, inactive), binary data formatting, and "last will" messages, but it will return an error if the clientName already exists, and it won't disconnect an active MQTT client with the same name.
"params" property summariesProperty | Description | Default | Type | Limits (inclusive) | ||||
|---|---|---|---|---|---|---|---|---|
(optional) specifies how the |
| string | One of the following: | |||||
(optional) synonymous with |
| Boolean |
| |||||
(conditional) specifies the unique name that identifies the client to the FairCom MQ engine. If omitted, the server creates a unique name for the session and returns it in the response. | Required - unless you want the server to generate a unique client name | string | 0 to 65,550 bytes | |||||
(optional) specifies the number of seconds before the server removes the session |
| integer | ||||||
(optional) assigns a label to the object using the label's group and name. |
| object | "label": {
"group": "group name",
"name": "label name"
} | |||||
| (optional) identifies a label using its group description. |
| string | 0 to 64 bytes | ||||
| (optional) identifies a label using its name. |
| string | 0 to 64 bytes | ||||
(optional) assigns a label to the object using the label's ID. |
| integer |
| |||||
(optional) specifies the maximum number of backlog messages per minute for a session to be considered healthy |
| integer | ||||||
(optional) specifies the maximum number of messages per minute for a session to be considered healthy |
| integer | ||||||
(optional) specifies the maximum number of topic filters for a session to be considered healthy |
| integer | ||||||
(optional) specifies the maximum size of a single packet that the session can receive |
| integer | ||||||
(optional) specifies the minimum number of messages per minute for a session to be considered healthy |
| integer | ||||||
(optional) specifies the minimum number of topic filters for a session to be considered healthy |
| integer | ||||||
(optional) specifies the version of MQTT protocol to use in your session |
| string enum |
| |||||
(optional) specifies the maximum number of QoS 1 and QoS 2 publish messages that the MQTT client is willing to process concurrently |
| integer |
| |||||
(optional) specifies whether or not to include problem information in the response |
| Boolean |
| |||||
(optional) specifies whether or not to include response information in the response |
| Boolean |
| |||||
(conditional) specifies the number of seconds that a temporary MQTT session can be inactive before the server deactivates it | If | integer |
| |||||
specifies the status of the session's health | Required - No default value | enum |
| |||||
(optional) specifies the status of an MQTT or MQ API session |
| enum |
| |||||
(optional) specifies whether or not the session will be permanent or temporary |
| Boolean |
| |||||
(optional) specifies the maximum number of topic aliases that the MQTT client can support |
| integer |
| |||||
(optional) assigns key-value pairs to MQTT 5 messages |
| array | ||||||
(optional) specifies the content type of the last will message |
| string |
| |||||
(optional) sets up request-response messages |
| JSON | 0 to 65,500 bytes | |||||
(optional) specifies the number of second the server will wait before sending the last will message |
| integer | ||||||
(optional) specifies the number of seconds before the last will message expires |
| integer | ||||||
(conditional) contains the payload of the last will message | Required when another “will…” property is used; otherwise, | JSON | ||||||
(optional) specifies the payload format for the last will message |
| ENUM |
| |||||
(optional) specifies the quality of service the publisher used when publishing the will |
| integer | ||||||
(optional) specifies the topic for the last will message response |
| string | ||||||
(optional) tells the FairCom server to retain the will message for automatically sending to new subscribers as the first message they receive |
| Boolean |
| |||||
(optional) specifies the topic that the FairCom server will use to publish the will message |
| UTF-8 string | ||||||
(optional) assigns key-value pairs to the last will messages |
| array | ||||||
| (optional) specifies the key in a key-value pair assigned by userProperties |
| string | |||||
| (optional) specifies the value in a key-value pair assigned by userProperties |
| string |
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.
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.
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.
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"
}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"
}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"
}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
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.
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.
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.
The "maximumPacketSize" property is an optional integer that specifies the maximum size of a single packet that the session can receive.
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.
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.
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"
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.
The "requestProblemInformation" property is an optional Boolean that specifies whether or not to include problem Information in the response.
The "requestResponseInformation" property is an optional Boolean that specifies whether or not to include response information in the response.
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"to0to expire a temporary session when the JSON action session closes.Set
"sessionExpiryInterval"to a value between0and4294967296to expire the session when it has been inactive for the specified number of seconds.Set
"sessionExpiryInterval"to4294967296to never expire the session.
The "temporarySession" property sets the value of the "sessionExpiryInterval" property.
If
"temporarySession"istrue, the server defaults"sessionExpiryInterval"to0so that a temporary session expires by default when the JSON session expires.If
"temporarySession"isfalse, the server sets"sessionExpiryInterval"to4294967296.
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":
"healthy"indicates the session is healthy, which occurs when a client is:Connected
Sends at least the expected number of messages per minute (see
"minHealthySendRatePerMinute").Sends less than or equal to the maximum number of messages per minute (see
"maxHealthySendRatePerMinute").Does not exceed the maximum backlog rate of unprocessed subscribed messages (see
"maxHealthyBacklogRatePerMinute").Subscribes to at least the minimum expected number of topic filters ( see
"minHealthySubscribedTopicFiltersCount").Subscribes to no more than the maximum number of expected number of topic filters (see
"maxHealthySubscribedTopicFiltersCount").
"unhealthy"indicates the session is unhealthy, which occurs when a client:Fails to send the expected number of messages per minute (see
"minHealthySendRatePerMinute").Sends more than the maximum number of messages per minute (see
"maxHealthySendRatePerMinute").Exceeds the maximum backlog of unprocessed subscribed messages (see
"maxHealthyBacklogRatePerMinute").Subscribes to less than the minimum number of expected number of topic filters ( see
"minHealthySubscribedTopicFiltersCount").Subscribes to more than the maximum number of expected number of topic filters (see
"maxHealthySubscribedTopicFiltersCount").
"offline"indicates a session is not connected.
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"
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.
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.
The "topicAliasMaximum" property is an optional integer that specifies the maximum number of topic aliases that the MQTT client can support.
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"
}
]The "willContentType" property is an optional string that specifies the content type of the last will message.
The "willCorrelationData" property is an optional JSON value that can be used to set will request-response messages.
The "willDelaySeconds" property is an optional integer that specifies the number of seconds the server will wait before sending the last will message.
The "willExpirySeconds" property is an optional integer that specifies the number of seconds before the last will message expires.
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.
The "willPayloadFormatIndicator" property is an optional enumerated value that specifies the payload format for the last will message.
The property "willQoS" is reserved. The server sets it to 2.
The "willResponseTopic" property is an optional string that specifies the topic for the last will message response.
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.
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.
The "willUserProperties" property is an optional array that assigns key-value pairs to the last will messages.
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.
"result" property summariesProperty | Description | Type | Limits (inclusive) | ||||||
|---|---|---|---|---|---|---|---|---|---|
indicates if and how a client is connected to an MQ session. | string |
| |||||||
specifies what format the results will be returned in. | string |
| |||||||
specifies the default value for the | string |
| |||||||
specifies the default value of the | string | ||||||||
specifies a default value for | object |
| |||||||
| specifies the format in which binary values are returned | string |
| ||||||
| specifies the format in which variant fields are returned | string |
| ||||||
| specifies what format the results will be returned in | string |
| ||||||
| specifies how numbers are formatted in the JSON response message | string |
| ||||||
| specifies whether a label is deprecated or not. | Boolean |
| ||||||
| describes a label. | string | 1 to 65,500 bytes | ||||||
| assigns an integer number to a label. | smallint |
| ||||||
| uniquely identifies a label. | integer | 0 to 65,500 | ||||||
| assigns metadata to a label. | JSON | 0 to 65,500 bytes | ||||||
| specifies the numerical order of labels within a group. | double | Any floating point or integer number | ||||||
| assigns a value to a label. | JSON | 0 to 65,500 bytes | ||||||
specifies how numbers are formatted in the JSON response message | string |
| |||||||
specifies whether or not the broker will use a previously stored session state, which includes the client's previous descriptions | Boolean |
| |||||||
specifies which type of session the requested client is currently running. | string |
| |||||||
specifies the account name of a user or application. | string | 1 to 64 bytes | |||||||
specifies the format in which variant fields are returned | string |
|
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.
The "defaultVariantFormat" property sets the default value of the "variantFormat" property when a JSON Action request does not include it.
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"
}"variantFormat"
The "variantFormat" property tells the server how to format the values of variant fields in its response to your request.
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.
"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.000144722494are 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
nullThis defaults to
"number".
Example request
{
"action": "someAction",
"responseOptions":
{
"numberFormat": "string"
},
"authToken": "replaceWithAuthTokenFromCreateSession"
}
The "sessionType" property specifies which type of session the requested client is currently running. This property can return "mqApi", "mqtt", or "both".
Boolean that specifies whether the broker will use a previously stored session state, including the client's previous descriptions.
Example
"result": {
"sessionPresent": false
},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.
The "variantFormat" property is an optional enumerated string that specifies the format in which variant fields are returned. It may have one of the following values: "variant", "base64", "hex", or "utf8":
"variant"returns a Variant Object containing JSON describing information about the variant value, including its data type and encoding."hex"converts the binary value to hexadecimal and returns the field value as a JSON string."base64"converts the binary value to Base64 and returns the field value as a JSON string."utf8"converts the binary value into a UTF-8 string and returns the value as a JSON string.
The "variantFormat" property converts the variant value into the form an application needs.
Some applications prefer to receive the JSON object form of the variant so they have the metadata describing its data type and how it is encoded. The Variant Object is ideal for web services that transform data.
Some applications prefer to process the variant's raw binary value because they use heuristics to determine the data type. They may want a variant returned as Base64 because it is the most efficient encoding of binary data in a JSON string.
Some applications may prefer to display the variant's raw binary value as a hexadecimal string because they may not have a widget that can display and edit all possible variant values such as numbers, strings, Booleans, images, audio, JSON, XML, etc. When the user wants to view the actual value, the application queries the record again using the
"variantFormat": "variant"setting to get the data type so it can display the value in a more useful manner.
The following examples show the same variant values encoded in various ways.
The first value is a GIF image containing a single black pixel.
The second is the JSON document
{ "myProperty": "myValue" }.The third value is a UTF-8 encoded string
"UTF-8 encoded string".
A "getRecords..." action containing "variantFormat": "variant" causes the server to return a Variant Object for each variant field. A Variant Object is a JSON object with the property "schema": "jsonaction.org/schemas/variantOjbect".
"getRecords..." response containing a GIF image as a Variant Object encoded as Base64{
"data": [
{
"myField": {
"schema": "jsonaction.org/schemas/variantObject",
"value": "R0lGODlhAQABAIAAAAAAAP///yH5BAUAAAEALAAAAAABAAEAAAICRAEAOw==",
"valueEncoding": [ "base64" ],
"type": "gif",
"storageEncoding": ["7z"]
}
}
]
}"getRecords..." response containing the JSON object { "myProperty": "myValue" } as a Variant Object encoded as JSON{
"data": [
{
"myField": {
"schema": "jsonaction.org/schemas/variantObject",
"value": { "myProperty": "myValue" },
"valueEncoding": [ "json" ],
"type": "json",
"storageEncoding": ["7z"]
}
}
]
}"getRecords..." response containing the UTF-8 string "UTF-8 encoded string" as a Variant Object encoded as UTF-8{
"data": [
{
"myField": {
"schema": "jsonaction.org/schemas/variantObject",
"value": "UTF-8 encoded string",
"valueEncoding": [ "utf8" ],
"type": "string",
"storageEncoding": ["7z"]
}
}
]
}A "getRecords..." action containing "variantFormat": "hex" causes the server to return the field value as a Hexadecimal-encoded string instead of a Variable Object.
"getRecords..." response containing a GIF image encoded in Hexadecimal{
"data": [
{
"myField": "47494638396101000100800000000000ffffff21f90405000001002c00000000010001000002024401003b"
}
]
}"getRecords..." response containing the JSON object { "myProperty": "myValue" } encoded in Hexadecimal{
"data": [
{
"myField": "7b20226d7950726f7065727479223a20226d7956616c756522207d"
}
]
}"getRecords..." response containing the UTF-8 string "UTF-8 encoded string" encoded in Hexadecimal{
"data": [
{
"myField": "5554462d3820656e636f64656420737472696e67"
}
]
}A "getRecords..." action containing "variantFormat": "base64" causes the server to return the field value as a Base64-encoded string instead of a Variable Object.
"getRecords..." response containing a GIF image encoded in Base64{
"data": [
{
"myField": "R0lGODlhAQABAIAAAAAAAP///yH5BAUAAAEALAAAAAABAAEAAAICRAEAOw=="
}
]
}"getRecords..." response containing the JSON object { "myProperty": "myValue" } encoded in Base64{
"data": [
{
"myField": "eyAibXlQcm9wZXJ0eSI6ICJteVZhbHVlIiB9"
}
]
}"getRecords..." response containing the UTF-8 string "UTF-8 encoded string" encoded in Base64{
"data": [
{
"myField": "VVRGLTggZW5jb2RlZCBzdHJpbmc="
}
]
}A "getRecords..." action containing "variantFormat": "utf8" causes the server to return the field value as a UTF-8-encoded string instead of a Variable Object.
"getRecords..." response containing a GIF Image encoded as a UTF-8 string{
"data": [
{
"myField": "GIF89a € ÿÿÿ!ù , D ;"
}
]
}"getRecords..." response containing the JSON object { "myProperty": "myValue" } encoded as a UTF-8 string{
"data": [
{
"myField": "{ \"myProperty\": \"myValue\" }"
}
]
}"getRecords..." response containing the UTF-8 string "UTF-8 encoded string"{
"data": [
{
"myField": "UTF-8 encoded string"
}
]
}