Digest 7.16

Owned by Mr. Schmittberger
Last updated: Apr 28, 2022 by Team Kolibri (Unlicensed)
3 min read

Addendum

The potential security issue that was reported for the Postgres database under CVE-2022-21724 is fixed by updating the JDBC driver to version 42.3.3 for core-service and service manager (bpm-service / inbox-service) 7.16.17. 

Extraction

The extraction-service supports invoices in PDF format. This includes the XML file based on the ZUGFeRD version 2.1.1 format (similar to ZUGFeRD version 1.x).

Breaking Change

We have corrected a typo in the properties. Some properties contained the wrong spelling 'aggreement'. In the future, it will be correctly spelled as 'agreement'.

Action: If you have used a property of the old form for mapping, you need to adapt your mapping.

Infrastructure

Context Path

When installing the system, a customized context path can be defined which deviates from the standard, and under which the services will be available.

For example, the URL for the client can look like this: https://mydomain/myContextPath/app/client/

Authentication via OAuth2

The system supports OAuth2 as an authentication method. You need Keycloak as a proxy for LDAP-based Identity Providers that maintain the common user data. Nevertheless, the users of this LDAP system must be synchronized with yuuvis® RAD.

yuuvis® RAD agent, which connects the client with Windows applications, has been adapted as well to support OAuth2.

Sharing Objects

The endpoint that allows to share folders and objects has been adapted. Now you can define whether all children of a folder should be shared or not. The current default is to share all objects assigned to the folder. In specific circumstances, you may not want to share them all.

Upcoming Update of the Workflow Scripting Engine

Starting with version 8, our workflow engine will switch from the Nashorn Script engine to the newer GraalVM engine. The new engine brings full support for the ECMAScript2 specification.

Since the Nashorn engine pre-dates the ECMAScript21, we recommend to test existing worfklow models prior to upgrading to version 8, and if necessary, the syntax of scripts to be updated to the new standard. 
This is to be executed only in development/test systems as a preparation for migration to yuuvis® RAD 8, since GraalVM is not yet officially supported in yuuvis® RAD 7.16 LTS and should not be used in productive systems.

In order to test the new script engine, the core-service has to be started with the following parameter:

-Dcom.os.ecm.workflow.scriptEngineType=GraalVM

The Nashorn engine is used, regardless of the core-service having been started with the -Dcom.os.ecm.workflow.scriptEngineType=Nashorn or without it. 

Deprecated Methods in $.http in Workflow Scripts

Until version 7.16 LTS, $.http has been giving access to the singleton class HttpClient. On this singleton, an HTTP request could be configured and executed. As HttpClient is implemented as a singleton, all functions of this class are modifying the very same HTTP request. This semantic is error-prone because configurations of sequential HTTP requests could easily get mixed up unintendedly.
To improve this, the new HttpRequest class has been introduced. Instances of this class allow configuration and execution of HTTP requests. Multiple instances of HttpRequest can be created using functions like get() or post() of the HttpClient singleton.

  • The following methods in the HttpClient class (accessible by the $.http object) are deprecated:
    • service()
    • path()
    • raw()
    • header()
    • param()
    • query()
    • body()
    • clear()
    • execute()
  • Starting with version 7.16 LTS the HttpRequest class is introduced in workflow scripting.
    • Instances of HttpRequest can be created using these functions of the $.http object: get(), post, put, delete, patch.
    • Instances of HttpRequest offer the following methods that are deprecated on HttpClient, such as service(), path(), body(), etc.

Both approaches are supported in version 7.16 LTS 

  • It is recommended to use the new class to configure and execute HTTP requests from version 7.16 LTS on
  • Starting with version 8.0 and later, this will be the only supported approach

HttpClient example (prior to 7.16 LTS)

this.$.http.get();
this.$.http.path("/service/organization/role/{id}").param("id", roleId); //This configures the http singleton. These methods on $.http are deprecated for removal in 8.0
var response = this.$.http.query("orgobjects", true).execute(); // This executes the singleton HttpClass.
HttpRequest example (from 7.16 LTS onwards)
var getRequest =this.$.http.get(); //This creates a new request instance.
var response = getRequest.path("/service/organization/role/{id}").param("id", roleId).query("orgobjects", true).execute(); //Configuration is executed on the getRequest object, no longer on the $.http singleton
//The methods for request instance configuration can be safely used in 7.16 LTS and onwards.

Changes in the Response Format of BpmProcessService.getDataFields due to a Bugfix

Due to a bugfix (ERA-8384 - Model datafields of type List<ID> are returned in wrong format), the format of the response body of the BpmProcessService.getDataFields endpoint changed. 

Up to version 7.14, the service delivered the IDs in the wrong format (for instance "l_workflowFileIds.item: OsId[id=97DC54B56A844F9EBB198935476F15B5]"), so the response format has been corrected (for the same example, the response would be "l_workflowFileIds.item: 97DC54B56A844F9EBB198935476F15B5").

Custom microservices that use this endpoint need to adapt to this change before updating to version 7.16.