Skip to Content

Changes for page 57

Last modified by Erik Bakker on 2023/01/23 13:58
From version 1.1
edited by Erik Bakker
on 2022/05/05 14:03
Change comment: There is no comment for this version
To version 9.1
edited by Erik Bakker
on 2022/06/16 12:48
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Building Time
1 +60
Parent
... ... @@ -1,1 +1,1 @@
1 -Main.Release Information.Portal.WebHome
1 +Main.Release Information.Build numbers.WebHome
Content
... ... @@ -1,33 +1,14 @@
1 -Version 175, released 2022-04-29
1 +Small update that fixes three specific issues.
2 2  
3 -Release that brings flow testing and JSON support improvements and a new build number with runtime bug fixes. In addition, this release includes several other improvements and tackles some minor issues. To benefit from the improvements, please make sure to clear your browser cache (Ctrl+Shift+Del) before signing in the first time.
3 +Find out more in our [release blog]
4 4  
5 -Find out more on our release blog here: [[https:~~/~~/www.emagiz.com/en/release-blog-en/175-building-time-release-blog/>>https://www.emagiz.com/en/release-blog-en/175-building-time-release-blog/]]
6 6  
6 +===== Bug Fixes =====
7 7  
8 -===== Major Changes =====
8 +* Build number 59 broke the debugger, build number 60 fixes this.
9 +* Fixed Kafka components not being able to use key- or truststores from the "resources" tab.
10 +* Deploying flows containing a 'Jetty server' support object in build number 59 only worked on the latest runtime version: build number 60 fixes the backwards compatibility with older runtimes. Note that it is still strongly recommended to update to the latest version of the runtime (5.0.4) if you haven't done so already, because this contains fixes for the Log4j security vulnerability.
9 9  
10 -* This release brings build number 61 with several runtime improvements.
11 -** The OAuth 2.0 authorization interceptor in the Rest Template component contained client 'Authentication methods’ that were invalid and caused a flow not to start in build 59. Also the clockskew is now configurable so we can handle the requirements of more oauth2 authentication providers.
12 -** The Amazon S3 authentication interceptor in the Rest Template component had a threading issue where the key would be invalid on heavy usage. The threading has been changed and is now behaving correctly.
13 -** In several flow designer components, you can add Groovy scripts. Since build 59 using FastStringUtils (JSON parsing) in Groovy scripts did not work.
14 -** For Gen3 runtimes we upgraded to Spring Boot 2.6.6 to bring the latest security patches.
15 -
16 -
17 17  ===== Minor Changes =====
18 18  
19 -* Create - Flow designer: Message Definitions: Added JSON Array support for JSON message definitions. Using this, you can have an array of simple values based on an entity.
20 -* Create - Flow testing: Flow testing has better support for components that use flow resources like groovy scripts or database initialization scripts.
21 -* Create - Flow testing: Flow testing was not compatible with flows that contain queued message channels.
22 -* Manage - Monitoring: We removed the obsolete statistics screens 'Channel statistics', 'Handler statistics', and 'Cloud statistics'.
23 -
24 -
25 -===== Bug Fixes =====
26 -
27 -* Design - Message Mapping: We fixed an issue where some warnings were showing as errors in right panel.
28 -* Create - Flow Designer: Improved transformation of JSON messages when 2 similar structures in the source message definition are mapped to the same structure in the output definition.
29 -
30 -
31 -===== Remarks =====
32 -
33 -* Mendix Runtime has been upgraded to Mendix 9.12.1.
14 +* Change of behaviour when incoming HTTP headers are mapped to message headers: Up to build 58 the values of incoming HTTP headers were only mapped to an array when it contained multiple values, otherwise the first (and only) value was automatically extracted and used for the message header. Since build 59 the values are always mapped to an array. While this makes the data type of the header more predictable - it is no longer dependent on the number of values a client was sending - it does mean that your SpEL expressions that were previously expecting single values need to now handle array values. In many cases this can be as simple as extracting the first array value like this: "headers.myHeader[0]".