Wiki source code of Cleanup a running flow

Last modified by Erik Bakker on 2024/02/23 08:52

Show last authors
1 {{container}}{{container layoutStyle="columns"}}(((
2 In this microlearning, we will focus on the part of the lifecycle management where you need to clean up a flow that is active on a runtime at the moment when the integration needs to be removed. It involves complexity in a sense that flow needs to be removed from the Deploy phase. Before it can be removed from the Create phase and further.
3
4 Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5
6 == 1. Prerequisites ==
7 * Advanced knowledge of the eMagiz platform
8
9 == 2. Key concepts ==
10 The most important for this microlearning to understand is that a flow needs be removed from the Deploy phase before it can be removed from the integration model that is in Capture, Design and Create. Removing a flow from the model before removing it from Deploy results in "ghost" flows that result in unexpected behavior in the Deploy phases.
11
12 == 3. Steps to remove a flow from Deploy ==
13
14 === 3.1 Remove from all releases ===
15
16 1. Remove the flow from the active release by creating a new release and deselecting the integration.
17 2. Once deselected make sure that the new release is deployed on all your environments.
18 3. Remove all old releases that still have a reference to the flow.
19
20 === 3.2 Remove unused Properties ===
21 Ensure to remove the associated properties from each TAP environment specific to this flow. Refer to the [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Lifecycle Management.intermediate-lifecycle-management-cleanup-properties-gen3.WebHome||target="blank"]] that explains that process.
22
23 === 3.3 Remove alerting triggers ===
24
25 Within this Tab navigate to Triggers (look at the Tag name when following these instructions). If you have configured the alerting following the best practice outlined in the user guide for Alerting, the following triggers (at least!!!) need to be changed. For your specific situation more triggers could be relevant
26 * Standard – Queue consumers too high
27 * Standard – Queue consumers too low
28
29 If you are removing the last flow belonging to a system and you have followed the best practice outlined here the following triggers (at least!!!) need to be changed. For your specific situation more triggers could be relevant
30
31 * Standard – Data measurements missing
32 * Standard – Log entries missing
33 * Standard – Error log entry
34
35 === 3.4 Remove from all Releases ===
36 The key to understand is that the flow to be removed needs to be removed from all the releases in the 3 environments test, acceptance and production. In most cases, it means that a new (series of) release(s) needs to be created and made active in each environment. Older releases can be removed so that no release has this flow included. Once that is achieved, then the flow is removed from the Deploy phase.
37
38 It usually means that it will take a certain grace period before a flow is actually out of Deploy.
39
40 == 4. Key takeaways ==
41
42 * A flow needs to be removed from all releases before it can be removed from Create - see specific micro-learning for that purpose
43 * Don't forget to clean the Manage phase with Alert triggers, and the properties from Deploy
44
45
46
47 == 5. Suggested Additional Readings ==
48
49 If you are interested in this topic and want more information on it, please read the release notes provided by eMagiz
50
51 )))((({{toc/}}))){{/container}}{{/container}}