Skip to Content

Wiki source code of eMagiz Runtime Generation 3

Last modified by Martijn Woudstra on 2022/10/25 13:30
Hide last authors
Martijn Woudstra 65.1 1 {{container}}{{container layoutStyle="columns"}}(((
2 Below you will find a document describing the migration path to migrate a single runtime (i.e., connector or container) to the latest generation runtime. Note that this functionality is not yet generally available and can only be executed after consulting your partner manager. For the key aspects of the new generation compared to the current generation, please read this [[fundamental>>doc:Main.eMagiz Academy.Fundamentals.fundamental-runtime-generation3.WebHome||target="blank"]].
3
4 Should you have any questions, please get in touch with academy@emagiz.com.
5
6 == 1. Prerequisites ==
7
8 * Advanced knowledge of the eMagiz platform
9 * A thorough understanding of your eMagiz model
10
11 == 2. Key concepts ==
12
13 * This migration path allows you to migrate a specific runtime to Generation 3
14 * All flows of the runtime are updated, so plan your migration
15 * The JMS needs to be migrated to Generation 3 as the last runtime of your model
16 * When executing the first migration of a runtime, additional steps are necessary to update your cloud configuration
17 * In case you want to use the new EDI functionality in messaging, both the connector and the process container need to be migrated to Generation 3
18
19 == 3. Migration Scenarios ==
20
21 As migrating to the latest generation runtime impacts your model, it is advisable to consider various scenarios when migrating. In broad terms, there are two scenarios with which you can migrate. The first scenario is a scenario we will call "Big Bang." In this scenario, you will migrate your complete model at once. The second scenario we will discuss is called "Gradual Improvement." In this scenario, you will migrate parts of your model in a larger time frame.
22
23 Before diving into both scenarios and outlining the pros and cons, let us first look at the current limitations of the new generation runtime that might impact your choice regarding which method to choose.
24
25 === 3.1 Known Limitations ===
26
27 The list below shows functionality not yet tested or migrated to work on the Generation 3 runtime. Take this list into account when determining when and how to migrate.
28
29 * Message redelivery
30 * Code Mappings
31 * Smooks components
32 * XSL-FO (PDF Generation)
33 * WS-Security
34 * eMagiz Mendix Connector
35 * Dynamic Alerting
36 * Using "Batch" components (i.e., Data Pipeline)
37 * Hosting a SOAP web service
38 * Hosting a REST web service
39 * Hosting an ODATA web service
40
41 === 3.2 "Big Bang" ===
42
43 As the name of the scenario suggests, this scenario is designed to migrate your complete model at once. As a result, you can (quickly) execute the steps outlined in Chapter four in one go.
44
45 {{info}}
46 We advise this scenario for models on which no significant development is taken place.
47 {{/info}}
48
49 ==== 3.2.1 Advantages ====
50
51 * The migration path can be executed efficiently as you migrate all runtimes in one iteration
52 * Your user experience won't be clouded by the fact that part of your solution runs the 'old' architecture and the other part runs in the 'new' architecture
53 * The duration of the complete migration path from start to finish is limited as you migrate everything at once, and therefore you can move through the environments at a faster pace
54
55 ==== 3.2.2 Disadvantages ====
56
57 * As you migrate everything at once, you need a period of roughly 2-3 weeks in which no functional changes can happen on your model
58 * Everything needs to be tested at once
59 * If part of your model cannot yet be migrated, you need to wait until the complete model can be migrated before you can execute this scenario barring you from unlocking other new features that are only available on the new runtime architecture.
60
61 === 3.3 "Gradual Improvement" ===
62
63 As the name of the scenario suggests, this scenario is designed to migrate your model gradually. As a result, you can (efficiently) execute the steps outlined in Chapter four in a phased manner.
64
65 {{info}}
66 We advise this scenario for models in which significant development is taken place.
67 {{/info}}
68
69 ==== 3.3.1 Advantages ====
70
71 * By migrating gradually, you can migrate parts of your model earlier, unlocking new features of the runtime architecture but still keeping others in the current runtime until functional changes are done or limitations removed.
72 * You can incrementally test only those static parts of your solution that you want to migrate.
73 * Only the part you want to migrate cannot contain functional changes.
74
75 ==== 3.3.2 Disadvantages ====
76
77 * You need to migrate parts of your model over a more considerable amount of time (i.e., 2-3 months), meaning that you continuously need to be aware of how to migrate from the old to the new situation.
78 * During the time you run on both architectures, your user experience will be dual in nature, especially in Manage. This means that part of your metrics, logging, and error messages are shown differently per runtime.
79 * By dragging out the migration over a long period, you risk that the migration takes such a long time that you are forced to migrate in a hurry at some point in time
80 * You continuously need to be aware of the order via which you need to migrate (especially surrounding the JMS migration).
81
82 == 4. Technical Migration Path ==
83
84 {{warning}}Each of the steps detailed below need to be executed per runtime with the exception of the steps that explicitly state they should be executed once.{{/warning}}
85
86 Below you will find a document describing the migration path to migrate a single runtime (i.e., connector or container) to the latest generation runtime. Note that this functionality is not yet generally available and can only be executed after consulting your partner manager. For the key aspects of the new generation compared to the current generation please read this [[fundamental>>doc:Main.eMagiz Academy.Fundamentals.fundamental-runtime-generation3.WebHome||target="blank"]].
87
88 === 4.1 Update Design Architecture ===
89
90 The first step of this migration path is to update a part of your Design Architecture. In this update step, you will define on runtime level (i.e., connector or container) whether a runtime is a generation 3 runtime or not.
91
92 [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--define-generation-in-design-architecture.png]]
93
94 Note that we have provided an extensive help text to support you in your choice of whether to migrate to Generation 3 or not. You can read the help text by pressing the information icon on the popup and selecting the Gen3 option.
95
96 [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--helptext-generation-in-design-architecture.png]]
97
98 === 4.2 Transfer Settings from Design ===
99
100 Now that we have indicated that a certain runtime needs to be migrated to Generation three, the next step is Create. In Create navigate to Settings -> Transfer Settings From Design -> Container. Here you will see all runtimes designed to be generation 3 in Design but are still configured as generation 2 in Create.
101
102 [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--transfer-settings-from-design-overview.png]]
103
104 When you press the button "Transfer Gen3 state from Design", eMagiz will automatically migrate your environment to the latest generation and update all your flows accordingly. This means that each flow will get a new version number which we need to deploy in a later phase.
105
106 On top of that eMagiz will change the default behavior of how the error handling is done within eMagiz flows. When migrating you will have the option to select for which flows you want to keep your custom error handling.
107
108 [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--transfer-settings-from-design-custom-error-handling.png]]
109
110 For more information on migrating your custom error handling towards the 3rd generation runtime please see this [[migration path>>doc:Main.eMagiz Support.Migration Paths.migration-path-custom-error-handling-runtime-generation-3.WebHome||target="blank"]]
111
112 === 4.3 Create a new release ===
113
114 After the migration is finished, eMagiz will have created new versions of all flows on the runtime you just migrated. The next step would be to include these changes in a new release so they can be deployed. After adding the new flow versions to the release, ensure the release is "set as active."
115
116 {{info}}Make sure to also include flows you cannot select visually (for example the infra flow).{{/info}}
117
118 === 4.4 Update Deploy Architecture ===
119
120 ==== 4.4.1 Update Cloud Template - One Time Action ====
121
122 For the first runtime, you migrate to Generation 3; you need to ensure that the correct cloud template is selected on which the Generation 3 runtimes can function. This is the latest Docker template available at the moment of your migration. Note that upgrades of new cloud templates will be automated after this moment, just as you are used to within eMagiz. As an alternative, you can also execute the updates manually if needed.
123
124 To update your cloud architecture, press "Apply to Environment" in Deploy Architecture.
125
126 {{info}}Note that you need to be in "Start Editing" mode to execute this command.{{/info}}
127
128 ==== 4.4.2 Update A Subsequent Runtime ====
129
130 Apart from updating the cloud template itself, you also need to update each runtime so it will run on Generation 3. To apply the changes from Design Architecture to Deploy Architecture, you need to press the button "Apply to Environment" just as you would now if you add or change a runtime in the current architecture.
131
132 [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--apply-to-environment.png]]
133
134 {{info}}Note that this update will be included the first time when you update the cloud template.{{/info}}
135
136 === 4.5 Verify whether runtime started ===
137
138 There are two mechanisms to verify whether the runtime started up correctly. Below you can find more information on these mechanisms.
139
140 ==== 4.5.1 Verification in Deploy Architecture ====
141
142 The first check can be done in Deploy Architecture itself. Here you can access the context menu on the runtime level and open the Details page of the runtime.
143
144 [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--runtime-context-menu.png]]
145
146 Once you have opened the Details overview, you will see a second tab called "Status". On this tab, you can see the "Status" of the runtime and execute several commands on the runtime level when in "Start Editing" mode.
147
148 [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--status-tab.png]]
149
150 You can also define which release version is running on this runtime by looking at the last part of the image name. This part holds a reference to the release version. In this example, the release version is 7.2.1
151
152 ==== 4.5.2 Verification in Manage ====
153
154 On top of this verification, you can check the Log Entries in Manage to see whether your runtime successfully started up. Here you can search for the key phrase "Started eMagiz" to see which runtimes have been started (or you can filter on a specific runtime).
155
156 [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--log-entries-started-emagiz.png]]
157
158 === 4.6 Update Deployment Plan ===
159
160 Note that the way each runtime is deployed is changed in Generation 3. This also means that your deployment plan changes as well. For example, instead of deploying on a flow-by-flow basis, we will package the whole runtime in one image and deploy that to the machine. Therefore new steps have been added to the deployment plan to deploy changes on your machine. For example, the first time you introduce a Generation 3 runtime on a machine, you need to add a Deploy Machine step to the deployment plan and remove all actions referencing the runtime you just migrated. An example of what this looks like can be seen below.
161
162 [[image:Main.Images.Migrationpath.WebHome@migration-path-migration-path-emagiz-runtime-generation-3--deployment-plan-example.png]]
163
164 == 5. Key takeaways ==
165
166 * This migration path allows you to migrate a specific runtime to Generation 3
167 * All flows of the runtime are updated, so plan your migration
168 * The JMS needs to be migrated to Generation 3 as the last runtime of your model
169 * When executing the first migration of a runtime, additional steps are necessary to update your cloud configuration
170 * In case you want to use the new EDI functionality in messaging, both the connector and the process container need to be migrated to Generation 3
171
172 )))((({{toc/}}))){{/container}}{{/container}}