Skip to Content
Last modified by Erik Bakker on 2026/07/14 13:59
From version 3.1
edited by eMagiz
on 2022/11/22 09:23
Change comment: There is no comment for this version
To version 32.1
edited by Erik Bakker
on 2026/07/14 13:35
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Impact of Runtime image upgrades
1 +Impact upcoming runtime image
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.eMagiz
1 +XWiki.ebakker
Content
... ... @@ -1,65 +1,30 @@
1 1  {{container}}{{container layoutStyle="columns"}}(((
2 -In this microlearning, we will focus on the helping you to assess the impact of upgrading to new buildnumbers.
2 +As announced in our [[Release blog>>doc:Main.Release Information.Release Blogs.272 - Driven Datamodel.WebHome||target="blank"]] dated July 16th, 2026 we are hard at work updating our runtime code to the latest major version. Below you will see a more detailed overview of all functionality
3 3  
4 -Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
4 +If you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
6 6  == 1. Prerequisites ==
7 7  
8 -* Advanced knowledge of the eMagiz platform
8 +* For more general context read the following [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Lifecycle Management.advanced-lifecycle-management-impact-of-runtime-image-upgrades.WebHome||target="blank"]]
9 9  
10 -== 2. Key concepts ==
11 -
12 -With runtime image we mean the template that is used to create runtime specific images. That image is used to spin up docker containers and contains all required software components to let the docker container function properly. One of the key requirements is to load the required libraries that are used by flows of a runtime. A library in this context is a software component that performs a specific, often technical function in the eMagiz runtime. These libraries are Java based and different versions exist of these libraries.
10 +{{info}}Please note that the list shown below is subject to change. This means that additional changes can be added to this list. Once something is on this list you may assume that it will be included when we release our upcoming runtime image.{{/info}}
13 13  
14 -== 3. Assessing the impact of runtime images ==
12 +== 2. Changes ==
15 15  
16 -As mentioned the runtime image is a template which effectively means that all specific images that are created from this template. The template holds all latest software updates and libraries that the integration flows require. eMagiz follows the strategy to update these required libraries on a frequent basis to ensure vulnerabilities can be fixed quickly and new functionality is available on a needed basis. Furthermore, by having a single template available all runtime are operating on exactly the same software base across all eMagiz clients. This way, a single mix of libraries can be made available to the community that is tested properly and coherent. There can be no other mixes of
17 -
18 -
19 -
20 -
21 -=== 3.1 Release notes & impact assessment ===
14 +* We will update our code to Java 25.
15 +* The grant type {{code}}password{{/code}} when using the OAuth interceptor to retrieve a token from an external IDP is **no longer** supported.
16 +** If you are using this grant type please verify whether the IDP allows you to request OAuth tokens using one of the accepted grant types (preferably client credentials).
17 +* The default behavior of requesting an OAuth token from an IDP has changed. This means that the Client authentication method will default to {{code}}Client secret basic{{/code}} instead of {{code}}Client secret post{{/code}}.
18 +** If you are using the default configuration please verify whether the IDP allows you to request OAuth tokens using the option Client secret basic.
19 +* All data pipeline (Job) related functionality will be removed and can no longer be used.
20 +* The {{code}}ProxyWebServiceMessageSender{{/code}} support component will be removed.
22 22  
23 -These can be found [[here>>doc:Main.Release Information.Build numbers.WebHome||target="blank"]]. Once the release notes are properly read, assess the impact. This effectively means that the key notes around the model components can be used.
22 +== 3. Key takeaways ==
24 24  
25 -You see often a list of libraries that are updated, and when these are the only notes that means that the impact is slim to none. Then make sure to read the notes above around the model components touched. These will help to asses the impact. Some model components have additional capability, and some have a limited capability or a fix.
24 +* Validate whether the changes mentioned above are impacting any model you are responsible for.
26 26  
27 -**Example**
28 -Flows containing a Jetty server (support object), primarily used to host REST and SOAP web services, require some special attention when deploying because not all combinations of build number 50 (and higher) and 48 (and lower) flows will work correctly:
26 +== 4. Suggested Additional Readings ==
29 29  
30 -* After installing any build 50 (or higher) flow, build 48 (or lower) flows containing a Jetty server on the same runtime cannot be started anymore. If it is really necessary to still install/start a build 48 (or lower) Jetty server flow: uninstall all build 50 (or higher) flows on that runtime first, then install/start the build 48 (or lower) Jetty server flow, and finally re-install the build 50 (or higher) flows.
31 -* When deploying a flow containing a Jetty server, the infra flow of that runtime must have a matching build number, that is: if the the Jetty server flow is build 48 (or lower) the infra needs to be build 48 (or lower) as well, if the Jetty server flow is build 50 (or higher) the infra needs to be 50 (or higher) as well.
32 -
33 -**Impact**: review the runtimes that have flows with a Jetty component and ensure that matching buildnumbers are inside these runtimes for all flows.
34 -
35 -=== 3.2 Upgrade ===
36 -
37 -Use the designed options in eMagiz to upgrade the flows to the new buildnumber. See the relevant microlearnings for that.
38 -
39 -=== 3.3 Functional changes ===
40 -
41 -Before an environment is updates to the flows with the latest releases, it is adviced to first check which flows have functional changes. These flows need to be tested and put into production first so that you can isolate issues in case they occur. Once these flows are tested and live, only then move the flows with the new buildnumbers from test to production.
42 -
43 -=== 3.4 Approach ===
44 -
45 -It is usually best to update the test and acceptance environment first and leave that running for a certain grace period. So that in case potential issues can be fixed still.
46 -
47 -== 4. Assignment ==
48 -
49 -Take a look at the release notes in the eMagiz Portal to ensure you know where to look.
50 -
51 -== 5. Key takeaways ==
52 -
53 -* Keep as close to the latest buildnumber as possible for the entire environment
54 -* The best option is to have the entire environment run on the same buildnumber
55 -* A mix of buildnumbers in a runtime is not a good plan - conflicting behaviors may occur.
56 -* Read the release notes for builnumbers carefully to assess the impact - in case the impact is minimal proceed with the upgrade
57 -* Make the buildnumber upgrades planable so the release schedule takes these actions into account.
58 -
59 -== 6. Suggested Additional Readings ==
60 -
61 -If you are interested in this topic and want more information on it, please read the release notes provided by eMagiz
62 -
63 -== 7. Silent demonstration video ==
64 -
65 -There is no video available as this is more a theoretical microlearning.)))((({{toc/}}))){{/container}}{{/container}}
28 +* [[Release Information (Menu)>>doc:Main.Release Information.WebHome||target="blank"]]
29 +* [[Runtime Images (Navigation)>>doc:Main.Release Information.Runtime Images.WebHome||target="blank"]]
30 +)))((({{toc/}}))){{/container}}{{/container}}