System Database
Overview
The system database is the database used by the ADITO application itself to store its own configuration and runtime data, such as alias configurations, permissions, dashboards, or audit records. It is distinct from the data database, which holds the business data of an ADITO-based solution.
System Tables
Tables whose name starts with ASYS_ are internal system tables. Most reside in the system database, but certain ASYS_ tables also exist in the data database. Regardless of which database they reside in, they store data that the platform itself needs to function and are not part of the public data model.
Do not read or write ASYS_ tables directly. Their format and content can change at any time, and direct access can break with any future platform update.
Access the data these tables hold only through the corresponding JDito API documentation methods. If no such method exists for a given ASYS_ table, direct access by customizing code is not supported.
General
Core & Configuration
| Table | Description | Accessed via |
|---|---|---|
ASYS_SYSTEM | Storage for all data models managed internally by ADITO, including Contexts and other definitions created in the Designer. | project |
ASYS_ALIASCONFIG | Stores the alias configurations of the definitions used by a project, for example database, Exchange, or other connection types. | |
ASYS_SEQUENCES | Manages the automatic assignment of unique IDs to records. Whenever a new record is created, this table ensures in the background that it receives a unique, not-yet-used number. | db |
ASYS_BINARIES | Storage location for file attachments (documents, images, etc.) attached to records, regardless of which table the record resides in. | db |
ASYS_VERSIONHISTORY | Keeps track of which version each system table is at, used to detect whether a system table update is required. |
Users & Permissions
| Table | Description | Accessed via |
|---|---|---|
ASYS_USERS | ADITO's central user management. Stores user accounts and their properties (for example assigned roles) used to log in. | tools |
ASYS_USERTOKEN | Stores login tokens, for example for a "stay logged in" function, so users don't have to log in again on every visit. | tools |
ASYS_ROLES | Manages the roles defined in the system, through which permissions are assigned to users. | tools |
ASYS_ROLES_CHILDREN | Maps hierarchies between roles, so that one role can inherit or include other roles. | tools |
ASYS_PERMISSION | Part of permission management. Stores additional conditions, for example restrictions, under which a permission applies. | tools |
ASYS_PERMISSIONACTION | Part of permission management. Defines which concrete actions, for example read or write, a permission allows. | tools |
ASYS_PERMISSIONSET | Core of permission management. Links roles to entities and fields with the respective access type, defining who may access what and how. | tools |
Dashboard & Notifications
| Table | Description | Accessed via |
|---|---|---|
ASYS_DASHLETS | Stores which dashboard widgets (dashlets) a user has placed on their dashboard, including position and size. | |
ASYS_DASHLETCONFIGURATIONS | Contains the overview of all available dashlet types a user can choose from to build their dashboard. | |
ASYS_NOTIFICATIONS | Manages which notification has already been seen, read, or archived by which user. | notification |
ASYS_NOTIFICATIONCONTENTS | Contains the actual content (text, icon, link) of notifications sent to one or more users. | notification |
Processes & Scheduling
| Table | Description | Accessed via |
|---|---|---|
ASYS_TIMERS | Manages time-controlled, automatically running processes (for example "run this process every night at 2 a.m."). | process |
ASYS_TIMERS_SERVERRUNS | Records, for each schedule, which server last executed it. Relevant when multiple servers operate together, so a schedule doesn't run more than once at the same time. | process |
ASYS_PROCESSHISTORY | Log of all executed processes, started manually or by schedule, including status (successful or failed) and timestamp. Used for traceability and monitoring of process runs. | process |
Audit
| Table | Description | Accessed via |
|---|---|---|
ASYS_AUDIT | Logs changes to monitored tables: who changed which record, when, and how. Used for tracking data changes. |
Tags & Favorites
| Table | Description | Accessed via |
|---|---|---|
ASYS_RECORDGROUP | Manages favorite and tag groups that users can use to categorize records. | tag |
ASYS_RECORD | Links specific records to the favorite and tag groups from ASYS_RECORDGROUP. | tag |
Synchronization
| Table | Description | Accessed via |
|---|---|---|
ASYS_SYNCSLAVES | List of mobile or offline-capable devices and clients that synchronize with the system, including when they last synchronized. |
Mail
| Table | Description | Accessed via |
|---|---|---|
ASYS_MAILREPOSIT | ADITO's internal mailbox. Stores received and sent emails when ADITO's own mail storage is used. | mail |
ASYS_MAILREPOSIT_HASH | Prevents the same email from being accidentally stored twice during mail import. | mail |
Calendar
| Table | Description | Accessed via |
|---|---|---|
ASYS_CALENDARBACKEND | Stores calendar entries (appointments, tasks) directly in the system database when ADITO's own calendar backend is used. | calendars, neon |
ASYS_CALENDARLINK | Links calendar entries to other records in the system, for example an appointment to a related business transaction. | calendars, neon |
ASYS_CALENDARSYNC | Records which internal calendar entry corresponds to which external calendar entry, so that synchronization with external calendar systems (for example Exchange) works correctly. | |
ASYS_UIDRESOLVER | Ensures that calendar entries remain uniquely identifiable across different systems, preventing duplicate or colliding IDs. | calendars, neon |
Farm
| Table | Description | Accessed via |
|---|---|---|
ASYS_FARM | Overview of the servers in an ADITO server cluster (farm), including current load, used to distribute new users to the least loaded server. | |
ASYS_FARM_CLIENT | Shows which users and clients are currently connected to which server in the server cluster. |
Exceptions
As an exception to the rule above, only special Contexts that ADITO maintains itself access these tables directly. ADITO adjusts these Contexts whenever the underlying table structure changes.