Configuration

Configuration

The configuration is loaded out of a configuration file at "config/default.properties".

General

2022-01-01 12:00

Key Value Store

keyvalue.type

Possible Values: mongodb|couchdb|redis

Default: NULL

This parameter specifies which type of Key Value Store to use. If this parameter is not given then no Key Value Store will be available.

keyvalue.cert

Possible Values: “s“ (String, Filepath)

Default: NULL

If you do need a special certificate to authenticate against your Key Value Store (e.g. AWS DocumentDB) then you could give the full path to your certificate file here.

keyvalue.host

Possible Values: “s“ (String, Hostname)

Default: NULL

The host on which the desired Key Value Store could be reached.

keyvalue.username

Possible Values: “s“ (String, Username)

Default: NULL

Specify the username to authenticate against your Key Value Store with.

keyvalue.password

Possible Values: “s“ (String, Password)

Default: NULL

If you need a password to authenticate against your Key Value Store, then your must specify it here.

keyvalue.database

Possible Values: “s“ (String)

Default: NULL

The database or schema – depending on which type of Key Value Store you use – must be given here, if needed.

keyvalue.table

Possible Values: “s“ (String)

Default: “key_value_store“

If your Key Value Store supports collections or tables, then you can change the default one here.

General

app.settings.rules.path

Possible Values: "s" (String, Path)

Default: "./rules/"

This parameter specifies the path in which the Rules file and all resources referenced by the Rules file should be found.

app.settings.rules.filename

Possible Values: "s" (String, Filename)

Default: "rules.json"

If you want to change the default filename of the Rules file, then you have to use this parameter. It should only give a filename without any relative or absolute folder.

Stateful Operation

Normally OTDT is – in the context of actions (the "that") – completely stateless.

If you want (or need) to store special states (cached reading points, own calculations, …) between several calls to OTDT (via the "this") then you need to put OTDT into Stateful Operation.

The reason for this need could be for example …

  • Actions (the "that") based on own calculations initiated by several different triggers (the "this").
  • Emulating Multi-Threading via running several instances on the same machine.
  • Implement high availability via running several instances on different machines.

The following configuration parameters are used to specify Stateful Operation.

app.settings.state.store.type

Possible Values: all|single|none

Default: none

You have to set this parameter to "all" or "single" if you need Stateful Operation. The parameter specifies if the State Store should be stored entirely or for each single operation on it. Stateful Operation will only work via the configured Key Value Store (KVS).

In principle – if you need Stateful Operation – the mode "all" is recommended due to having things faster (only 1 store operation). But, depending on the type of State Lock you will use (see below) and the runtime of your actions (the "that") it may come to piling of incoming requests waiting for being processed.

You then would have to use mode "single" where each single operation on the State Store is stored (slower) which then is available to all other instances immediately (again, depending on the type if State Lock (see below)).

app.settings.state.lock.type

Possible Values: global|local|none

Default: none

If you need to run several instances of OTDT you will have to set this parameter to "global" or "local". The parameter specifies the type of State Lock. While actions (the "that") are executing and OTDT is in Stateful Operation the State Store is locked where this parameter specifies how the lock if managed.

While in "local" mode the State Lock will only be managed on the machine OTDT is running on, so it is only for several instances on the same machine – emulated multi-threading.

When in "global" mode the State Lock will be managed via the configured Key Value Store (KVS) and therefore globally. This means this type of State Lock could and should be used for high availability scenarios where several instances of OTDT are running on different machines.

app.settings.state.lock.timeout

Possible Values: n (Integer value >= 0 in seconds)

Default: 30

With this parameter you specify the timeout in seconds a State Lock will expire.

app.settings.state.lock.wait

Possible Values: n (Integer value >= 0 in milliseconds)

Default: 1000

Use this parameter to define the timeout in milliseconds OTDT will wait for a lock until checking its state again.