When the execution of a task is launched, it runs in a dedicated thread of the Execution Service. The resources that this job requires add up to the microservice consumption. To manage this, there is a limit on the number of jobs that can run simultaneously in the Execution Service, with a default of 5. When this limit is reached and a new job is launched, it is queued until a running job finishes. This queue is by default unlimited.

The parameters that control the above are the following:

They are Spring properties, and can therefore be overridden by the standard Spring mechanisms, typically environment variables set in the Docker configuration. For more details, refer to Section Using Docker Configuration Files.

Finished jobs, completed or failed, are automatically removed from the database. You can configure the cleaning criteria by editing the YAML file extensions/execution-service-extension/src/main/resources/application.yml.

job-management:
  history:
    max-age: 30 # Use -1 to disable max-age jobs cleaning
    jobs-limit: 1000 # Use -1 to disable jobs-limit cleaning
    cleaning-cron: 0 0 0 * * * # Spring cron expression to periodically run jobs auto cleaning, default is every day at 00:00, see https://www.spring.io/blog/2020/11/10/new-in-spring-5-3-improved-cron-expressions

Users with the role APPLICATION_ADMIN can also launch the cleaning process, at all times, through the following REST API call:

POST /api/execution/jobs/clean-jobs?maxAge=xxx&jobsLimit=yyy

The caller can provide a value for the parameters maxAge and jobsLimit. If none is provided, the default values are used.

An application built using DOC can implement CORS to secure and facilitate integration with resources from different origins than its backend.

Requests to DOC API that require CORS usually come from the frontend of a web application other than yours. Instead, requests to DOC API that originate from the backend of an application do not involve resource sharing and do not require CORS.

Figure 15.1. Understanding CORS and Normal Requests

In such a situation, the web browser running the 3rd-party web application automatically makes “preflight requests” to ensure CORS is allowed and expects the API to answer with a correct response. In case the response is not correct, an error is displayed in your browser debug console.

Figure 15.2. Encountering a CORS Error

For safety reasons, CORS should not be accepting all routes and origins of your application, but only the ones required for the use case at hand.

To do so, the Gateway Service must be configured by defining the information that can be exchanged through headers. Configurations at micro-service level are ineffective regarding CORS, therefore, the file extensions/gateway-service-extension/config/application.yml application should be edited by:

For example, a rule can be added as follows:

spring:
  cloud:
    gateway:
      globalcors:
        corsConfigurations:
          '[/api/service/controller-path]':
            allowedOrigins: "http://third.party.domain.com"
            allowedMethods: 
            - GET
            allowedHeaders: "X-Api-Key"

The need for the "X-Api-Key" header in CORS depends on the security requirements and the context in which the API is used. For instance, it might not be required for internal use and same-origin requests, or public APIs and open resources. However, it might be needed to request any other type of private servers.

For more details, refer to the official Spring Cloud Gateway documentation.

Content security policy (also called CSP) is a layer of security that helps to detect and mitigate certain types of attacks on web application. It mainly helps for cross-site scripting, code injections and https only.

You can find additional information on this standard there:

The functioning of CSP is really simple. The server adds a header in the web document response that will tell the browser where it can load resources and how to behave with these resources.

The headers have to respect a given structure, you can find some specifications on this header there: CSP header specification

It is composed of a list of policy directives and has the following form:

Content-Security-Policy: <first-policy-directive>; <second-policy-directive>; <etc>

Each policy directive is composed of a directive name and some values.

The following figure illustrates a basic example of CSP header:

Content-Security-Policy: default-src "self" https: ; object-src "none"

The blue squares highlight two policy directives, the green squares highlight the directive names, and the yellow squares highlight the values.

For an application built on top of DOC, a default configuration is provided for the CSP header. If you need to customize it, it can be achieved in the Gateway extension.

A typical case in which the CSP header needs to be customized is when you develop a graphical widget that consumes external resources like icons, fonts, etc.

The configuration is done in the following file: extensions/gateway-service-extension/config/application.yml

Note that Safari does not handle the CSP header in the same way as other browsers, like Chrome, Firefox or Edge. In order for the web notifications to work properly, you will have to add the base web socket URL among the values of the "default-src" directive policy. For an application accessible via the URL https://my-application.io, you need to add the value wss://my-application.io to the policy-directive default-src. It should look like the following pseudo-code: spring: cloud: gateway: filter: secure-headers: content-security-policy: "default-src wss://my-application.io 'self' ..."

DOC provides a mechanism for implementing translation of the web client using the ngx-translate library, the default language file is web/src/assets/i18n/en.json It is possible to customize strings or create a localized version for another language by duplicating this file structure, naming it accordingly and using it in AppComponent constructor like this:

export class AppComponent {
    constructor(translate: TranslateService, settingsService: GeneSettingsService) {
        // add the new language
        translate.addLangs(['fr','en']);
        // this language will be used as a fallback when a translation isn't found in the current language
        translate.setDefaultLang('en');
        
        // translations will be taken from web/src/assets/i18n/fr.json
        translate.use('fr');
        
        // DOC Settings
        settingsService.registerDefaultApplicationSettings( DEFAULT_APP_SETTINGS );
    }
}

The missing translation values from the file will fall back to the one provided by default by DOC, and a warning will be emitted in the browser console with the missing keys.

DOC uses AG Grid library for Data Grids, which uses its own translation file located under web/src/assets/i18n/ag-grid.en.json.

To create a localized version for another language, you can, for example, duplicate the file structure of web/src/assets/i18n/ag-grid.fr.json, the fr locale containing the key/values. For more detals, refer to the Official AG Grid Documentation.

Example:

{
    // Set Filter
    selectAll: '(Select All)',
    selectAllSearchResults: '(Select All Search Results)',
    searchOoo: 'Search...',
    blanks: '(Blanks)',
    noMatches: 'No matches',
     
    //...
    
}

The withGeneAgGridTranslations() DOC function can be used to enable localization mechanism on any AG Grid instance.

import { withGeneAgGridTranslations } from '@gene/widget-core';

// ...

let options: GridOptions;
let translateService: TranslateService;

// ...

withGeneAgGridTranslations(options, translateService);

Note: Developing with AG Grid library in your code requires to purchase an ag-grid enterprise license from www.ag-grid.com.

See www.ag-grid.com/javascript-data-grid/localisation for more information about ag-grid localization.

It is possible to use DOC error page component to display error messages using routing. In the frontend code raising the error change current location to /error/error/<error-code> where error-code is an integer greater than 100 (lower numbers are reserved for DOC) and if the translation file contains the string with the key COMPONENT.ERROR.MESSAGES.<error-code> it will be displayed on the error page.