iWD History Node Configuration
The .yaml configuration file:
- Provides initial log configuration
- Provides configuration for the events migration mechanism from the Event Log database to the History Node database
On startup, History Node attempts to read it from a default location:
However, different .yaml configuration file can be provided by using the -config command-line option.
logging: level: INFO appenders: - type: console - type: file currentLogFilename: /var/log/historynode.log threshold: ALL archive: true archivedLogFilenamePattern: /var/log/historynode-%i.log archivedFileCount: 5 timeZone: UTC maxFileSize: 100MB event-log-migration: solutionId: SLT1 fetchSize: 10 interaction-server: driverClass: com.microsoft.sqlserver.jdbc.SQLServerDriver url: jdbc:sqlserver://<db_host>:<db_port>;databaseName=inx_db user: <db_username> password: <db_password> eventlog: driverClass: com.microsoft.sqlserver.jdbc.SQLServerDriver url: jdbc:sqlserver://<db_host>:<db_port>;databaseName=eventlog_db user: <db_username> password: <db_password>
- logging—Defines History Node logging configuration.
- event-log-migration—Contains configuration of the Event Log database events to History Node events migration process. This section is optional.
- solutionId—The runtime id of the solution for which events will be migrated. Solution with this id must be configured in Configuration Server
- fetchSize—Determines how many interactions' events will be queried at once from the Event Log database. Please note it is number of interactions, not number of events. Default value: 10.
- interaction-server—Points to the Interaction Server database.
- eventlog—Points to the Event Log database.
Logging configuration is retrieved from Configuration Server in the following way:
- When History Node starts initial logging configuration is read from .yaml configuration file.
- History Node retrieves configuration from Configuration Server.
- If logging configuration is missing in Configuration Server, initial configuration is used (the one from .yaml file).
- If logging configuration is incorrect, History Node will exit with error.
- If logging configuration is correct, History Node will reconfigure itself to log according to configuration placed in Configuration Server.
The History Node Cluster application itself doesn't need any configuration. History Node applications included in the cluster have following configuration restrictions:
- All of the History Node applications included in the cluster should be connected to the same database.
- If automatic database schema migration is enabled (migrate-schema option set to true), it mustn't be enabled in more than one History Node application.
- If removal of the history events is enabled (stop-processing option set to remove), it should be enabled only in one History Node application.
Configuring History Node to Process a Single Event Type
History Node can provide data for iWD Manager or iWD Data Mart or both. By default both event types are processed; however you can change this with following options:
- process-gtl—setting this option to false will disable processing of the events for the iWD Manager.
- process-dm—setting this option to false will disable processing of the events for the iWD Data Mart.
1. iWD Manager will not connect to a History Node application unless the process-gtl option is explicitly set to true.
Configuring History Node to Process UTF-8
If you plan to use UTF-8 encoded characters in the task updates (for example, in task attributes values), you must enable the UTF-8 encoding support.
To do this for Windows, add -Dfile.encoding=utf-8 to JavaServerStarter.ini under the [JavaArgs] section.
To do this for UNIX, add -Dfile.encoding=utf-8 to JAVA_OPTS in iwd_history.sh.
Then restart History Node.