Breaking Changes

You will find all breaking changes for the major and minor releases below.

License Control

• Implementation of a License Control, starting with version 10.0:

  • Differentiation between named and concurrent user

  • Differentiation between PRODUCTION, TEST, and PROVISION (trial) system with the control of an expiration date

  • Later and step by step: Control of functions like Import/Export (ETL), Signing, OCR, ...

Localization

• Beginning with version 10.6: In the past, the localization of labels, error messages, and audit information was handled on the core-service side. Step by step, most of these items have to be configured on the client side. With the next step the basis parameters like title, description, created, modified, creator, modifier, etc. are no longer handled on the core-service side.
  Therefore, basis parameter labels on the client side must be localized within the <language iso code>.json files (e.g. ja.json).

• CSV Export

  • Beginning with version 10.8: The client requests the search-service for the CSV export with a list of the fields and their labels concerning the language the user has configured.

  • Attention: If a CSV export is requested via search API, keep in mind that the column labels are only in English if the fields are not explicitly listed in the payload. The list of fields controls the column sequence in the CSV file. The value of the fields contains the qualified name of the field (object type property) followed by the label (all characters after the first space). If no label is given, the technical name is used for it.
    Used endpoint of the search API: http://mydomain.de/search/export

    { "types": [ "personaldossier" ], "options": { ... }, "fields": [ "type Type", "personaldossier.dateofdeployment Date of employment", "personaldossier.class Class", "personaldossier.firstname First name", "personaldossier.surname Family name", ... "created Created", "creatortitle Creator", "modified Edited", "modifiertitle Editor" ] }

BPM-Scripting

• In yuuvis® RAD version 8 LTS, the BPM-Scripting API call "$.history.createEntry" was deprecated by a new method "$.history.addEntry".
  The deprecated method is removed with version 10.0.

• The script engine is running in strict mode, so some of the errors that were previously present in scripts (and were ignored by the engine) are now visible.

  • If a read-only property of an object belonging to the workflow scripting API is changed, an exception will be thrown. In previous versions, it would appear as if they could obtain a new value, but when saving the state of properties, they would not be saved. 

    • This change in particular affects manipulation of performers in scripts, where old examples were using read-only fields in an improper manner.

    • We have introduced a new approach to obtain the correct OrgObject (with method getObjectById() ), details can be found in How to Update/Upgrade 10.x. 

  • Use of undeclared variables results in an error. This is a frequent issue in Javascript that does not run in strict mode and is typically caused by a typo (either a name of a previously declared variable is mistyped, or var declaration is forgotten). The issue is corrected by using the correct name, or by properly declaring the variable.

Client

• Custom clients must be upgraded to Angular 17 because the client has been updated to this framework version. See this documentation for building a custom client as well: Getting Started

  • Outlook: Another upgrade step to Angular 18 is planned for version 10.8.

• The Task list widget has been refactored and face-lifted. The old version saved the list data in the local browser storage, so the data was not available on other workstations.
  The new widget saves the data centrally. However, the old data will get lost.

• In a client form-script, it is possible to check with row.persisted whether a row existed or not when the onchanged event was fired. But row.persisted gave the wrong false or true value for the current situation. Now this is corrected, so it is necessary to change the affected scripts and negate your logic.

• The widget configuration has been extended and improved. This may cause that some of the existing configurations from 9.16 are no longer valid, an error is shown and the user should reconfigure the affected widget so that a new configuration is applied.

• It was necessary to change the table behavior of the object reference aspect from grouped objects to a flat list of objects.

• Beginning with version 10.6, the core-service no longer offers localisation of the system-specific basis parameters like type, title, description, version etc. Now, these parameters are part of the client localisation files. If additional language files other than the standard en.json and de.json are in use, these files have to be extended with the basis parameters. See the description in the update steps.

• Beginning with version 10.12, the user experience of searching for ‘Without value’ is changed. Instead of clicking the form field label, the new operator ∅ is introduced.

Core-service API

• Introduction of the new feature in process development that allows modeler to exclude certain users, roles, and groups from participation in a workitem has caused the following API changes: 

  • GET  /bpm/process/processId/activity/activityId/performer has new response format that lists exclusions as well.

    • GET /bpm/process/{processId}/activity/{activityId}/inboxitem has been extended to contain excluded members (https://jira.optimal-systems.de/browse/ERA-9010), but there are no breaking changes (users of the endpoint may decide to use this new information).

  • PUT /bpm/process/{processId}/activity/{activityId}/performer has been changed (https://jira.optimal-systems.de/browse/ERA-9796).

    • Its payload structure has been changed to allow adding of both performers and performers.exclusions.

    • It can only add performers and performers.exclusions to the existing list (up to version 9.16 it was possible to replace the whole configuration if parameter "replace" is set to "true").

  • POST /bpm/process/{processId}/activity/{activityId}/performer has been added to replace the complete performer- and performer.exclusions-configuration.

    • It uses the same payload structure as GET and PUT endpoints.

• GET /bpm/process/<processId>/history has a new optional parameter "includeData" that controls the size of its response.

  • The parameter is "false" by default.

  • If the includeData parameter is not set or set to "false" the data object (containing all variables and its values for every history entry) is not written into response.

  • If the includeData parameter is set to true, the data object containing the variables will also be returned.

Service-Infrastructure

signing-service

Beginning with version 10.10 the signing-service uses the new Elasticsearch API instead of the yuuvis® RAD search API. After the update, it is necessary to adjust the servicewatcher-sw.yml for the signingservice section. "es" must be added to the profile.

repository-manager

The repository-manager is replaced by two new SAP^®-certified microservices, RMALINK service for SAP^® ArchiveLink and RMILM service for SAP^® ILM. Manual configurations are necessary. (internal: TUK-5306)
Please read the information about the update steps: How to Update/Upgrade 10.x

Deprecated Features

You will find all deprecated features for the major and minor releases below.

10.0

• Qlik, the new owner of Talend Open Studio has discontinued it from January 31st, 2024.
  For this reason, we are forced to deprecate the Talend connectors for yuuvis® RAD but we will continue to offer support in form of bug fixes in yuuvis® RAD version 10.0.

• In BPM-Scripting API, the class "Variable" has been deprecated and we recommend using the new class "Datafield" instead. It is similar to the deprecated class "Variable" but offers a simpler and more consistent API when working with complex data types (e.g., lists of lists).
  Details and examples can be found in BPM-Scripting API documentation in core-service. It is allowed to use "Datafield" and "Variable" classes in different scripts of the same workflow model, but not to mix them in the same script. This also means that if the model's global script was adjusted to use the class "DataField" instead of "Variable", it must be ensured that other scripts calling affected global script methods are adjusted, too. And vice-versa: if global script uses the class "Variable", then its client should also use the class "Variable".