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 4.1
edited by eMagiz
on 2022/11/22 12:42
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,56 @@
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 to create runtime specific docker 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.
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 docker 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 mix of software components that behave each differently.
17 +
21 21  
22 -== 3. Key takeaways ==
19 +=== 3.1 Overal deployment strategy ===
23 23  
24 -* Validate whether the changes mentioned above are impacting any model you are responsible for.
21 +At the moment when a release is set as active, the runtime image will be used to create specific runtime images that are used to deploy Docker containers. Effectively that means that for every release, a specific docker image is created and that docker image will be used at the moment when the deployment plan is run. That also means that at each and every deployment, all docker containers will be replaced with a new docker container based on that docker image created of the release.
25 25  
26 -== 4. Suggested Additional Readings ==
23 +=== 3.2 Release notes & impact assessment ===
24 +
25 +Release notes for runtime images can be found [[here>>doc:Main.Release Information.Runtime Images.WebHome||target="blank"]]. Please consult these at regular basis or at the moment when unexpected behavior is observed.
26 +
27 +=== 3.2 Disaster recovery runtimes ===
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}}
29 +In very specific cases, a runtime may not function properly after a specific release is done. That means that the flows in that runtime are not 100% compatible with the runtime image used to create the docker images from. This may happen in cases when there hasn't been a deployment for many months, and the new runtime images will contain large changes. Effectively that means that the Runtime Image as delivered by eMagiz is incompatible with the flows in that runtime. And action is needed on eMagiz side to update the runtime image. This situation is expected to be very expectional.
30 +
31 +Whenever this situation occurs, a user can navigate to the Deploy architecture of the model. The details of the specific runtime (right-click option) can be opened and a release can be selected. That release should be the previous release where the runtime was operating normally. Once selected, press Save and choose the Deploy Runtime option (right-click option) on machine level. This will force that specific runtime to load the previous docker image.
32 +
33 +
34 +=== 3.4 Approach ===
35 +
36 +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.
37 +
38 +== 4. Assignment ==
39 +
40 +Take a look at the release notes in the eMagiz Portal to ensure you know where to look.
41 +
42 +== 5. Key takeaways ==
43 +
44 +* Keep as close to the latest buildnumber as possible for the entire environment
45 +* The best option is to have the entire environment run on the same buildnumber
46 +* A mix of buildnumbers in a runtime is not a good plan - conflicting behaviors may occur.
47 +* Read the release notes for builnumbers carefully to assess the impact - in case the impact is minimal proceed with the upgrade
48 +* Make the buildnumber upgrades planable so the release schedule takes these actions into account.
49 +
50 +== 6. Suggested Additional Readings ==
51 +
52 +If you are interested in this topic and want more information on it, please read the release notes provided by eMagiz
53 +
54 +== 7. Silent demonstration video ==
55 +
56 +There is no video available as this is more a theoretical microlearning.)))((({{toc/}}))){{/container}}{{/container}}