What is the Nodinite Configuration Database?
The Nodinite Configuration Database is the secure, high-performance backbone of your integration environment. Hosted in your SQL Server instance, it provides robust configuration, auditing, and management for all Nodinite Core Services.
- ✅ Centralize and secure all configuration and System Parameters
- ✅ Ensure long-term performance and reliability, even as data grows
- ✅ Enable robust auditing and compliance with full change tracking
- ✅ Simplify management for system integration experts and IT teams
There is exactly one Configuration Database per Nodinite environment. The installation creates it with a name based on the Environment you register in the Nodinite Portal, for example Nodinite_Prod_Config or Nodinite_Test_Config. Databases upgraded from Nodinite v6 keep their original names (NodiniteConfig_Prod).
Nodinite is engineered to keep your environments running smoothly, even as your data grows. The Configuration Database efficiently stores statistics and configuration data indefinitely, ensuring long-term performance and reliability.
Understanding the Configuration Database
Multiple components interact with and depend on the Configuration Database. Each component can be configured with least-privilege access, enhancing security while introducing some additional administrative complexity. The Core Services Overview table provides links to all required SQL, Windows, and firewall settings. The 'Prerequisites' page offers further details specific to the Configuration Database.
Diagram: Nodinite Web Applications and Services interacting with the Configuration Database.
Components That Use the Configuration Database
| Component | How it uses the Configuration Database |
|---|---|
| Web API | Reads and writes all configuration on behalf of the Web Client and API clients; every change is Log Audited |
| Log API | Connects to it when it accepts Log Events from Log Agents and custom code |
| Logging Service | Reads System Parameters and the list of Log Databases; creates new Log Databases and processes logged data |
| Monitoring Service | Reads the monitored resources, Monitor Views, and System Parameters it needs to evaluate and report monitoring state |
What Is Stored in the Configuration Database?
The Configuration Database contains many stored procedures, table types, and functions, and stores all Nodinite configuration in dedicated tables, including:
- The Repository Model, Log Views, Monitor Views, Roles, and their related entities
- The System Parameters (see below)
- The list of Log Databases and their status
- The Log Audits of every change made through the Web Client or Web API
All queries against Log Databases and BizTalk databases are executed as potentially remote queries using linked servers. Ensure the Linked Server is properly configured—see Prerequisites for more information.
Where System Parameter Values Are Stored
The Configuration Database is where Nodinite stores the values of all System Parameters: the SystemParameters table holds one row per key for the environment.
- Change values in the Web Client or through the Web API as described in Manage System Parameters, never directly in SQL Server. That way the Administrator role is checked, JSON values can be validated, and the change is Log Audited.
- The Logging Service, Monitoring Service, Web Client, Web API, and Log API read the values from this table. Each process caches a value for about 15 seconds, so no restart is needed after a change.
- The System Parameters overview lists every key, grouped by purpose, with a link to its own page.
Keep Users and SQL DBAs Away
Keep Users and SQL DBAs away from Nodinite databases!
Nodinite is always aware—while messages and context properties are encrypted, you should minimize attack vectors and keep configuration data secure. All operations should be performed via the Web Client or Web API to ensure every change is Log Audited.
How do you know who accessed sensitive information? Nodinite helps you stay aware and compliant.
Single Server Example
The Nodinite Configuration Database typically resides alongside the current online Log Database on the same SQL Server Instance.
Diagram: Nodinite Configuration Database and Log Databases on the same SQL Server Instance.
Important
A Linked Server must be configured for access to all Nodinite Log Databases. For Microsoft BizTalk Server, a Linked Server is also required for BizTalkDTADb and BizTalkMGMTDb.
Historical Databases Stored on SQL Hotel
With Nodinite, you never have to delete a single transaction! Log as much data as you need, for as long as you need. When the online Log Database grows too large or too old (see the 'SizeToSplitDatabaseOn' and 'DaysToSplitDatabaseOn' System Parameters), a SQL DBA can move historical Log Databases to another SQL Instance as needed. Disk volume is the primary limiting factor—both for performance and for managing large data volumes.
Diagram: Configuration Database with Online and Historical Log Databases across SQL Server instances.
Installation and Updates
The Configuration Database ships with the Core Services and is never installed on its own:
- The SQL Server type (standalone, Always On Availability Group, or Azure SQL Managed Instance) and the connection string are set in the Nodinite Portal, Step 3: Infrastructure, together with the SqlPackage.exe path used to deploy the database schema.
- The generated CLI package creates or updates the database when you run it (Step 7). Before it applies schema changes, the CLI asks you to confirm a verified backup.
See Install Configuration Database, Update Configuration Database, and Uninstall Configuration Database for the details.
Frequently Asked Questions
Find solutions to common problems and explore the Nodinite Configuration Database FAQ in the Troubleshooting user guide.