Skip to main content

"alterInput"

The JSON Edge API "alterInput" action modifies an existing FairCom Edge input

Abstract

alters, changes, modifies, updates, or configures an existing input connector in FairCom Edge. An input connector collects data automatically from a device or software system.

The "alterInput" action alters an existing input connector in FairCom Edge to collect tags automatically from a device or software system. Before you can alter an input, you must use "createInput" to create it.

Note

A tag is named data, such as a temperature with a value of 70 . In JSON, a tag is a JSON property, such as "temperature": 70. In a SQL table, a tag is a data field, such as a field named temperature with a value of 70.

  • "alterInput" modifies how an input service collects data from a data source, transforms it, and inserts it into an integration table.

    For example, an input can configure the OPC UA service to collect data from an external source and write that data to an integration table in FairCom Edge.

  • You can do the following:

    • You can change the settings of an input.

    • You can change the retention policy of the input’s integration table.

    • You can change the transforms applied to the data when it is inserted into the integration table.

    • You can change metadata about the input to make it easier to locate.

  • You cannot do the following:

    • You cannot change the mapping between the service and the integration table. To do this, you need to create a new input and delete the old one.

    • You cannot remap a connector service to a different integration table because this mapping is fundamental to the nature of the input. In the future, we may enhance this action to be able to remap the connector service to a different integration table, or we may provide a special action just for this purpose.

      The action, "alterInput", is the only way to configure an existing input. If the specified value of "inputName" does not find an existing input, this action returns an error. To create an input, use the "createInput" action.

Request examples

Minimal request example

{
  "api":        "hub",
  "apiVersion": "1.0",
  "requestId":  "optionalUniquerequestIdFromTheClient",
  "authToken":  "anAuthorizationTokenFromTheServer",
  "action":     "alterInput",
  "params":     {
    "inputName":       "AcmefactoryLine1Station1AcidbathTelemetry",
    "retentionPeriod": 15
  }
}
{
  "api":        "hub",
  "apiVersion": "1.0",
  "requestId":  "optionalUniquerequestIdFromTheClient",
  "authToken":  "anAuthorizationTokenFromTheServer",
  "action":     "alterInput",
  "params":     {
    "inputName":       "AcmefactoryLine1Station1AcidbathTelemetry",
    "retentionPolicy": "autoPurge",
    "retentionPeriod": 30,
    "retentionUnit":   "day",
    "metadata":        {
      "description": "a description of what this ",
      "tags":        [ "" ]
    },
    "transformNames":  [ "" ]
  }
}

Response examples

{
    "resulet":{},
    "requestId":"00000005",,
    "errorCode": 0,
    "errorMessage":"
}
{
    "resulet":{},
    "requestId":"00000005",,
    "errorCode": 0,
    "errorMessage":"
}

"params"

The "params" property is an object that contains an action's parameters. Each action defines its own required and optional properties.

Properties summary

Table 1. "params" properties summary

Property

Description

Default

Type

Limits (inclusive)

inputName

contains a unique name for the mapping of a data source to an input plugin to an integration table

A FairCom generated name that follows the pattern "Input #n from <pluginName> to <databaseName>.<ownerName>.<tableName>"

string

1 to 100 bytes

metadata

exists primarily for the user interface to find integration information

{}

object

May contain any number and type of user-defined properties

retentionPeriod

specifies the number of retention units, which controls how long data is retained – see "retentionUnit"

4

integer/string

1 to 100

retentionPolicy

specifies how messages persist

"autoPurge"

string

"autoPurge"
"neverPurge"
"doNotPersist"

retentionUnit

purges expired messages each time this unit cycles – see "retentionPeriod"

"week"

string

"minute"
"hour"
"day"
"week"
"month"
"year"
"forever"

settings

contains properties needed to configure the data source of the specified plugin

{}

object

transformName

specifies the name of a transform process

""

string

1 to 64 bytes



The "metadata" property is an optional JSON object. It exists primarily for the user interface to find integration information. By default, it is an empty JSON object.

Things to know:
  • It contains a flexible set of properties.

  • It typically contains tags and description properties.

Example

{
  "description": "",
  "tags": [""],
  "yourOwnProperties": "usage, purpose, notes, location, etc.",
}

