Skip to main content
This guide shows the steps to set up a content service. The recommended way to configure the content service is to use the Atoti Server Starter. Once it has been added to your project, a content service will automatically be created. The content service can then be configured by setting the relevant Spring properties. First, set the content service type to use as shown below. By default, an in-memory content service is used.
The following sections show additional configuration properties for each applicable type of content service.

Hibernate content service

To use a content service backed by a database:
  1. Make sure your database’s JDBC driver is available at runtime. This example uses an H2 database, so the following dependency needs to be added:
  2. Set atoti.server.content-service.enabled-type to hibernate.
  3. Use a configuration such as:
To use a different database, update the url and driver properties.

Content service audit and high availability

A content service backed by a database can enable audit or high availability. To enable audit or high availability:
  1. Set atoti.server.content-service.enabled-type to hibernate or database.
  2. Set atoti.server.content-service.persistence.audit.enabled or atoti.server.content-service.persistence.high-availability.enabled to true.
Audit and high availability cannot both be enabled. Startup fails with an explicit error message if both are set to true.

Audit

The atoti.server.content-service.persistence.audit.enabled property enables audit at the database level. It traces every change made to the content. This lets users inspect and restore previous versions of files, for example dashboards. This property is optional and defaults to false.

High availability

The atoti.server.content-service.persistence.high-availability.enabled property enables database-level locks. These locks prevent concurrency issues when multiple content service instances are backed by the same database. This property is optional and defaults to false.
The atoti.server.content-service.persistence.high-availability.polling-interval property controls how often changes from other content service instances are polled from the database. This property is optional and defaults to 5 minutes. It is only valid when high availability is enabled.

Remote content service

To use a remote content service:
  1. Set atoti.server.content-service.enabled-type to remote.
  2. Use a configuration such as:

Content service prefix

The atoti.server.content-service.prefix property wraps the content service so all its entries are stored under a directory prefix. This applies to every content service type: in-memory, remote, Hibernate, and database. A typical use case is several Atoti applications sharing a single content service, each using its own prefix. No prefix is applied when the property is unset, blank, or set to /. The property only takes effect on the auto-configured content service with pivot integration enabled, which is the default. When the pivot integration is disabled, the standalone content service currently ignores this property.
See Sharing one content service between multiple Atoti instances for more information.

Option 2: manual bean declaration

An alternative to using the Atoti Server Starter is for your Spring configuration to define the appropriate beans.

1. Create an IContentService

The first bean required is of type IContentService. IContentService.builder() can be used to create instances of IContentService. The following sections give examples for each content service type.

In-memory content service

Hibernate content service

To use database-level locks instead of Java locks, use the builder’s databaseLocks method:
Audit can be enabled with the builder’s audit method.

Remote content service

2. Create an IActivePivotContentService

The second bean required is of type IActivePivotContentService and wraps the first bean. ActivePivotContentServiceBuilder can be used to create instances of IActivePivotContentService. One way to create this bean is shown in the example below.
In some cases such as when a single content service is used by multiple Atoti Servers, it may be useful to have each server use a different prefix. One way to define such a prefix is shown below. For more information, see here