Breaking Changes / Deprecated Features 10.x

 

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, ...

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

  • 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 you need to change your script and negate your logic.

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.

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 "Variables" but offers a simpler and more consistent API when working with complex data types (for instance, 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".