The "retentionPeriod" property specifies how many units of data to retain. It must be an integer value from 1 to 100. It refers to the unit of time specified by the "retentionUnit" property — for example, if "retentionPeriod" is 14 and "retentionUnit" is "day", then message data is retained for 14 days. This property is optional.

If not specified, the default found in the services.json file is used. Initially, it is 4 (weeks).

Automatically purging data is important to ensure that retained data does not consume all storage and shut down the computer. The default value of 4 weeks allows FairCom's servers to store 1 TB of messages when 200 topics send one 2K message per second.

Note

  • If the value is not an integer from 1 to 100, FairCom's servers set it to the default value.

  • Smaller numbers improve SQL performance.

Things to know:
  • Each time the "retentionPeriod" cycles, FairCom's servers automatically and efficiently delete expired data.

  • FairCom's servers only use the "retentionPeriod" property when the "retentionPolicy" is "autoPurge".

  • The "retentionPeriod" can be changed to retain fewer or more messages. Changing it does not necessarily destroy existing data, but data may expire more quickly or be retained longer.

  • The "retentionPeriod" and "retentionUnit" properties control data granularity as well as the retention time.  In other words, "retentionPeriod" defines how many sets of data are stored, and "retentionUnit" defines how often data is purged.

    For example, if "rententionPeriod" is set to 14 , the server stores 14 sets of data. At the beginning of the 15th cycle, the server automatically purges the oldest set of data. If "retentionUnit" is set to day, then data will be purged daily. If set to "week", then data will be purged weekly.

  • The current calendar date affects purging.

    FairCom's servers automatically purge all retained data that has expired. This is noticeable when FairCom's servers come online after having been offline for a long time. When a server comes back online, it automatically purges all expired data.

    For example, if a FairCom server is offline for four weeks when it comes online, it will completely purge all retained data that has a retention time of less than 4 weeks.

The "retentionPolicy" property controls how messages are persisted. This property is optional.

If not specified, the default found in the services.json file is used. Initially, it is "autoPurge".

retentionPolicy values:
  • "autoPurge"

    This is the default. It is automatically applied when a new topic is created. It is preferred because it allows FairCom's servers to automatically remove messages that are older than the retention time. This helps ensure message data does not consume all storage space. It also minimizes storage costs and speeds up data access.

  • "neverPurge"

    This stores messages on disk and never removes them. This is useful when you need the entire history of the message stream. If message velocity is high, this can consume all storage space and cause an outage.

  • "doNotPersist"

    This stores messages only in RAM, where they are transmitted more quickly. Undelivered messages are lost when FairCom's servers stop and restart. No transforms can be applied to the payload. Message data cannot be bridged across protocols.

Important

Changing the "retentionPolicy" property value to "doNotPersist" removes all existing message history for the topic because it changes how messages are stored on disk.

Each time this unit cycles, FairCom purges expired messages. For example, if you want a week's worth of messages to be purged once a week, set "retentionUnit" to "week" . This property is optional.

If not specified, the default found in the services.json file is used. Initially, it is "week"

Things to know:
  • This property is used in concert with "retentionPeriod" to determine retention time.

  • "retentionUnit" values:

    • "minute"

    • "hour"

    • "day"

    • "week"

    • "month"

    • "year"

    • "forever"

Note

  • For best performance, set the "retentionUnit" to a value that keeps "retentionPeriod" between 5 and 30

  • When the "retentionUnit" is set to "forever"  the messages will never be purged.

  • FairCom MQ only uses the "retentionUnit" property when the "retentionPolicy" is "autoPurge".

The "settings" property contains properties that are specific for each connector type. Settings for Modbus are different than settings for OPC UA, and so forth. See the API reference "params" property of each connector for details of the "settings" property for that connector.

Connector-specific "settings"

The "transformName" property is an optional string that contains the unique name of a transform process, which consists of one or more transform steps.

Things to know:
  • A transform is a process that works like a pipeline where the output of one transformation can become the input for another transformation.

  • The following actions use the "transformName" property to assign a transform to an integration table:

    • "configureTopic"

    • "createInput"

    • "alterInput"

    • "alterIntegrationTable"