Skip to main content

Application split VirtualApp

Overview​

The goal of the application split is to allow easy creation of partial applications from already existing larger base application. That means isolate certain functionality which will for the user will look like independent, separate application. The rest of the functionality should be unavailable to the user.

For example from HCM applications we can create Appreciations, Assessment, SWOT and several other applications.

Main principles​

The application split functionality is based on definition of separate right object group, side menu definition and permissions for the partial application. There is no need for separate deployment of partial application - only base application is deployed.

During application initialization the part code of the application is derived from the base part code which is hardcoded in the base application (in authentication library initialization) and extension which is extracted from the URL.

The base application url has three segments, eg. /apps/asol-hxm/x/. The partial application url has extension appended to the third x segment, eg. /apps/asol-hxm/x-appreciations/. In this example the appreciation is part code extension.

This part code is used to retrieve the side menu definition for the application.

This way when user access the url with part code extension the partial application will be shown.

Steps to create partial application​

Right now these steps are needed to create partial application

  1. Define the part code extension
  2. Create new right object group in some tenant database via IDM api call. Use the complete part code (base+extension) as a right object code.
  3. Prepare side menu definition json file. This can be derived from the base app definition. In this file following fields have to adjusted:
    • id - use complete part code
    • applicationCode - use complete part code
    • name - name of the partial application
    • shortName - short name of the partial application
    • logo - link to logo file (has to uploaded to avaspace content manager as public file into folder with name identical to complete part code)
    • icon - link to logo file (has to uploaded to avaspace content manager as public file into folder with name identical to complete part code)
    • href - add /x-{complete part code} to the original value, eg https://#{Dns_AsolAppWebSite}#:50019/x-SWOT
    • nameLocationlization, shortNameLocalization - localized values for the name and short name 4.Upload side menu definition into IDM via api call. . Copy record corresponding to complete part code from tenant collection IDM.RightObjectGroups to master collection IDM.RightObjectGroups
  4. Adjust following values in master collection IDM.RightObjectGroups in the record corresponding to complete part code:
    • href - use value with proper extension, eg. https://rca.avaplace.com/apps/asol-hcm/x-appreciations
    • backendhref - use value identical to base app
  5. Prepare json file for UI authorization with content corresponding to desired functionality. applicationCode has to contain complete part code.
  6. Upload the UI authorization file to IDM via api endpoint.

The base app has to deployed with base href set to contain the x at the end to prevent accidental match with Angular routing.

Implementation​

The core of implementation is in the initialization code of @asol-platform/authentication library, version 0.0.88 up. Here the third segment of the application URL is checked if it contains the part code extension. If so, the complete part code is formed from base app code and extension and is used as a value for APP_ID injection token (which is later used to download the side menu). The part code extension is also used to create proper value for APP_BASE_HREF injection token so the Angular router propery recognizes the base url and is able to correctly determine where the routing url stars.