Service Storage

Require a Client Hosted deployment.

This page control the persistence for the Digital Automation Suite long-running services.

This storage contains the instance data and triggers. It also contains the data stores data if subscribed.

Storage types

By default, service storage is achieved through the File System by using a mix of folders and file serialization.

For improved scalability, we also offer a MongoDB storage.

For most use cases, the file system storage offers more than enough performance but in the following cases, MongoDB should be considered:

  • Scaling the number of nodes running a workflow or case. When more than one digital distributed container runs the same workflow/case that is long-running (either throughput scalability or geographical scalability), it is not always possible to mount the same external storage to all container instances (pods).

  • Guaranteeing that only one node trigger on a given timer.

  • Using large data stores, the performance of MongoDB will be significantly faster for most lookup operations.

  • Data storage scalability (throughput or geographical) can be achieved using a MongoDB cluster.

Trisotech does not support your client hosted deployment of MongoDB, you are responsible to contract support for MongoDB.

Migrate to MongoDB

The migration of existing services to MongoDB is not reversible and a migration from MongoDB to the file system does not currently exist.

A wizard guide you through the transition.

  1. Establish connection with MongoDB server

  2. Select environments and services to be migrated

  3. Perform migration of selected services

  4. Verify migration by examining services instances via Cloud Execution

  5. Accept (will remove file system data and use MongoDB server as data store) or Reject migration (will clean up MongoDB and use file system as before)

Until the very last step of the wizard, rejecting the migration will not affect any instance currently running.

It is recommended to do the migration in a scheduled downtime and cut external traffic ingress that could start new long-running instances. Failing to do so will cause instance data loss in the transition process.

The migration of service instances to MongoDB is not required. It is often a good idea to start fresh.