CRMS at start-up

What this is about

Embedded, CRMS has no cold start of its own. It comes up with the start of the CDMS application, in the same process and in the same order as CDMS and CIAS. As a service of its own it has its own start, which looks the same, only without the CDMS models next to it.

How CDMS and CIAS start as a whole is under Cold start of an installation. This page shows what CRMS adds to it.

The timeline

flowchart LR
    A["1 Placement<br/>property against classpath"] --> B["2 Context<br/>mandatory settings, keys, bucket"]
    B --> C["3 Tables<br/>system and tenant DB"]
    C --> D["4 Templates<br/>seed shipped ones"]
    D --> E["5 Timers<br/>anchoring, retention"]
    E --> F(["ready for the first report"])
    classDef stufe fill:#ffc107,stroke:#b38600,color:#1f1a00
    classDef ziel fill:#4d7c0f,stroke:#4d7c0f,color:#fff
    class A,B,C,D,E stufe
    class F ziel

Stage 3 is not a fixed point in time. The tables of a database come about when it is needed for the first time, as with CDMS. For the system database that is at the latest when the templates are seeded.

The five stages

Stage 2: what fails the start

The list of all variables and when each is mandatory is under Environment variables. The timestamping key is explained in Timestamps and anchors.

Stage 3: where the CRMS tables land

CRMS has no database path of its own. It uses the shared CodamAI persistence layer, the same one as CDMS, and registers its entities there twice: once for the system database, once for every tenant database. So every database gets the same crms_… tables. Which row goes where is decided by whom it belongs to.

In SINGLE that is one database. The files of the final documents are not in the database but in the S3 bucket.

Unlike CIAS, there is no migration run of its own for this. The tables come about the same way as those of the CDMS models, on the first access to the database in question. So after an update, a tenant database too is raised only when this tenant works or a timer visits it. Details under The database and Databases and schemas.

Stage 4: seeding shipped templates

CRMS does not read a template folder by itself. If an application ships templates in its build, the application seeds them. The hub backend does this for its project documents as soon as it reports itself ready:

If seeding fails, that is in the log, and the start goes on. Everything else in the application works without the templates. A report that needs them answers with template-not-found until the next successful seeding. The whole path is shown in Templates shipped with a build.

Stage 5: the first anchoring pass

Anchoring means: CRMS has the latest state of every journal confirmed with a timestamp. That way nothing can be rewritten unnoticed later.

The first pass begins one minute after the start, then every CODAMAI_CRMS_ANCHOR_INTERVAL (hourly). The retention pass, which removes expired documents, follows the same pattern with an interval of 24 hours. Both are on as soon as CRMS is embedded. With CIAS it is the other way round: its timers are off until somebody switches them on. The reason is that anchoring and retention are obligations, not maintenance.

With several instances of the same application, you leave the timers on in exactly one (CODAMAI_CRMS_SCHEDULING_ENABLED). How an anchor is built is under Timestamps and anchors.

CRMS registers its roles

In stage 4 of the cold start, CIAS reads the declarations of the modules, that is, the lists of their roles and attributes, and creates roles in Keycloak from them. An embedded CRMS is in this list as module crms, next to cias and cdms. Its declaration is the bean crmsIdentityRegistry, and the project frame lists it.

It follows that:

• What is not used is not added. A scope the installation does not admit and documents it does not store register no role. The hub admits system templates only and stores no documents, so its list is empty.
• The reconciliation creates the roles as client roles on the application’s client, like CDMS’s. You grant them like any other role.
• A new name replaces the old one. If the installation renames a role, CRMS registers the new name. The reconciliation retires the old one instead of deleting it. See Modules register roles and attributes.
• CRMS never registers platform roles. System templates are written by the platform administrators that CIAS names for the installation. See The platform’s realm roles.
• A CRMS service of its own registers nothing. Its roles belong to the client of the CRMS service. You create them there yourself.

Where you set the role names is under The roles.

The variants

Watch out

Next

• Cold start of an installation: the start of CDMS and CIAS
• Databases and schemas and Modules register roles and attributes
• CRMS in the modes of operation
• Environment variables and The database
• Templates shipped with a build and Timestamps and anchors