Skip to Content
Last modified by Erik Bakker on 2026/07/14 13:59
From version 34.1
edited by Erik Bakker
on 2026/07/14 13:59
Change comment: There is no comment for this version
To version 1.1
edited by eMagiz
on 2022/11/21 15:46
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Impact upcoming runtime image
1 +Impact of Runtime image upgrades
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.ebakker
1 +XWiki.eMagiz
Content
... ... @@ -1,31 +1,63 @@
1 1  {{container}}{{container layoutStyle="columns"}}(((
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 is a more detailed overview of all functionality.
2 +In this microlearning, we will focus on the helping you to assess the impact of upgrading to new buildnumbers.
3 3  
4 -If you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
4 +Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
6 6  == 1. Prerequisites ==
7 7  
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"]]
8 +* Advanced knowledge of the eMagiz platform
9 +* Complete the microlearning that explains how to upgrade to a new buildnumber
9 9  
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 it will be included in our upcoming runtime image.{{/info}}
11 +== 2. Key concepts ==
11 11  
12 -== 2. Changes ==
13 +With buildnumbers we mean the piece of software that used by a flow to make it operational inside the runtime. Several eMagiz libraries are loaded together with the flow components XML into the runtime (Java container). In essence that means that a new buildnumber means the flow is technically speaking different from the previous buildnumber.
13 13  
14 -* We will update to run on Java 25.
15 -** If you are using custom SpEL expressions or Groovy scripts you could be impacted. Best course of action for now would be to identify these cases and if you have questions to contact us to discuss the best approach.
16 -* The grant type {{code}}password{{/code}} when using the OAuth interceptor to retrieve a token from an external IDP is **no longer** supported.
17 -** 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).
18 -* 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}}.
19 -** If you are using the default configuration, please verify whether the IDP allows you to request OAuth tokens using the Client secret basic option.
20 -* All data pipeline (Job) related functionality will be removed and can no longer be used.
21 -* The {{code}}ProxyWebServiceMessageSender{{/code}} support component will be removed.
15 +eMagiz works hard to limit the number of buildnumbers. The general approach for buildnumber is that these are backwards compatible, so the impact of moving to the next buildnumber poses a minimal impact and risk.
22 22  
23 -== 3. Key takeaways ==
17 +== 3. Assessing the impact of changing buildnumbers ==
24 24  
25 -* Validate whether the changes mentioned above are impacting any model you are responsible for.
19 +=== 3.1 Release notes & impact assessment ===
26 26  
27 -== 4. Suggested Additional Readings ==
21 +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.
28 28  
29 -* [[Release Information (Menu)>>doc:Main.Release Information.WebHome||target="blank"]]
30 -* [[Runtime Images (Navigation)>>doc:Main.Release Information.Runtime Images.WebHome||target="blank"]]
31 -)))((({{toc/}}))){{/container}}{{/container}}
23 +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 +
25 +**Example**
26 +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:
27 +
28 +* 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.
29 +* 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.
30 +
31 +**Impact**: review the runtimes that have flows with a Jetty component and ensure that matching buildnumbers are inside these runtimes for all flows.
32 +
33 +=== 3.2 Upgrade ===
34 +
35 +Use the designed options in eMagiz to upgrade the flows to the new buildnumber. See the relevant microlearnings for that.
36 +
37 +=== 3.3 Functional changes ===
38 +
39 +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.
40 +
41 +=== 3.4 Approach ===
42 +
43 +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.
44 +
45 +== 4. Assignment ==
46 +
47 +Take a look at the release notes in the eMagiz Portal to ensure you know where to look.
48 +
49 +== 5. Key takeaways ==
50 +
51 +* Keep as close to the latest buildnumber as possible for the entire environment
52 +* The best option is to have the entire environment run on the same buildnumber
53 +* A mix of buildnumbers in a runtime is not a good plan - conflicting behaviors may occur.
54 +* Read the release notes for builnumbers carefully to assess the impact - in case the impact is minimal proceed with the upgrade
55 +* Make the buildnumber upgrades planable so the release schedule takes these actions into account.
56 +
57 +== 6. Suggested Additional Readings ==
58 +
59 +If you are interested in this topic and want more information on it, please read the release notes provided by eMagiz
60 +
61 +== 7. Silent demonstration video ==
62 +
63 +There is no video available as this is more a theoretical microlearning.)))((({{toc/}}))){{/container}}{{/container}}