Skip to Content
Last modified by Erik Bakker on 2026/07/14 13:59
From version 32.1
edited by Erik Bakker
on 2026/07/14 13:35
Change comment: There is no comment for this version
To version 2.1
edited by eMagiz
on 2022/11/21 15:56
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,30 +1,65 @@
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 you will see 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 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 that it will be included when we release our upcoming runtime image.{{/info}}
10 +== 2. Key concepts ==
11 +
12 +With runtime image we mean the template that is used when creating 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 that are part of that runtime.
11 11  
12 -== 2. Changes ==
14 +== 3. Assessing the impact of runtime images ==
13 13  
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.
16 +As mentioned the runtime image is a template which effectively means that all specific images that are created
17 +
18 +
19 +
20 +
21 +=== 3.1 Release notes & impact assessment ===
21 21  
22 -== 3. Key takeaways ==
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.
23 23  
24 -* Validate whether the changes mentioned above are impacting any model you are responsible for.
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.
25 25  
26 -== 4. Suggested Additional Readings ==
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:
27 27  
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}}
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}}