Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt

Use this file to discover all available pages before exploring further.

The content service organizes metadata using a file-system-like structure, with stores as folders and keys as file names. Each file and directory has role-based permissions that control read and write access. This page is intended for readers who want to understand how Atoti persists and shares metadata.
  • Atoti Server
    • User content data (KPI, calculated members and named sets)
    • Branch permissions
    • Content service API version
    • User locale
  • Atoti Admin UI
    • User settings
  • Atoti UI
    • User permissions
    • User settings
    • User content data (dashboards, filters…)

​
How does the content server work?

The content server hosts the content service and exposes it through a REST API. Atoti Server and other components use this API to read and write metadata remotely. The content server organizes data using a file system like structure. Stores are represented as folders. Keys are represented as file names, and values as file content. Each file and directory has permissions that control read and write access by role. Two deployment options are available.
  • Embedded content server Atoti Server acts as the content server. This option requires no additional server and is the default behavior. It is suitable for development and simpler deployments.
  • Standalone content server The content server runs in a separate process.
In both deployments, you can choose from several storage implementations.
  • An in-memory implementation that does not persist data across restarts.
  • A local H2 database implementation.
  • An external database implementation persists data in a relational database and supports audit trail capabilities. The content server connects to this database via JDBC using the Hibernate framework.
Several Atoti applications can share one content server, in this case prefixes are used to separate their metadata.

​
What is the relationship to other Atoti products?

The content server is required for all Atoti deployments. It is used by applications built with the Atoti Java SDK or the Atoti Python SDK, and by all Atoti solutions and workflow products. Find out how to set up the content server with: Atoti Java SDK. Atoti Python SDK. Atoti UI depends on the content server to persist dashboards, bookmarks, and user settings. The content server URL must be configured together with the Atoti Server URL when setting up Atoti UI. Atoti Admin UI provides a browser-based interface for the content service. It allows administrators to browse and manage stored content, and to initialize the content service for a new Atoti UI deployment.