Management of apps that are based on yuuvis® Momentum via schema, permissions and availability configurations.

Introduction

The yuuvis® Momentum core system can be used as basis for apps. Apps are additional logical units that enhance the core system. The core system itself provides the possibility to define specific configurations for the individual apps. Thus, each app can have its own schema and its own role set. As of version 2021 Summer, apps can be enabled or disabled for individual tenants. The SYSTEM service manages the corresponding configuration files. There are endpoints provided by the API gateway that allow for retrieval, validation or update of the configuration files.

The system can support various apps.

App Information

System integrators can see all existing apps in the system by using the endpoint

• GET /api/system/apps

Users can see all apps that are enabled for their tenant by using the endpoint

• GET /api/dms/apps

App Management

The endpoints for the management of app-specific configuration files are provided by the API gateway and call the SYSTEM Service internally.

App names are case-insensitive. Furthermore, the system stores uppercase letters in app names in a lowercase form. For example, if you post an app schema for the app name myNewApp (via POST /system/apps/myNewApp/schema), this new app appears with the name mynewapp in the results of endpoints like GET /api/dms/apps or GET /api/system/apps.

Additionally, app names have to match the regular expression [a-z0-9]* in order to be consistent with the schema validation of app-specific prefixes.

App Schemata

App-specific schemata are managed via the following endpoints:

• GET /api/system/apps/{app}/schema
• POST /api/system/apps/{app}/schema
• POST api/system/apps/{app}/schema/validate

In the multi-tenant landscape of yuuvis® Momentum, any object types or properties that need to be available for multiple or all tenants, need to be introduced to the system schema. To prevent cluttering the system schema, avoid dependencies and allow for duplicate names, the system schema can be structured into applications, which provide a namespace for properties and object types pertaining to a particular use case.
>> Schema - Defining Object Types

Role Sets for Apps

App-specific role sets are managed via the following endpoints:

• GET /api/system/apps/{app}/permissions
• POST /api/system/apps/{app}/permissions
• POST /api/system/apps/{app}/permissions/validate

The permissions to access objects or to perform certain actions are assigned to specific roles that are listed in the role set. yuuvis® Momentum has the ability to further structure the global role set into applications.
>> Access Authorization and Permissions

App Sets for Availability Management

As of version 2021 Summer, the availability of an app for a specified tenant is managed in an app set via the following endpoints:

• GET /api/system/tenants/{tenant}/apps
• POST /api/system/tenants/{tenant}/apps
• POST /api/system/tenants/{tenant}/apps/validate

The configuration of the availability of each app for the specified tenant is stored and managed in the apps.xml file as shown in the example code block below. In this app set, each app has its own section (<app></app>) containing the app's name (<name></name>) and state of availability (<state></state>) which can be either enabled or disabled. The default value for state is disabled. Thus, each app that is not listed in the passed configuration XML will not be available for the corresponding tenant. There is no difference in the configuration of not-listed apps and apps listed as disabled.

<?xml version="1.0" encoding="utf-8"?>
<apps xmlns="http://optimal-systems.org/ns/yuuvis/apps/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://optimal-systems.org/ns/yuuvis/apps/ yuuvis-core-apps.xsd">
    <app>
        <name>clientsystem</name>
        <state>enabled</state>
    </app>
    <app>
        <name>client</name>
        <state>enabled</state>
    </app>
    <app>
        <name>email</name>
        <state>disabled</state>
    </app>
    <app>
        <name>acl</name>
        <state>disabled</state>
    </app>
</apps>

The apps.xml configuration file is stored via the CONFIG service and should only be changed using the above listed endpoints.

Note: If there is no apps.xml file, the GET endpoint will return the error code 404. Especially in systems of version 2020 Winter and older, there is no app set. If the file is missing entirely, all apps are enabled for all tenants in the system.

There can be dependencies between different app and tenant schemata via property references or secondary object type references. The validation of the app set considers these dependencies. If the schema of an app is referenced by the global or the corresponding tenant schema, the app cannot be disabled for the specified tenant. Equally, if the schema of an app (A) is referenced by the schema of another app (B), it is not possible to disable the first app (A) and enable the second app (B) for any tenant.

Creating a new dependency considers app availability for all tenants. If a new reference on an app schema (A) is introduced into an app schema (B), the referenced app (B) has to be enabled for each tenant for which the referencing app (A) is enabled. The validation fails if there is a tenant for which the app (A) is enabled and the app (B) is disabled.

Summary

Apps based on yuuvis® Momentum can be provided with their own schema and role set for individual configuration. As of version 2021 Summer, apps can be enabled or disabled for individual tenants via app sets. Each app set is validated in order to avoid broken references on app schemata.