1. General

The appNG Manager is an appNG application to configure and maintain the appNG platform and its installed applications. The manager is a mandatory privileged application of appNG. After installation of appNG, a site manager is available with an installed manager application. By default, the manager is available on localhost at

The application has different pages to configure and monitor the appNG platform:

Page Description

Sites

Manage sites and applications of a site

Applications

Manage applications and templates; edit application resources

Users

Manage users, groups and role assignments

Repositories

Manage application repositories and install applications

Platform

Configure platform properties and manage database connections.

System

Monitor the system-, environment- and cluster status. View logfile and edit log configuration.

2. Sites

An appNG site is a representation of a domain. An appNG installation can have several sites. Each site can have a different template, different configuration of some appNG platform features and a different set of appNG applications. The same appNG application can be installed in multiple sites with a different configuration.

2.1. Site Overview

The main page of the manager application lists all available sites. Among other things it shows if a site is active and running and the time when the site was started. It also provides a list of actions per site.

2.1.1. Reloading a site

In the list of available sites, each site has a list of actions. One of the actions is reload. Click this link to reload a site.

If the site has been running, it is shut down. Afterwards, all site properties and site application properties are newly initialized with the active values from the database. Furthermore, all applications activated for the site, including their resources, are loaded and initialized. If necessary, schema migrations are applied to the application databases.

If a running site is configured to be inactive, reload the site to shut it down. Since it is configured to not be active, it will not be restarted.

2.1.2. Deleting a site

In the list of available sites, each site has a list of actions. One of the actions is delete. Click this link to delete a site. This action has to be confirmed to avoid deletion by mistake.

When a site gets deleted, all information such as site attributes, site properties, application properties and application databases are removed. It is not possible to restore any of the deleted data. If you are not sure whether a site is needed in the future configure it to be inactive.

2.2. Creating a site

A fresh default installation of appNG provides only the initially configured site manager. To create a new site, click on the link create site above or below the list of sites on the main page.

By clicking this link, a new form opens where the attributes of the new site have to be defined:

Attribute Name Description

Name

The name of the site. It must be unique per appNG platform and is used in the appNG url scheme.

Host

In simple setups, this value is identical with the domain. In more complex use scenarios it could be necessary that a site should be available from different domains. In such a case, the webserver of your choice has to map domains to host-values and set the request attribute SERVER_LOCAL_NAME to the host value of the target site.

Domain

The DNS name incl. the protocol (http or https), as it will be used by the client. The value of this field is used to generate absolute URLs, where required.

Description

Some additional information about the site.

active

If a site is active, it is automatically started on appNG start-up.

Create folder for JSP-contents

Instructs appNG to create a folder in the local file system, where static resources and JSP files can be stored and processed.

Template

A site must have a template. On a fresh installation, the appNG default template is installed. Other templates can be installed on the platform. The template of choice can be configured per site.

After the site has been created, a new item is visible in the list of available sites. The site is listed as active if it was created as active site. The site is not running.

To start the created site, it has to be configured as an active site and then it has to be reloaded. If the site is configured to be active, it will also be started automatically during the next platform start-up.

2.3. Editing a site

In the list of available sites, each site has a list of actions. One of the actions is edit. Click this link to open the edit page of that site.

This page is partitioned in sections. The first section is similar to the form to create a site. Besides the site name, all attributes can be changed in that form. The other sections are described further down. Changes will be taken into account after a site reload.

A site reload is always necessary if a site attribute, site property, site application property or an application resource has been changed.

If appNG runs in a cluster setup, the site reload is executed first on the node where the action has been executed. If the site has been successfully reloaded, a cluster event is sent by this node to all the other nodes in the cluster to also reload that site.

In a cluster setup with non-sticky sessions it might happen, that the next request after triggering the site reload will be processed by another node, where the site reload event was not yet received or where the site reload is ongoing.

2.4. Configuring site properties

In addition to the site attributes, there are a lot of site properties. With site properties it is possible to disable, enable and configure site-specific appNG features. To change site properties, go to the edit page of a site. The page is partitioned in sections. The section to maintain the site properties has the name Site properties.

As long as a property value has not been changed for a site, appNG uses the Default-Value. In this case both fields Value and Multilined value are empty.

To update a property, enter a value in either the Value or Multiline value field. Note that it is not possible to save the property if both fields are filled. appNG will use the content of the Value or the Multilined value field, if it is not empty. After updating a property, a site reload is required.

A site property has the following attributes:

Attribute Name Description

Name

The name of the property.

Active Value

As described in Reloading a site, a property update will be only taken into account after a site reload. This attribute shows the value of the property after the next site reload.

Default Value

The default value defined by the platform on site creation.

Multiline Value

A normal value has a limited length of 255 characters. If a bigger value is needed, it must be defined in the Multilined Value field of a property.

Description

A short description of the property

Changed Value

Is shown in the list of properties. Indicates if a value has been changed for that site (yellow) or if it still uses the platform default (green).

If a property was changed and it shall use the default again it is necessary to empty the field value. It is also possible to copy just the default value as value. This will have the same effect, but the property would still be shown as changed value.

A site can be configured using an manageable amount of properties. These can be roughly divided into the following categories:

  • Backend
    Configures the management backend itself

  • Caching
    Configures caching using Ehcache

  • Content
    Properties for configuring content delivery from a site’s repository

  • Indexing/Searching
    Configures Lucene indexing and searching features

  • UI
    Affects the behavior of the management user interface

After changing site properties, you must perform a site reload to apply these changes.

A detailed list of the available properties can be found here:

Name Type Category Description Default

xssExceptions

multilined text

Backend

