Data Stores¶
Use Data Stores in Host Administration to define shared relational data stores that can be accessed across multiple domains.
This page is mainly used when a solution must keep using each domain's own default store for normal operations, while also exposing one or more shared stores for cross-domain or centralized data scenarios.
In practice, this shared-store model is especially useful when developing cross-tenant processes that need controlled access to relational data outside the current tenant's default store.
Default Domain Store Behavior¶
Emakin automatically creates a relational data store for each domain (tenant).
The automatically created store uses the same name as the domain. In normal database operations, if no target store is specified, Emakin uses the current domain's own data store.
This means the default behavior is tenant-scoped:
- each domain works with its own store
- database scripts do not need to specify a store for normal in-domain access
- omitting the store parameter keeps the query in the current domain's database
For example, the following call uses the current domain's default data store:
1 | |
The same applies when an empty store value is passed explicitly:
1 | |
Shared Data Stores¶
Host Administration can also define shared data stores that are not tied to a single tenant's default store.
These shared stores are intended for cases where developers need to query or maintain relational data outside the current domain's own store. A common use case is cross-tenant process development, where process logic must read or write shared relational data across tenant boundaries in a controlled way.
After a shared store is created, scripts can access it by passing the store name to the $Database object.
Creating Shared Stores in Host Administration¶
The Data Stores page allows administrators to register a shared store from Host Administration.
The shared-store definition includes:
- a shared data store name
- a sample process-definition XML
The process-definition XML is used to create the required relational structure in the selected shared store. In practice, this allows administrators to bootstrap schemas and tables for the shared database from a process definition.
After the shared store is created, developers can target it explicitly from scripts through $Database.
Switching to Another Store in Scripts¶
Developers can either use the current domain's default store or explicitly switch to another store.
Default-store usage:
1 | |
Explicit-store usage:
1 | |
Example:
1 | |
In this example, the query does not run in the current domain's default store. It runs in the shared store named PS_Reporting.
Naming and Safety Rules¶
Named shared stores must start with the PS_ prefix.
This prefix acts as a safety boundary for intentional shared-store access. It helps distinguish explicitly shared stores from ordinary domain stores and reduces the risk of accidentally switching into the wrong database by name.
Use the PS_ prefix consistently for all host-level shared store definitions and in all script examples that target a named shared store.
GUID-Based Access and Security Implications¶
The store parameter is not limited to shared-store names. It can also receive a data store GUID.
When a GUID is provided, the named-store validation is not applied. In other words, the PS_ prefix rule is checked for named access, but it is not checked for direct GUID access.
This has an important security implication: GUID-based access can directly target any data store, including stores that belong to other tenants.
When such access is used, queries can run against any schema in that target store, including tenant-internal schemas such as HR.
Treat GUID-based store access as an advanced capability and use it only when this behavior is explicitly intended. Unlike named shared-store access, GUID-based access is not constrained by the PS_ naming convention.