. . .

Configuration Files

ApiOmat stores installation-wide configuration in some configuration files residing in the configuration directory /etc/apiomat (Linux) or C:\Users\YourUser\AppData\Local\ApiOmat\config (Windows). The content of these files are explained on this page.

hazelcast.xml

Contains the configuration of all application server nodes to let them communicate together during deploys. To apply changed values, Tomcat has to be restarted. More information can be found here.

mongodb.conf

Contains configuration of MongoDB. This is only needed if the database is installed on the very same host as the application server. To apply changed values, MongoDD has to be restarted.

Crucial settings are:

  • dbpath = directory where data is stored

  • logpath = directory where logifle is stored

  • port = port of mongodb server

  • noprealloc = set to true on test installations to save disc space

  • nojournal = set to true on test installations to save disc space

Detailled information can be found here.

log4j.xml

ApiOmat uses Log4j2 as logging engine. Using the log4j.xml file, one can define the log level for separate classes or packages. Furthermore, logging can be redirected to other files, or emails. Changes are automatically applied after 30 seconds (see the monitorInterval attribute in the xml file).

The available loglevels are (beginning with the highest verbosity):

  • TRACE

  • DEBUG

  • INFO

  • WARN

  • ERROR

  • FATAL

Hence in order to enable all logs to be printed out from ApiOmat, simply set the rule for package com.apiomat to TRACE:

<Logger name="com.apiomat" level="trace" additivity="false">
<AppenderRef ref="CONSOLE" />
</Logger>

Backend specific logs to file

To create one logfile for each backend, add the APP_FILE appender:

<Logger name="com.apiomat" level="trace" additivity="false">
<AppenderRef ref="CONSOLE" />
<AppenderRef ref="APP_FILE" />
</Logger>

All backend specific logs will then be written to /tmp/applog-<APPNAME>.log; the destination can be changed in the <Routing> section of the log4j.xml file.

Keep in Mind to focus the Log4j2 Logger inheritance

E.g. the parent logger of 'com.apiomat.backend.persistence.LogEntry' is 'com.apiomat'. If the additivity of the child logger is set to false then the log messages that are caught by LogEntry-Logger are not transferred to the parent logger. That means that those log messages will not run through the parent logger configuration.

For further information visit the official documentation of log4j2 or read this compact article about Log4j Additivity.

Logs to logging console

It is also possible for a customer (a developer with credentials for the dashboard) to show all messages regarding the current backend and the modules she owns in the Dashboard's logging console. The log4j.xml should contain the packages attribute in its configuration and an additional AOMMongoAppender:

log4j.xml
<?xml version="1.0" encoding="UTF-8"?>
<Configuration monitorInterval="30" packages="com.apiomat.backend.persistence">
 
<Appenders>
...
<AOMMongoAppender name="AOM">
<ThresholdFilter level="ERROR" onMatch="ACCEPT" onMismatch="DENY" />
</AOMMongoAppender>
...

This appender writes each log message to the database in separate collections (one collection for each app or module). The messages can then be fetched via REST endpoint, which makes them accessible from the Dashboard even in a clustered environment. In contrast, writing to logfiles will result in separate log files on every cluster node.

To enable the new appender, you have to add a ref to a logger. As a default, the com.apiomat logger can be extended like this:

log4j.xml
...
<Logger name="com.apiomat" level="trace" additivity="false">
<AppenderRef ref="CONSOLE" />
<AppenderRef ref="AOM" />
</Logger>
...

Of course, the <AppenderRef ref="AOM"/> can be used in all other loggers, too.

Now, every ERROR or FATAL log message will be shown in the logging console. To change the log level for AOMMongoAppender, you can set the ThresholdFilter level to an other log level. To disable the threshold and only use the level set for the logger(s), just remove the whole ThresholdFilter tag.

Performance

Please keep in mind that writing logs to database will impact performance. Hence, ERROR is the default level to limit the writes to database. A change to INFO or even TRACE will result in much more database write operations and serious performance impacts.

Request logs

To enable printing the request information, simply set the jersey rule to INFO (default setting):

<logger name="com.sun.jersey" level="info" additivity="false">
<AppenderRef ref="CONSOLE" />
</logger>

Logs from native modules are written in the apps database and are accessible via the logging console in dashboard and via REST. To show these messages in the tomcat logs, at least the com.apiomat.backend.persistence.LogEntry entry in the log4j.xml has to be set to TRACE.

apiomat.yaml

This configuration file contains all basic information for YAMBAS installation. To apply changed values, YAMBAS has to be restarted.

required settings

  • common:

    • isEnterpriseInstallation:true - enables use of NativeModules, disabled app payment and restricts customer creation.

    • isWhitelabelInstallation:true - needs isEnterpriseInstallation, enables customer creation by everyone and restricts permissions for NativeModules.

    • defaultOrganizationPassword - password for default organization login (Before updating this field, the organization should be updated first via apidocs. Look at information field below)

    • hosts:

      • admin: base URL of the installation, like https://mysystem.com

      • live/staging/test: - base URL definable separately for each system

  • yambas:

Update Default Organization

  • Go to the apidocs and search "POST /organizations/{organizationName}/password"

  • fill all fields as desired

  • above, the superadmin credentials must be set

  • Now you can update the configuration files.

Additional Settings

All additional settings are mentioned in the apiomat.yaml.example file.

MongoDB Settings

passwordpolicy.json

Contains the configuration of the system wide password policies. It is used to deny invalid passwords on generation. To apply changed values, Tomcat has to be restarted. More information can be found within the guide Password Policy.

* link only available in Enterprise Documentation