Apps
Management of apps that are based on yuuvis® Momentum via schema, permissions, system hook configuration and availability configurations.
Table of Contents
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 resources 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 resource files. There are endpoints provided by the API gateway that allow for retrieval, validation or update of the resource files.
The system can support various apps.
App Information
System integrators can see all existing apps in the system by using the endpoint
Users can see all apps that are enabled for their tenant by using the endpoint
App Management
To create an app, deploy any app-specific resource file (schema, role set, system hook configuration). It has to be valid or completely empty. Alternatively, you can introduce a new app by specifying its name and its tenant-specific state in an app set as described below.
The endpoints for the management of app-specific resource 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...zA...Z][a...zA...Z0...9]*-)?([a...zA...Z][a...zA...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-specific System Hooks
As of 2022 Summer, it is possible to configure app-specific system hooks in separate resource files.
>> systemHookConfiguration.json
The following endpoints are available to manage those app-specific resources:
- GET /api/system/apps/{app}/systemhooks
- POST /api/system/apps/{app}/systemhooks
- POST /api/system/apps/{app}/systemhooks/validate
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
An app does not necessarily need its own resources within the core system. The core system can be used to only mark tenants to have a specific app. A new app can be introduced to the system by simply enabling if for a tenant. It is not necessary to create an initial resource (schema, role set or system hook configuration) for the app before you enable it for a tenant.
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.