Seitenvergleich

In your UM Cloud installation you cannot just SSH into your machine and edit one of the familiar configuration files (cmsbs.properties, additional.attributes etc.) to update certain global settings, modify the data model or add custom CSE plugins.

This section shows how these tasks can be carried out for a Cloud UM.

Create a custom UM Plugin

In order to have a similar degree of control over your Cloud UM as you are used to from an on-premise installation, you need to create a custom UM Plugin. This Plugin may contain your custom Core Scripting Engine code – if any – but also attribute configuration and other global settings that you would otherwise put into your cmsbs-conf/cmsbs.properties file.

You can follow along Providing a custom Plugin for the UM Cloud to create an empty Plugin, test it locally and have it included in your UM Cloud instance.

Manipulating the data model (aka editing “additional.attributes”)

In a UM Cloud environment it is generally not a good idea to overwrite the global cmsbs-conf/additional.attributes file as it is provided by Pinuts and might (need to) be updated in the course of a UM update. Instead, you can create incremental changes by putting cmsbs-conf/conf.d/*.attributes files into your Plugin.

The following example shows how to setup a TABLE attribute and add it to the std_personal attribute group.

additional.attributes[] = favorite_fruits
grp.std_personal.members[] = favorite_fruits

favorite_fruits.type = TABLE
favorite_fruits.members[] = fruit

favorite_fruits->fruit.type = STRING

Please remember that adding new primary attributes or adding columns to an already existing TABLE attribute require providing Automating Database Schema Updates.

Setting global configuration options (aka editing “cmsbs.properties”)

Likewise, you must not override the global cmsbs-conf/cmsbs.properties file in a UM Cloud environment. But similarly you can make incremental changes by putting cmsbs-conf/conf.d/*.properties files into your Plugin.

You can also put your properties files into well-known directories to have them take effect only in a specific UM environment (i.e. test, staging or prod):

• env/test/cmsbs-conf/conf.d/

• env/staging/cmsbs-conf/conf.d/

• env/prod/cmsbs-conf/conf.d/

Adding and overwriting configuration files

When a Cloud UM is deployed, configuration files will be copied together in a certain order, with files of the same name being overwritten.

1. The whole cmsbs-conf/ directory is pre-populated by the familiar UM installer that is run unattendedly.

2. Certain files are added to or overwritten in cmsbs-conf/ to adapt the UM to the Cloud environment in general and to prepare it for the specific customer.

3. Your custom UM Plugins will be deployed last so they could – in principle – override each and every file that pre-exists:

   1. First, cmsbs-conf is copied on top of the existing directory,

   2. and second, env/<environment>/cmsbs-conf/ is in turn copied on top.

Loading order of configuration files

When the UM starts, configuration files will be loaded and evaluated in the following order:

1. cmsbs-conf/cmsbs.properties

2. cmsbs-conf/conf.d/*.properties (in alphanumerical order of the respective file names)

The same applies to attribute model configuration files:

1. cmsbs-conf/additional.attributes

2. cmsbs-conf/conf.d/*.attributes (in alphanumerical order of the respective file names)

All configuration files in cmsbs-conf/conf.d/ that are provided by Pinuts share the same file name prefix _pi. and thus will be evaluated first.

Implementing custom REST endpoints, Jobs, Callbacks etc.

Besides adding configuration files you can also add everything that can be implemented using UM’s Core Scripting Engine like…

• REST endpoints

• Cronjobs

• Callbacks and Hooks

• Backoffice Wizards

See Tutorials for examples of frequently used programming patterns.