URL path prefixes where XSS protection is omitted. Contains one prefix per line. Supports blank lines and comments (#).

appendTabId

boolean

UI

If set to true, the name of the currently selected tab is being appended to the URL as a get-parameter. Addresses the issue that IE loses the anchor on a redirect.

false

assetsDir

text

Content

A semicolon-separated list of folder-names (relative to wwwDir) containing static resources such as images or pdfs

/assets

authApplication

text

Backend

The name of the application which is responsible for the authentication

appng-authentication

authLoginPage

text

Backend

The names of the login-pages (comma-separated) within the application defined in authApplication. The number of comma-separated pages must be the same as in authLoginRef, because authLoginRef[n] refers to authLoginPage[n]!

webform

authLoginRef

text

Backend

The action names (comma-separated) for the pages defined in authLoginPage. The number of comma-separated names must be the same as in authLoginPage, because authLoginRef[n] refers to authLoginPage[n]!

webform

authLogoutActionName

text

Backend

The name for the parameter defining the action on the authLogoutPage

action

authLogoutActionValue

text

Backend

The value for the parameter defining the action on the authLogoutPage

logout

authLogoutPage

text

Backend

The name of the logout-page within the application defined in authApplication

webform

authLogoutRef

text

Backend

The reference-path for the logout-action

webform/logout

cacheEnabled

boolean

Caching

Set to true to enable caching for this site.

false

cacheExceptions

multiline text

Caching

URL path prefixes which are never cached. Contains one prefix per line (multiline value).

/manager

cacheStatistics

boolean

Caching

Set to true to enable caching statistics

false

cacheTimeToLive

int

Caching

The default TTL for a cache entry in seconds, if there’s no matching path defined in cacheTimeouts.

1800

cacheTimeouts

multiline text

Caching

The cache timeouts as a multiline property, key=value

cacheTimeoutsAntStyle

boolean

Caching

Use Ant-style path matching for cacheTimeouts?

true

cacheClearOnShutdown

boolean

Caching

Whether or not the Ehcache is cleared on a site shutdown/reload

true

csrfProtectionEnabled

boolean

Backend

Set to true to enable CSRF-protection for this site

false

csrfProtectedMethods

text

Backend

a comma-separated list of HTTP-methods to enable CSRF protection for (see csrfProtectionEnabled)

POST,PUT

csrfProtectedPaths

text

Backend

a comma-separated list of path-prefixes to enable CSRF protection for (see csrfProtectionEnabled)

/manager

DatasourceConfigurer

text

Backend

The fully qualified name of a class implementing org.appng.core.repository.config.DatasourceConfigurer, which is responsible for JDBC connection-pooling. Supported are org.appng.core.repository.config.HikariCPConfigurer and org.appng.core.repository.config.TomcatJdbcConfigurer

org.appng.core.repository.config.HikariCPConfigurer

defaultPage

text

Content

The name of the default-page (without extension) relative to one of the directories defined in documentDir

index

defaultPageSize

int

UI

The default page size (items per page)

25

defaultApplication

text

Backend

The application to be called after a successful login

appng-manager

documentDir

text

Content

A semicolon-separated list of folder-names (relative to wwwDir) containing JSP-files and static resources

/de

encoding

text

Content

The encoding for file-resources

UTF-8

enforcePrimaryDomain

boolean

Backend

Set to true to enforce the protocol used by the site (http or https)

false

errorPage

text

Content

The name of the default error-page (without extension) relative to wwwDir

error

errorPages

text

Content

The name of the error-page per document-directory (see documentDir), multiple entries separated by a pipe (|)

/de=fehler|/en=error

host

text

Backend

The host of the site. For convenience only, do not change!

The host of the site

indexConfig

text

Indexing

For each directory defined in documentDir, there can be defined which locale and which Lucene-analyzer to use for indexing.

/de;de;GermanAnalyzer|/assets;de;GermanAnalyzer

indexDir

text

Indexing

The folder containing the Lucene-Index, relative to wwwDir

/index

indexFileSystemQueueSize

int

Indexing

the queue size used per directory when indexing the file system

2500

indexFileTypes

text

Indexing

A list of comma-separated file-extensions (without leading dot) which are being indexed

jsp,pdf,doc

indexQueueSize

int

Indexing

The queue size used for document indexing

1000

indexTimeout

int

Indexing

The timeout in milliseconds for indexing

5000

ldapDomain

text

Backend

The Netbios Domain name to use, when "SAM" is used as principal scheme

EXAMPLE

ldapGroupBaseDn

text

Backend

The base-DN for LDAP-groups

OU=Groups,DC=example,DC=com

ldapHost

text

Backend

The LDAP host in provider URL format (ldap[s]://<host>:<port>). Note that you might need to add CA certificates to the truststore of the executing JVM if you enable “ldaps”.

ldap:<host>:<port>

ldapIdAttribute

text

Backend

The name of the LDAP-attribute containing the user-id used for authentication

sAMAccountName

ldapPassword

text

Backend

Password of the LDAP service-user

secret

ldapPrincipalScheme

text

Backend

How the LDAP principal is built from a given username when logging in: “DN”, “UPN” or “SAM”. (See LDAP connectivity for details.)

SAM

ldapStartTls

boolean

Backend

Use STARTTLS for the LDAP connection. If you set this to true the value of ldapHost should begin with ldap: (not ldaps:), because STARTTLS and LDAP over SSL (which is used when ldaps: is in place) are mutually exclusive.

false

ldapUser

text

Backend

The name of the LDAP service-user for general LDAP lookups. If the value is a Distinguished Name (e.g. “cn=Service User,dc=mycompany,dc=com”) it will be used directly as LDAP principal. Otherwise the principal will be derived according to the value specified in ldapPrincipalScheme.

serviceUser

ldapUserBaseDn

text

Backend

The base-DN which is used to map a plain username to a Distinguished Name, if "DN" is used as principal scheme (see property ldapPrincipalScheme above).

OU=Users,DC=example,DC=com

locale

text

UI

The default locale for the site. Use one of java.util.Locale.getAvailableLocales()

Locale.getDefault().getLanguage()

mailDisabled

boolean

Backend

Set to true to disable mailing and log the e-mails instead.

true

mailHost

text

Backend

The mail-host to use

localhost

mailPort

int

Backend

The mail-port to use

25

manager-path

text

UI

The path-suffix for the appNG-Webapplication

/manager

name

text

Backend

The name of the site. For convenience only, do not change!

rewriteConfig

text

Content

the location of the rewrite rules for UrlRewriteFilter (http://tuckey.org/urlrewrite), relative to siteRootDir.

/meta/conf/urlrewrite.xml

searchChunkSize

int

Content

The chunksize (items per page) for the search-tag

20

searchMaxHits

int

Content

The maximum number of hits for the search-tag

100

serviceOutputFormat

text

Backend

The output format to be used when actions/datasources are being called through service URLs

html

serviceOutputType

text

Backend

The output type to be used when actions/datasources are being called through service URLs

service

service-path

text

Backend

The path-suffix for the services offered by appNG (such as Webservices, SOAP, Actions, Datasources)

/service

siteRootDir

text

Backend

The absolute path to the site’s root-directory

supportedLanguages

text

Backend

A comma-separated list of the languages supported by the site

en, de

supportReloadFile

boolean

Backend

If true, a site reload is performed when a file named .reload is created in the site’s root directory.

false

tagPrefix

text

Content

The prefix used for the appNG JSP-tags.

appNG

template

text

Backend

The name of the template to use

appng

timeZone

text

UI

The default timezone for the site. Use one of java.util.TimeZone.getAvailableIDs().

TimeZone.getDefault().getID()

wwwDir

text

Content

The name of the folder containing the web-contents, relative to repositoryPath configured at the platform

/www

2.5. Managing applications of a site

2.5.1. Assigning applications to a site

To assign a new application to a site, it first has to be installed on the platform. For installing applications on appNG read [Installing applications] in chapter Repositories in this manual.

To assign an application to a site, go to the edit page of a site. In the section Applications a list of all available applications is shown. For each application not yet assigned to that site an action Activate is available. By clicking this action the application gets activated for that site. On activation, appNG creates a database connection for the application for that site if the application requires a database. AppNG also clones the application properties into site application properties.

Once the activation is finished, the application appears as active in the list, but the column Requires Reload shows, that the application is not started in the respective site. Finally the site has to be reloaded to start the application. This can be done directly by the reload site link on top of the table.

If the application provides a role marked as admin role, it is automatically assigned to the group Administrators in appNG. If not, the administrator of the platform has to care about assigning application roles to appropriate groups. In most cases there will be a kind of admin role which should be assigned to the group Administrators. Other roles maybe have to be assigned to other groups but that depends on the application and the kind of groups created on the platform. Read more about that in the chapter Users and groups in this manual.

After assigning the role, the application will not be visible immediately because appNG processes the permissions for a user only during login. After logging out and in again, the menu entry for that new assigned application should be visible in the menu of the respective site.

2.5.2. Deactivating applications of a site

To unassign an application from a site, go to the edit page of a site. In the section Applications a list of all available applications is shown. For each application assigned to that site an action Deactivate is available. By clicking this action the application is deassigned for that site.

When an application is deassigned, all information such as application properties and the application database are deleted. It is not possible to restore any of the deleted data.

2.5.3. Grant access to other sites

Without any additional configuration, a site cannot access an application in another site. In most cases this is not desired anyway. But if an application provides functionality to be used in different sites it is necessary to grant access to the application for that consuming site.

On the edit page of the site in section Applications a list of all available applications is shown. Applications assigned to that site provide an action named Grant. By clicking this link, a form appears where other sites can be selected to be granted the right to call this application in this site.

2.5.4. Configuring the applications of a site

An appNG application can provide properties to configure the application. Each site has its own application properties. Thus it is possible to run the same application with different configurations in different sites.

The site-specific application properties are similar to the site properties - they have the same attributes. Site-specific application properties also have the concept of a Default-Value. As long as the value is not updated for that site, the property will always have the application’s default value.

In contrast to site properties, the default value of site-specific application properties can be implicitly changed when updating the application.

If a new version of an application changes the default value of a property, this new default value is also applied to the respective site application property in all sites, unless this property is a multilined value.

Multilined values are treated differently. They do not have a default value. When assigning an application to a site, the multilined value is copied into the site’s application property. When the application gets updated with a new multilined value, the multilined values in site’s application will stay untouched.

Changes to the site-specific application properties will be taken into account after next site reload.

2.6. Managing database connections

If an application needs a database, a new appNG database connection is created for each associated application of a site. If an application has been activated in multiple sites, multiple database connections (one in each site) have been created. The different application instances are thus independent of each other, each accessing their own database.

If the database server is managed by appNG, a database and a site- and application-specific user will be created automatically in the database server. If the database server is not managed by appNG, database and user have to be manually created in the database server and configured at the database connection in appNG.

The edit site page has a section to manage the Database connections for the applications assigned to this site. A database connection has the following attributes:

Attribute Name Description Example

Type

The type of the database.

MYSQL

Name

The name of the database. This is generated and consists of the prefix appng followed by site name and application name, concatenated by underscore.

appng_manager_testapp

JDBC-URL

The JDBC url used to connect to the database.

jdbc:mysql://localhost:3306/ appng_manager_testapp

User-Name

The name of the user used to connect to the database. This name is generated on database creation and is composed of site id and application id.

site1app12

Password

A random password generated on database creation.

Driver-Class

The name of the java.sql.Driver implementation used to connect to the database.

com.mysql.jdbc.Driver

Min. number of connections

appNG uses connection pooling to avoid the overhead by opening and closing JDBC connections. This value defines the minimum number of connections in the pool. Default value is 1.

1

Max. number of connections

This value defines the maximum number of open JDBC connections in that pool. Default value is 20.

20

Validation query

appNG checks if a database is properly connected. Therefore it needs to execute a query. Default for mysql databases is select 1.

select 1

Description

The Administrator can add some more information about the connection. Per default it contains again the site and application name.

manager - testapp

If the database server is not managed by appNG, the JDBC connection has to be configured manually. Above examples for the name schema of Name and User-Name are true if the database server is managed by appNG. Otherwise, the database name and user name are assigned by the database administrator.

This section of the appNG Manager also contains a folded form with an input field to Execute SQL queries. Queries entered in the SQL Statement field are executed in the configured database. The result is shown below in the Result field. This is particularly helpful if there is no native access to the database server. But be aware: "With great power comes great responsibility!"

2.7. Managing the site’s status

2.7.1. Caching

appNG provides integrated caching with Ehcache. Per default, the caching is disabled. The caching can be enabled per site. To enable caching, set the site property (see Configuring site properties) ehcacheEnabled to true. The site’s status section contains the cache statistics. It lists the following information:

Information Description Example

Average get time

The average get time in seconds. Because Ehcache uses System.currentTimeMillis(), which returns the current time in milliseconds, instead of nanoseconds, the accuracy is limited.

0.008894

Hits

The number of times a requested item was found in the cache.

1711886

Misses

The number of times a requested element was not found in the cache.

65480

Name

The name of the cache. It is the prefix pageCache- followed by site name.

pageCache-manager

Size

This number is the actual number of elements in the cache, including expired elements that have not yet been removed.

5866

Statistics accuracy

Accurately measuring statistics can be expensive. appNG uses the setting for best effort and acceptable accuracy

BEST_EFFORT

Status

The status of the cache. Can be one of STATUS_ALIVE, STATUS_UNINITIALISED or STATUS_SHUTDOWN

STATUS_ALIVE

This section also offers a link to clear the cache statistics. Maybe useful if cache settings have been changed.

There is also a table where all elements in the cache are listed with their id (which is the request method plus the URL path), the type of response, size and some other useful information. It offers also two actions per item: to delete it from the cache or to view the item.

The cache is only based on protocol and URL path. That means that resources generated by appNG applications, which will not change often, may also be cached.

At the bottom of the item list is an action to clean the entire cache for that site.

Cache exceptions as URL path prefixes can be maintained as multilined value in the site property ehcacheExceptions. All requests, where the URL path (the part after the domain name) starts with the same prefix (case sensitive) will not be cached. POST requests are never cached.

2.7.2. Sessions

The status section contains a table listing all active sessions for that site. Each entry provides an action to manually expire the session immediately, unless it is the session of the current user.

If appNG runs in a cluster environment, it depends on the cluster setup whether the table shows only sessions of the current node or, if a central session store has been configured, of all nodes.

This table might be useful to check if there are authenticated users in a site before restarting it. For authenticated users their user-name appears in the respective column.

On the bottom of the table an action is available to expire all sessions, except the current user session, immediately.

3. Applications

The page Applications shows the list of all installed applications. Each application in that list offers the two actions Edit and Delete.

3.1. Editing an application

Besides the three switches Privileged Application, Hidden and filebased all information about an application is stored within the XML files of the application package. If something has been changed through the appNG manager, it might be overwritten by the next application update.

We advise to update information of the application within the application package source files to avoid that important changes are overwritten after application updates.

This feature provides powerful possibilities to modify an installed application, which is useful for quickly testing small changes without deploying a new version of the application.

3.1.1. Update Application

In this section some of the main application attributes can be viewed and updated. The most important switches are at the bottom of the form:

Name Description

Privileged Application

A privileged application has elevated access rights in the appNG platform. This is for instance necessary if an application is designed to provide the authentication service for a site.

Hidden

An hidden application is not listed in the application menu of the site. It will still appear in the list of assigned application on the edit page of the site. This is useful if an application has no user interface.

filebased

If appNG runs as single instance, it does not matter whether the application resources are stored in the file system or in the database. But in a cluster scenario, it is necessary, that all resources of an application are stored in the database. All cluster nodes are connected to the same database so they will all use the same application resources.

If the filebased property is toggled, appNG automatically migrates application resources from the database to the file system and vice versa.

After toggling the filebased property, resource migration in a cluster setup only applies to the current node. I.e. if filebased is activated, the application resources are moved from the database to the filesystem of the current node. All other nodes will fail to run the application, as they can not access the application resources any more. Make sure applications are never installed filebased in your cluster!

Installing applications in filebased mode might make development and debugging in a local development environment easier.

3.1.2. Application Properties

This section shows all application properties which have been read from the application.xml file during application installation.

An application property offers the method Edit. It opens a form where the fields value and Multilined value can be changed. But this does not have any effect on properties of assigned applications nor does it have any effect on the site-specific application properties to be created on assignment.

An application property can be deleted. This does not have any effect on site-specific application properties of assigned application, but the deleted property will not be created as site application property when an application gets assigned to a site.

An application property can be created with an unique name. The given value will be set as the default value of the property. This new property will not be added to the list of site-specific application properties of already assigned applications, but it will be created as site-specific application property for upcoming application assignments.

Default values of existing application properties cannot be changed, but the property can be removed and created with the same name. This will affect only site-specific application properties of applications, which are assigned afterwards and will not affect the existing ones.

During an application update, all properties which are part of the application.xml of the new application package are overwritten. Existing application properties in appNG, with no counterpart in the application.xml file, will stay untouched.

3.1.3. Roles

appNG has a fine-grained role and permission model. A permission is the right to see or do something. A role is a set of permissions. An appNG group aggregates roles, and groups can be assigned to appNG users.

Permissions and roles are defined in the application.xml file of an application. The aggregation of permissions and roles can be modified within the appNG manager, but general changes should be done in the application.xml file and changed by an application update.

The Roles page shows the list of all available roles of that application. A role can be edited or deleted and a new role can be created.

Edit Role

By clicking the edit action of a role, a form opens where the user can change the name and description of a role as well as the assignment of permissions to that role. This change takes effect after next login. It will not take immediate effect for currently authenticated users.

Removed permissions of a role are re-assigned during the next application update, if the role still has that permission in the application.xml file of the new application package. Added permissions will still be assigned to the role after an application update, even if the role in the new application package does not have that permission.

Delete Role

By clicking the delete action in the application roles overview, a role can be deleted. This change takes effect after the next login. It will not take immediate effect for currently authenticated users.

A deleted role will be created again on package update, if the deleted role is still part of the application.xml file of the new application package.

If the roles shipped together with the application do not meet your requirements, create your own roles. They will not be modified during an application update. See Create Role.

Create Role

By clicking the action Create role below or above the overview table, a form opens to define the name and description of the new role. It also gives the possibility to assign permissions to that new role. A created role will stay untouched on application updates as long as the new application.xml file of the application package does not contain a (new) role with the same name. Otherwise, the role is updated as described above.

3.1.4. Permissions

A permission is the right to see or do something. Permissions can be applied to a lot of elements like actions, datasources, pages, linkpanels and fields. Furthermore, application developers can test a permission programmatically.

A permission must be used either in the source XML (which describes the structure of the application and the user interface), or in the application source code, to have any effect. We suggest to not change the permissions of an application, unless an application developer advised you to do so.

3.1.5. Resources

This section lists all available resources which have been installed along with the package. The list can be filtered by type:

Name Description

BEANS_XML

beans.xml located in the root directory

JAR

JAR files (*.jar) located at /lib

XML

XML sources (*.xml) located at /conf

XSL

XSL stylesheets (*.xsl) located at /xsl

SQL

SQL scripts (*.sql) located at /sql

TPL

custom (non-XSL) template resources

RESOURCE

custom resources, such as .js, .css, .jpg, .png

DICTIONARY

dictionaries (*.properties) located at /dictionary

APPLICATION

application.xml located in the root directory

ASSET

Not supported yet

The path statements describe the location of the files, relative to the application package respectively the application root folder.

Each element in the list can be deleted, even if this would lead to a situation where the application cannot startup anymore. All text files can be edited, which is useful during rapid prototyping. Furthermore, this function may be handy to apply a quick-fix. However, this should be the exemption, since the regular development workflow is omitted. New Resources can be uploaded. E.g. another dictionary file can be added to support another language.

All resources are removed and re-created on application update. That means, all changes applied to the resources and all additionally created resources are gone after the application update. If application resources have been edited or added, and if you want to keep these changes, make sure the new application contains the changes or the new resources.

3.2. Deleting an application

The application overview provides an action per application to delete the application. After confirming to delete the application, the following actions are executed:

  • remove the application assignment from inactive sites

  • delete roles

  • delete permissions

  • delete resources

  • delete properties

An application assigned to an active site cannot be removed.

4. Templates

Templates can be installed on or removed from the appNG platform. It is not possible to edit or change the contents of an installed template package. A site chooses the template to be used for all applications of that site in the edit site form.

4.1. Deleting a template

In the template overview, an action to delete each template is available. All resources of the template are removed during deletion. A template cannot be removed if it is in use by any site no matter if active or not.

5. Users and groups

appNG features a fine-grained user role and permission model. The key elements are:

Element Description

permission

The right to see or do something. Permissions are defined by the application in the application.xml file. It can be applied to a lot of elements like actions, datasources, pages, linkpanels and fields. Furthermore, application developers can test a permission programmatically.

role

An aggregation of permissions of one application. Roles are defined in the application.xml file.

group

An aggregation of roles, also from different applications. Created and defined in the appNG manager. On installation the group Administrators is created by default. All admin roles from all default applications (appng-manager, appng-scheduler) are automatically assigned to that group.

user

An account in appNG. Could be a pure appNG-local user or a user from an LDAP repository or Active Directory. A user can have multiple groups. In default installations, the user admin is created and gets assigned to the group Administrators.

Permissions are added to a user by assigning groups to users and roles to groups and permissions to roles. The assignment has always a contributing nature. It will not happen that an assignment will remove the permission set by another assignment. The user will always have the super-set of all permissions of all groups and roles assigned to him.

The users page shows a list of all configured users.

5.1. LDAP connectivity

If the type LDAP user or LDAP Group is used, authentication will use an external LDAP server.

In case of LDAP user the username is mapped to an LDAP principal and a simple bind is done against the LDAP server. The user is authenticated, if the bind succeeds. Note that the configured LDAP user name and the one entered in the login mask, are the same, when using LDAP user.

In case of LDAP Group the configured name is interpreted as an LDAP group, which is resolved to the actual usernames. This comprises three steps:

  1. The username entered in the login mask is used to bind in the same way as described for LDAP user above.

  2. The configured LDAP Group name is mapped to members by looking up the member attributes of the object cn=<name>,ldapGroupBaseDn. This step makes use of the service credentials configured via ldapUser and ldapPassword, to execute the lookup.

  3. The username entered in the login mask must be present in the ldapIdAttribute of at least one member object, found in the previous step, in order to be successful.

Principal Mapping

How usernames are mapped to ldap principals depends on the value of ldapPrincipalScheme:

  • “DN” : results in ldapIdAttribute=<username>,ldapUserBaseDn

  • “UPN”: results in <username>@ldapDomain

  • “SAM”: results in ldapDomain\<username>

The schemes “UPN” and “SAM” are Windows AD specific (see MSDN on supported authentication methods in AD). The default value is “SAM” to remain backward compatibility with older appNG versions

Property Description Example

ldapDomain

The Netbios Domain name to use, when "SAM" is used as principal scheme

EXAMPLE

ldapGroupBaseDn

The base-DN for LDAP-groups

OU=Groups,DC=example,DC=com

ldapHost

The LDAP host in provider URL format (ldap[s]://<host>:<port>). Note that you might need to add CA certificates to the truststore of the executing JVM if you enable “ldaps”.

ldap:<host>:<port>

ldapIdAttribute

The name of the LDAP-attribute containing the user-id used for authentication

sAMAccountName

ldapPassword

Password of the LDAP service-user

secret

ldapPrincipalScheme

How the LDAP principal is built from a given username when logging in: “DN”, “UPN” or “SAM” as described above.

SAM

ldapStartTls

Use STARTTLS for the LDAP connection. If you set this to true the value of ldapHost should begin with ldap: (not ldaps:), because STARTTLS and LDAP over SSL (which is used when ldaps: is in place) are mutually exclusive.

false

ldapUser

The name of the LDAP service-user for general LDAP lookups. If the value is a Distinguished Name (e.g. “cn=Service User,dc=mycompany,dc=com”) it will be used directly as LDAP principal. Otherwise the principal will be derived according to the value specified in ldapPrincipalScheme.

serviceUser

ldapUserBaseDn

The base-DN which is used to map a plain username to a Distinguished Name, if "DN" is used as principal scheme.

OU=Users,DC=example,DC=com and LDAP over SSL (which is used when “ldaps:” is in place) are mutually exclusive.

Read more about site properties in Configuring site properties in this manual.

5.2. Users

5.2.1. Creating a user

Above and below the users list a link with the action to create a user is displayed. When clicking this link a new form opens, where the user attributes can be defined:

Attribute Description Example

Name

User name as used for the login. Must be unique.

johndoe

Real Name

The person’s real name

John Doe

E-mail

E-Mail address of the person

john.doe@example.com

Description

Some additional info about the user

Just a test account

Type

One of Local user, LDAP User or LDAP Group

Local user

Language

The preferred language of the user. Shows available appNG languages.

en

Timezone

The users timezone

Berlin (GMT+01:00)

Password

Must have at least 6 chars and max 64 chars

v3ry53cr37

Password Confirmation

Must contain the same value as the Password field

v3ry53cr37

Groups

Select initial groups of the user

Administrators

5.2.2. Editing a user

The default action of an entry in the users list is the action to edit a user. This opens a form where nearly all of the user attributes can be changed, except the internal ID and the user name.

5.3. Groups

On the page Users there is another section Groups. It lists all available groups configured in appNG. On appNG installation, the group Administrators is created. This is special group because if an application defines an admin-role in the application.xml file, this role is automatically assigned to this group. It is also not possible to delete this group.

The overview table provides actions to create, edit and delete groups.

5.3.1. Creating a group

When clicking the Create group action on top or bottom of the table, a new form opens where the attributes of the group can be defined:

Attribute Description

Name

Name of the group. Must be unique.

Description

Some additional info about the group.

Roles

Select roles from different applications to assign them to the group. Only roles of those applications are available which are assigned to the current site.

5.3.2. Editing a group

In the overview table of groups is an action per group to edit it. Except the internal ID, all attributes and the role assignment of the group can be changed.

5.3.3. Deleting a group

In the overview table of groups is an action per group to delete it. The group Administrators is a special group and cannot be deleted. After the deletion has been confirmed, the group and all assignments to users are completely removed.

6. Platform

The page Platform contains all elements regarding the installed appNG platform.

6.1. Configuring the platform

The first section of the page Platform lists the platform properties. A platform property can be created, deleted and edited.

Platform properties are created during the first (initial) startup of the platform. The default values are defined within the appNG platform. The default value may be overwritten during a platform update.

As long as the value or the multilined value of a property is not defined, appNG uses the default value.

6.2. Platform properties

The appNG platform can be configured by a manageable amount of properties.

When changing platform properties, appNG (means: Tomcat) needs to be restarted to apply those changes.

A detailed list of the available properties can be found here:

Name Type Category Description Default

xssProtect

boolean

Security

Set to true to enable XSS protection

false

applicationDir

text

Backend

The folder used for installing file-based-applications, relative to the webapp-root

/applications

rootPath

text

Backend

The absolute root-path of the platform

determined during installation

cacheApplicationFolder

text

Caching

The folder for the application-cache, relative to cacheFolder. Applications might use this folder to cache temporary data.

application

cacheFolder

text

Caching

The cache folder, relative to WEB-INF. Contains the cacheFolder and the cacheApplicationFolder.

cache

cacheImageFolder

text

Caching

The folder used for caching images, within the application-cache

image

cachePlatformFolder

text

Caching

The folder for the cache, relative to cacheFolder. The cache is used by appNG to cache application resources.

platform

csrfFilterEnabled

boolean

Security

Set to true to enable a filter preventing CSRF-attacks

false

databasePrefix

text

Database

The prefix to use when generating database names (in case manageDatabases is true)

empty

databaseValidationPeriod

text

Database

The idle database connection test period in minutes. If a database connection remains idle for the specified time, the validation query defined in the database connection will be sent to prevent a database connection timeout.

15

defaultTemplate

text

UI

The name of the default template to use (must be a folder located under templateFolder)

appng

devMode

boolean

Backend

Disable for production use. If enabled, XML and XSL resources will be written to the cache directory. If disabled, XML and XSL resources will be cached in memory.

false

ehcacheConfig

text

Caching

The global page cache configuration using the Ehcache XML configuration format. This cache is used to cache HTTP responses.

WEB-INF/conf/ehcache.xml

encoding

text

UI

The charset/encoding used for http-responses.

UTF-8

filebasedDeployment

boolean

Backend

Set to true if applications should be deployed to the local filesystem, false otherwise.

true

formatOutput

boolean

UI

Disable for production use. If enabled, debugging is easier, but Textarea values are formatted wrong.

false

imageMagickPath

text

Backend

The path to the ImageMagick executable

/usr/bin

jspFileType

text

Backend

The file-extension for JSP-files.

jsp

locale

text

UI

The default locale for the site. Use one of java.util.Locale.getAvailableLocales()

en

logfile

text

Backend

The name of the logfile generated by appNG

appNG.log

mailDisabled

boolean

Backend

Set to true to disable mailing and log the e-mails instead.

true

mailHost

text

Backend

The mail-host to use

localhost

mailPort

text

Backend

The mail-port to use

25

manageDatabases

boolean

Database

If set to true, appNG will manage the databases (create schemas and users) required by the applications.

true

maxUploadSize

text

Backend

The maximum size for file uploads in bytes

31457280

mdcEnabled

boolean

Backend

Set to true to enable support for Mapped Diagnostic Context (MDC) Logging.

true

messagingEnabled

boolean

Clustering

Set to true to enable cluster messaging

false

messagingReceiver

text

Clustering

Define messaging implementation by referring class name.

org.appng.core.controller.messaging.MulticastReceiver

messagingGroupAddress

text

Clustering

The multicast address used for messaging

224.2.2.4

messagingGroupPort

text

Clustering

The port used for multicast messaging

4000

monitorPerformance

boolean

Backend

Set to true to enable performance monitoring for the target XML

false

passwordPolicyErrorMessageKey

text

Security

The resource-bundle key (for messages-core) for the message which is being displayed when the password does not match the policy.

DefaultPasswordPolicy.errorMessage

passwordPolicyRegEx

text

Security

A regular expression describing the password-policy

[\S]{6,64}

repositoryPath

text

Backend

The folder used for the content repositories of the site, relative to the webapp-root

repository

repositoryDefaultDigest

text

Security

The default digest for a published local application repository

empty

repositoryCert

text

Security

The certificate to use when verifying a signed remote application repository (PEM format)

empty

repositorySignature

text

Security

The private key to use when signing a local published application repository (PEM format)

empty

repositoryTrustStore

text

Security

The truststore used when verifying a signed remote application repository, using file-protocol. If empty, the default $java.home/lib/security/cacerts is being used.

empty

repositoryTrustStorePassword

text

Security

The truststore’s password

empty

repositoryVerifySignature

boolean

Security

When set to true, signed remote application repositories are validated against the configured (or default) truststore.

true

sessionTimeout

text

The timeout for a user session in seconds

1800

sharedSecret

text

Security

The shared secret used for digest authentication

none, generated during installation

templateFolder

text

Backend

The folder used for templates, relative to the webapp-root

/templates

templatePrefix

text

Backend

The path under which the resources of the active template are beeing served.

/template

timeZone

text

UI

The default timezone for the site. Use one of java.util.TimeZone.getAvailableIDs().

TimeZone.getDefault().getID()

uploadDir

text

Backend

The folder for saving uploads, relative to the webapp-root

/uploads

vHostMode

text

Backend

Defines whether the server is identified by its IP (IP_BASED) or by its name (NAME_BASED)

NAME_BASED

writeDebugFiles

boolean

Backend

When set to true, the XML, XSLT and potential Exceptions occurring on a request to the appNG manager GUI are written to rootPath/debug

false

xssAllowedTags

text

Security

A list of additionally allowed HTML Tags, separated by |, optionally followed by a space-separated list of allowed attributes. Example:
h1|h2|a href class style|div align style

a href class style|div align style

6.2.1. Edit platform property

Each property in the list of platform properties offers an action to edit it. By clicking this action a new form opens where the value or the multilined value of a property can be changed. Note that it is not possible to save the property if both fields are filled.

If the value or multilined value is defined, appNG will use this new value after a platform reload. Empty the value or multilined value field if appNG should use the default again.

6.2.2. Create platform property

On top and bottom of the table an action to create a platform property is displayed. The new property has to have an unique name. The given value will be used as default value. Creating a property can be used to activate and configure features for appNG not available in the default configuration. Properties can also be used as feature toggles to activate and configure new features during appNG platform development.

6.2.3. Delete platform property

Each property in the list can be deleted. For standard properties this makes no sense because the property will be recreated after a platform reload. Manually created properties can be deleted.

6.3. Reloading the platform

On top and bottom of the table an action to reload the platform is displayed. This action reinitializes the platform configuration and reloads all sites without restarting the whole Tomcat instance.

6.4. Managing the platform’s database connection

appNG stores all its configuration data like platform properties, sites, applications properties, site properties, site-specific application properties and also entire application resources in a database. The database is a fundamental component of each appNG installation.

The platform page has a section to manage the database connection. appNG currently supports three different kinds of database servers. Database connections are pre-configured for those database servers. Only one of them is active after a default installation.

Supported database servers are:

  • MYSQL

  • MSSQL

  • HSQL

HSQL is used for executing integration tests and for the appNG standalone version. For production use we recommend to use either MySQL or MSSQL.

6.4.1. Editing a database connection

This section allows to modify the existing database connections. It is not supported to delete or create database connections. To edit a database connection click on the table row or the edit action within a row. A new form opens where the database connection attributes can be maintained:

Attribute Name Description Example

Type

The type of the database.

MYSQL

Name

The name of the database.

appNG MYSQL

JDBC-URL

The JDBC url used to connect to the database.

jdbc:mysql://localhost:3306/appng

User-Name

The name of the user used to connect to the database.

appng

Password

The password used to authenticate the database user.

Xoos9Eeng1ku

Driver-Class

The name of the java.sql.Driver implementation used to connect to the database.

com.mysql.jdbc.Driver

managed

Flag to indicate whether the database is managed by appNG or not. If the database is not managed by appNG, a database administrator has to take care of creating databases for the platform as well as for applications requesting a database.

true

active

Flag to indicate whether this connection can be used by appNG.

yes

Min. number of connections

appNG uses connection pooling to avoid the overhead by opening and closing JDBC connections. This value defines the minimum number of connections in the pool. Default value is 1.

1

Max. number of connections

This value defines the maximum number of open JDBC connections in that pool. Default value is 20.

20

Validation query

appNG checks if the database is properly connected. Therefore it needs to execute a query. Default for mysql databases is select 1.

select 1

Description

The Administrator can add some more information about the connection.

appNG Root Database

appNG can use database connections to different types of database servers at the same time. TODO: Explain, example, order of supported databases in application.xml

6.5. JAR-Files

The section JAR-Files lists all Java archive files of the platform and JAR files which are provided by the Tomcat runtime environment. File name, version, title and vendor are displayed. This is useful to verify the version of the used libraries. It also helps to include library versions in bug reports. The information displayed here is read from the META-INF/MANIFEST.MF of the respective library. If information is missing for a certain library, its MANIFEST.MF is probably not well-maintained.

6.6. Events

There are certain events that occur within the appNG platform that are written to an event log. This event log can be shown, filtered and exported.

Events that are recorded include:

  • starting/stopping the platform

  • starting/stopping a site

  • assigning/removing an application to/from a site

  • user log-in and log-out, session expiration

  • creating/dropping databases

  • creating/modifing any of appNG’s core components
    (sites, applications, users, groups, roles, permissions, resources and database connections)

A platform event has the following attributes:

Attribute Name Description Example

Created

The date and time when the event occurred.

18/04/17 12:37:49

Type

The type of the event. One of CREATE, UPDATE, DELETE, INFO,ERROR,WARN.

INFO

Event

A text describing the event.

Loaded site manager

Application

The application that triggered the event. One of appNG, appNG CLI or appNGizer

appNG

Context

The context the event was executed in, depending on the application that triggered the event.
If it was triggered by appNG or appNGizer, the context is the relative URL path that caused the event.
If triggered by appNG CLI, the context is the CLI command that caused the event

/manager/manager/appng-manager/sites
batch -f ./install.list

User

The user that triggered the event. This is either a user that was signed in at the appNG Manager, appNG platform (in case no specific user could be determined),
appNGizer (when triggered by the same) or, in case of an CLI command, the name of the system user that executed the command.

appNG Administrator

Host

The remote host or IP that triggered the event. May contain an IPv4 or IPv6 address or a host name.

127.0.0.1

Host name

The local host name of the appNG server where the event was triggered at.

appng-node1.example.com

Request

A universally unique identifier (UUID) for the request that triggered the event. Multiple events can be triggered by the same request.

ba81aa7b-069b-4ed4-954e-7050f3a59da6

Session

The first 8 characters of the HTTP session, if applicable (only the case when triggered by appNG or appNGizer).

D809E5C5

6.7. Dictionary

This section shows the content of the platform dictionary.

7. Repositories

appNG applications are installed from a repository. A repository can be a local folder where application packages can be copied to or uploaded into. A repository also implements some SOAP services to provide its applications to other appNG installations as a remote repository.

7.1. Creating a repository

On page Repository a list of all available repositories is shown. On top and bottom of that list is a link to create a repository. By clicking this link, a new form opens where the repository attributes can be defined:

Attribute Name Description Example

Name

Name of the repository.

Local
Remote

Description

Some additional information about the repository.

Local repository
appNG central repository

Type

Type of the repository. One of Local Repository and Published Repository.

Local Repository
Published Repository

URI

Address of the repository. An URL of a remote repository (prefix: http: or https:) or the file path to a local repository (prefix: file:).

file:/var/appng/repository
https://appng.org/service/appng/appng-manager/soap/repositoryService

active

Indicates if this repository is active

true
true

7.2. Editing a repository

Each repository in the list offers an action to edit the repository configuration. In addition to the above mentioned attributes, further attributes appear depending on the chosen repository type.

7.2.1. Local Repository

Attribute Name Description

Mode

The repository can offer only snapshots, stables or both kinds of builds.

Published

Activate this checkbox if the repository shall be published as remote repository to other appNG instances. The SOAP provider service will be available under the URL <protocol>://<domain>.<tld>/service/<site-name>/appng-manager/soap/repositoryService

Digest

If this is a published repository, a digest for authentication (shared secret) can be defined to make sure only authorized appNG instances can use it as a remote repository. The digest is optional.

7.2.2. Remote Repository

Attribute Name Description

Name of remote repository

Multiple repositories can be published under the same URL. Entering the name of the remote repository is required and identifies the repository in the remote appNG instance to be accessed.

Digest

The digest to authenticate against the remote repository. If the remote repository grants anonymous access, this field can be left empty.

Upload trusted certificate

Upload the certificate used to verify the contents of the remote repository.

7.3. Deleting a repository

Each item in the list of repositories offers an action to delete the respective repository. After confirming the deletion, the configuration of that repository is removed from the appNG database. It does not remove any files in the local file system nor does it remove any applications installed from this repository.

7.4. Reloading a repository

When the page is rendered, the current list of available applications and their versions are read from the file system or retrieved via a SOAP request from the remote repository. This information is cached by the system to avoid unnecessary overhead. By clicking the action reload, this cache is refreshed with the current data.

7.5. Listing the applications of a repository

Each item in the list of repositories offers an action Installation. By clicking this action, a new section opens, showing a list of all available applications in that repository. It informs about the latest stable release and about the latest snapshot build. It also shows the currently installed version.

Depending on the installed version, each entry offers a set of actions:

Action Description

Show application versions

By clicking this action a table is shown with all versions of that application available in the repository. Each version in this list can be selected to be installed on the platform. It is also possible to downgrade an installed application, but this is technically only possible if no database schema migrations have been applied between the actual and the old version.

Install latest release

This action can be executed if the latest release is not equal to the currently installed release or if the currently installed version is a snapshot. By clicking this link, the latest release version of the application from the repository will be installed.

Install latest snapshot

This action can be executed if there is a snapshot build available of an application and if the currently installed version is not equal to this latest snapshot version. By clicking this link, the latest snapshot build of the application will be installed from the repository.

As defined above, the Install latest …​ actions will only check if the currently installed version is not equal to the latest version in repository. It does not check whether the installed version is higher than the latest version in the repository. If the currently installed application has a higher version than the latest one in the repository, appNG would downgrade the application by executing this action.

Even if an application has been updated, the currently running instance in the site will still be the old one. To finally activate the newly installed application all sites where the application is assigned to needs to be restarted.

7.6. Uploading applications

There are two ways to add an application version to a repository. By copying it into the file system folder of the local repository or by uploading the application.

Copying the application to the local file system folder does not automatically refresh the repository cache, although appNG should detect the new file. If it is not listed immediately, reloading the repository should help.

Application packages can only be uploaded to local repositories. The upload form is placed above the list of available application versions of that repository. An application package (*.zip file) can be selected from the local machine to be uploaded to the local repository.

After uploading the file, the repository cache is automatically refreshed and the application can be installed.

8. System

This page shows information about the runtime environment of the appNG platform.

8.1. Environment

8.1.1. JVM Arguments

Returns the parameters passed to the Java virtual machine.

8.1.2. System Properties

Determines the current system properties. It displays all values returned by calling the static System method

java.lang.System.getProperties()

8.1.3. System Environment

Determines the current system environment. The environment is a system-dependent mapping from names to values which is passed from parent to child processes. AppNG does this by calling

java.lang.System.getenv()

8.2. Status

The Status section displays some information about the system status.

8.2.1. Processor

Shows the system load average for the last minute and the number of processors available to the Java virtual machine.

8.2.2. Memory

Determines the current memory usage of the heap that is used for object allocation and the current memory usage of non-heap memory that is used by the Java virtual machine.

8.2.3. Sessions

Lists all sessions currently active on the platform. Allows to expire one or all sessions, besides the session of the current user.

8.3. Logfile

Shows a tail view of the appNG logfile from the current node. If appNG runs in a cluster setup be aware that there are other logfiles on other nodes.

It also shows the current log4j configuration in an editable text field. Changes to the log configuration can be submitted. This will update the current log4j configuration immediately without a platform reload. It is optionally possible to propagate this configuration to all other nodes in the cluster.

8.4. Cluster Status

This section displays the status of all other nodes in the cluster. A status entry consists of:

Status Item Description

The cluster status is directly requested from the other nodes in the cluster. This timestamp shows when the data of the respective node has been retrieved.

Memory status

The current memory usage of the heap of the respective node that is used for object allocation.

Node ID

Node id defined as system property appng.node.id. Identifies a node within a cluster.

Last Updated

Each entry can be enlarged to show also:

  • List and status of all sites of that node.

  • System properties of that node as shown in the Environment page of that node.

  • System Environment of that node as shown in the Environment page of that node.

9. Jobs

The appNG manager ships with three scheduled jobs.

They all have something to do with platform-events.

9.1. Database Report Job

Purpose:
This job collects all platform events containg 'jdbc:' in their message that occurred in the last hour/day/week/month, puts them into an Excel-file and sends this file via e-mail to all users that own the role 'Database report receiver'.

Enabled by default: No.

Configuration
This job can be configured using the following application properties:

  • databaseReportReceivers
    A semicolon separted list of receviers, additional to all users with role 'Database report receiver'.
    Default: <none>

  • databaseReportSender
    The sender for the database report email.
    Default: report@example.com

  • databaseReportSubject
    The subject for the database report email.
    Default: appNG database report

  • databaseReportText
    The text for the database report email.
    Default: See attached file for a report of the database related platform events.

Additionally, the entry interval in the job’s jobDataMap can be used to set the time unit for the report (one of HOUR, DAY, WEEK, MONTH, defaults to DAY).

9.2. Log Database Size Job

Purpose:
This job writes a platform event for each active and working database connection, may it be a global one or of a site’s application.

An entry looks like this:
Size of MYSQL database for site 'appng' located at 'jdbc:mysql://localhost:3306/my_app' is 16.44MB

Enabled by default: Yes.

Scheduled at: 0 0 1 1/1 * ? *
(every night at 1:00 am)

9.3. Platform Event Report Job

Purpose:
This job collects all platform events of certain types that occurred in the last hour/day/week/month, puts them into an Excel-file and sends this file via e-mail to all users that own the role 'Event report receiver'.

Enabled by default: No.

Configuration
This job can be configured using the following application properties:

  • eventReportReceivers
    A semicolon separted list of receviers, additional to all users with role 'Event report receiver'.
    Default: <none>

  • eventReportSender
    The sender for the event report email.
    Ddefault: report@example.com

  • eventReportSubject
    The subject for the event report email.
    Default: appNG event report

  • eventReportText
    The text for the event report email.
    Default: See attached file for a report of the recent appNG platform events

  • eventReportTypes
    The event types to be included in the even report email, separeted by space.
    Default: CREATE UPDATE DELETE INFO ERROR WARN

Additionally, the entry interval in the job’s jobDataMap can be used to set the time unit for the report (one of HOUR, DAY, WEEK, MONTH, defaults to DAY).