What happens when you start the server depends on whether you start the server for the first time after installation or if you start it later again

First Content Server start

Before you start the Content Server for the first time, make sure that the content type definition file (<xyz>-doctypes.xml) can be found at the location configured with the parameter cap.server.documentTypes. Normally this file is placed in the directory config/contentserver/doctypes. You may point this parameter to multiple comma separated paths, which may contain Ant-style wildcards. If you want to use separate table spaces for blob data, you have to adapt the <DBname>.properties file of your database before the first start of the Content Server. See Section 3.2.1, “Specifying Tablespaces for the Content Server” for details.

Start Content Server Spring Boot application.

When executing for the first time, this creates the data schema from the content type definition files. Depending on the file number and sizes this can take some time. Look into the log file of the Content Server and the catalina.out to see system and error messages.

Make sure that the Master Live Server is online before you start any Replication Live Servers. After the first start of a Replication Live Server, the server will remain in the runlevel Administration until the content of the Master Live Server has been replicated with the exception a few very recent changes.

Start the Workflow Server Spring Boot application.

Now you need to choose and upload predefined workflows to the CoreMedia Workflow Server that you want to use. You can omit this step if you want to use only your own workflows with your own workflow groups. The valid predefined workflow names are defined in the Workflow Manual. To upload one of these predefined workflows with the upload utility, execute cm upload -u admin -p <password> -n <workflow-name> and replace <password> with the password of the admin user (ID=0) and <workflow-name> with one of the names listed in Workflow Manual, for example, three-step-publication.xml.

You can continue uploading further custom workflows in the same way as described for the Global Search and Replace workflow in the previous step. The upload utility is described in the Workflow Manual.

After successful initialization, the password of the administrator (admin) and other system users (watchdog, importer, etc.) should be changed in order to guarantee the security of the system. Go to the User Management window in the editor for this purpose (see Section 3.15, “User Administration”). Make sure to update all relevant configuration files.

Later Content Server starts

Later starts of the Content Server will be faster.

A Replication Live Server will go online only after it has contacted the Master Live Server and has replicated all but a few very recent changes. This means that the server will not go online automatically if the replicator is disabled or if the Master Live Server is not running.

By setting replicator.force-online-switch=true you can make sure that the Replication Live Server goes online immediately, regardless of the replication state and the Master Live Server availability. This can help to ensure that a failed Master Live Server cannot bring down the entire delivery environment, if you do not have any monitoring solution or watchdogs in place. It might, however, cause different CAEs to deliver different states of the content.

Wait until the server is up and start the Workflow Server.

For description of the options see Section 2.4, “Server Run Levels”.

The server can be stopped with

cm runlevel -r offline [-g <grace period>] or with the servlet container's methods.

Running clients are informed in regular intervals about the server shutdown.

To check whether the Content Server is running, try to reach the server, for example with Telnet:

telnet <serverhost> <server.http.port>

If the server is running, a connection can be established, otherwise it fails.

Start both servers before all other CoreMedia components which must communicate with them. A server restart is necessary when the database connected to the server is restarted.