Environment files

Each file in environments/ describes one self-contained environment: where to connect, what to track there, and where the changes should go. The filename without its extension becomes the environment name, so production.json gives you an environment called production.

These files are watched. Saving one reloads that environment within about a second, which means you can iterate on what you track without restarting anything.

{
  "Provider": "mssql",
  "ConnectionStrings": {
    "PrimaryDatabase": "Server=sql.example.com;Database=PrimaryDB;Trusted_Connection=True;"
  },
  "ChangeTracking": {
    "PollingIntervalSeconds": 30,
    "ExportToFile": true,
    "FilePath": "exports/{environment}/{object}/changes-{timestamp}.json",
    "ExportToApi": false,
    "RetryCount": 3,
    "RetryDelaySeconds": 5,
    "TrackingObjects": [],
    "ApiEndpoints": []
  }
}

Provider ​

The database platform every connection string in this file points at. Optional, defaults to mssql.

One environment is one platform. To track both, write two environment files.

The provider decides how the procedure is invoked and whether Trignis can read a watermark from the server. See the stored procedure contract.

ConnectionStrings ​

A map of key to connection string, in the syntax of the chosen Provider. Keys are referenced by TrackingObjects[].Database.

Values are encrypted in place on first read.

Trignis fills in a few keys, but only when you have not set them yourself:

ChangeTracking ​

Everything in this section is optional. Anything you leave out falls back to your global settings, so it is quite reasonable for this block to contain nothing but TrackingObjects until you find a reason to differ.

TrackingObjects ​

Each entry here is one table you would like watched, paired with the procedure that reads its changes:

{
  "Name": "Items",
  "Database": "PrimaryDatabase",
  "TableName": "dbo.Items",
  "StoredProcedureName": "web.get_itemssync",
  "InitialSyncMode": "Incremental"
}

InitialSyncMode only comes into play when there is no stored version yet, which means the very first run or a reset from the dashboard. You have two options:

• Incremental adopts the current version and exports nothing, so only changes made from that point onwards are sent. This is the default, on the grounds that pointing Trignis at a large table should not immediately push its entire contents downstream.
• Full exports every row first, then continues incrementally. Choose this when the downstream system is starting empty and needs the history.

ApiEndpoints ​

Destinations for the changes Trignis reads. An HTTP endpoint looks like this:

{
  "Key": "webhook",
  "Url": "https://api.example.com/changes",
  "Auth": { "Type": "Bearer", "Token": "..." },
  "CustomHeaders": { "X-Correlation-Id": "{guid}" },
  "EnableCompression": false
}

A queue endpoint lives in the same list and is told apart by the presence of MessageQueueType:

{
  "Key": "rabbit",
  "MessageQueueType": "RabbitMQ",
  "MessageQueue": { "HostName": "localhost", "QueueName": "changes" }
}

It is worth knowing that every endpoint in an environment receives every change from that environment. There is no per-object routing within a single file.

When you need different objects going to different places, splitting them across separate environment files is the way to do it, and it has the pleasant side effect of letting each one have its own polling interval and retry settings.

Placeholders ​

These are available in FilePath, Url and CustomHeaders, which makes it easy to keep exports organised without hardcoding a path per object:

Validation ​

Configuration is validated at startup. Errors stop the service; warnings are logged and it continues. Common errors: a Database with no matching connection string, a missing StoredProcedureName, a queue endpoint with no MessageQueue, an unknown MessageQueueType.