Skip to Content
Last modified by Waria on 2026/07/23 09:38
From version 22.1
edited by Waria
on 2026/07/23 09:38
Change comment: There is no comment for this version
To version 6.1
edited by Erik Bakker
on 2022/06/13 08:18
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Key differences Design & Deploy Architecture
1 +Edit memory for on-premise runtime (Linux)
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.waria
1 +XWiki.ebakker
Content
... ... @@ -1,78 +1,85 @@
1 -{{container}}
2 -{{container layoutStyle="columns"}}
3 -(((
4 -In this microlearning, we’ll explore the differences between the Design Architecture and Deploy Architecture within eMagiz. While the Design Architecture is where integration models are initially structured and systems are assigned to either Cloud or on-premises machines, the Deploy Architecture is where these designs are brought to life. However, not all systems in the Design phase will appear in the Deploy phase due to their specific configurations. Understanding these key differences will help you better manage and implement your integration architecture effectively.
1 +{{container}}{{container layoutStyle="columns"}}(((
5 5  
6 -Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
3 +Sometimes you have runtimes running on*premises. What we mean by that is that the runtimes are running within a data center of the customer instead of running in the eMagiz Cloud. For running a runtime on*premise we support running them on either Windows or Linux as the operating system. In this microlearning, we will learn how you can edit the memory settings of a runtime that is deployed on*premise on Linux.
7 7  
8 -== 1. Prerequisites ==
5 +Should you have any questions, please contact academy@emagiz.com.
9 9  
10 -* Intermediate knowledge of the eMagiz platform
11 -* Good working experience in the Design & Deploy architecture aspects
7 +* Last update: April 5th, 2022
8 +* Required reading time: 5 minutes
12 12  
10 +== 1. Prerequisites ==
11 +* Basic knowledge of the eMagiz platform
12 +
13 13  == 2. Key concepts ==
14 +This microlearning centers on editing the memory settings for an on*premise runtime that is running on Linux. With an on*premise runtime we mean: A runtime that is running within a data center of the customer instead of running in the eMagiz Cloud
14 14  
15 -The Design Architecture is the place where the architecture of the integration model is forged. It allows to place Systems to Cloud or On-premises connector machines so that hybrid cloud architectures are possible. The Deploy Architecture is the place where the Design architecture is effectuated. In case a system is added to a Cloud Connector machine for instance, the Deploy architecture will allows to actually deploy that runtime.
16 +The focal point of this microlearning will be to learn how you can safely edit the memory settings for an on*premise runtime running on Linux
16 16  
17 -== 3. Key differences in views Deploy & Design ==
18 +* The key aspects are:
19 + ** eMagiz can help you determine the correct size you need to configure via Design *> Architecture
20 + ** You need access to the on*premise location to perform the action
21 + ** Only change the wrapper.conf file. Nothing else
18 18  
19 -The System is the key notion for a eMagiz runtime to get created. The eMagiz runtime is a Java based application container in which flows can be made active or operational. In most cases, all Systems in Design are to be located on a machine to effectuate these runtimes on the machines.
23 +== 3. Edit memory for on*premise runtime (Linux) ==
20 20  
21 -However, in some cases the Deploy architecture looks different compared to the Design architecture. In a sense that some system don't get "created" in Deploy. These are the reasons for Systems not to appear in Deploy architecture:
25 +Sometimes you have runtimes running on*premises. What we mean by that is that the runtimes are running within a data center of the customer instead of running in the eMagiz Cloud. For running a runtime on*premise we support running them on either Windows or Linux as the operating system. In this microlearning, we will learn how you can edit the memory settings of a runtime that is deployed on*premise.
22 22  
23 -* System is only used for API Gateway Access
24 -The system acts as a user, and no other integrations are used to and from that system. You can recognize the blue lines with blue rounded boxes containing the number of operations. These systems will be displayed in Design yet not in Deploy architecture. No runtime application is needed as no flows are supposed to run inside these systems. This works the same for multi-tenant systems (with tenants being the users). Below an example of such a case:
27 +The focal point of this microlearning will be to learn how you can safely edit the memory settings for an on*premise runtime.
25 25  
26 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-1.png]]
29 +* The key aspects are:
30 + ** eMagiz can help you determine the correct size you need to configure via Design *> Architecture
31 + ** You need access to the on*premise location to perform the action
32 + ** Only change the wrapper.conf file. Nothing else
27 27  
28 -* System that is used only for Event Streaming integrations
29 -The same applies to systems that are displayed for registering Producers and Consumers for Event Streaming. These systems are not displayed in Deploy Architecture.
34 +=== 3.1 Check adviced size ===
30 30  
31 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-2.png]]
36 +Within Design Architecture you can see for each connector runtime what the advised sizing of eMagiz is based on how you have configured your integration data model. To do so navigate to Design *> Architecture and open the context menu on connector runtime level via a right mouse click.
32 32  
33 -* Systems accessed via Exit Gates only
34 -Applications that accessed via API Gateway operations only are also no displayed in the Deploy Architecture. Exit gates are accessing these applications (displayed as systems) yet the exit gate will run on the gateway container runtime. Therefore, these system don't require any flow to deploy on so no runtimes gets created.
38 +[[image:Main.Images.Microlearning.WebHome@intermediate-solution-architecture-edit-memory-on-premise-runtime-windows--context-menu-view.png]]
35 35  
36 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-3.png]]
40 +When selecting the option View container a pop*up will be shown. Within this pop*up, you will see the advised heap and non*heap memory settings of that particular runtime.
37 37  
38 -There is an exception for that. In case the exit gate is required to run on the on-premises infrastructure of the client for security reasons, the runtime does get created and will be displayed therefore in the Deploy architecture. Apply to environment will not result in the physical deployment of the runtime, but's displayed so that the Deployment plan can indicate progress on deployment. The option Split Gateway needs to be checked in the Design phase
42 +[[image:Main.Images.Microlearning.WebHome@intermediate-solution-architecture-edit-memory-on-premise-runtime-windows--pop-up-details.png]]
39 39  
40 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-4.png]]
44 +=== 3.2 Edit memory on Linux based runtimes ===
41 41  
42 -* Hybrid systems
43 -In case a system will contain not only a user management like integration but also another integration (i.e. Messaging) the runtime will be displayed in Deploy architecture as usual. A flow or series of flows need to be deployed on the runtime
46 +Now that we know what the advised size is we can navigate to our on*premise installation location to edit the memory settings. Below we will detail the various steps needed to make this happen.
44 44  
45 -* Best practice for Design Architecture
46 -In Design Architecture it is adviced to create one or more on-premises machine that is toggled excluded. Each of these machine will act as a location where runtime not used in Deploy are put. So alignment between Design and Deploy is improved.
48 +* Log in via Putty by typing in the host and the port and press load
49 +* When asked for credentials fill in credentials (Be aware, Linux does not acceapt ctrl+v and does not show the password or an indication of the password). Right mouse click to copy the password and press enter
50 +* Navigate to the directory where you have installed the runtime (Command is: cd {directory structure})
51 +* Open the folder related to the runtime you want to change (Command is: cd emagiz_{technicalbusname}-{containertype}-{techincalnameruntime}_{environment}).
52 +* Open the etc folder within your runtime installation (Command is: cd etc)
53 +* Type in the following command: sudo vi emagiz and press Tab. This way Linux should auto suggest the so called wrapper.conf to be edited and press Enter if so
54 +* Type "i" to enter insert mode
55 +* Change the values of heap and or metaspace memory you want to change (you can navigate through the document with your arrow keys)
56 +* Press ESC and then type ":wq!" then press Enter to save the changes and exit Edit mode. Note: If you would like to exit the file without making any changes press ESC, then type ":q!" and press Enter
57 +* Restart the runtime by executing the correct restart command:
58 + ** systemd type: sudo systemctl restart <SERVICE_NAME>
59 + ** SystemV Type: sudo /etc/init.d/<SERVICE_NAME>-service restart
47 47  
48 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-4.png]]
49 49  
50 -== 4. Key takeaways ==
51 51  
52 -Design and Deploy architecture can differ in view * specific reasons exit which are described in this microlearning.
53 53  
54 -== 5. Suggested Additional Readings ==
64 +== 4. Assignment ==
55 55  
56 -*
57 -** [[Fundamentals (Menu)>>doc:Main.eMagiz Academy.Fundamentals.WebHome||target="blank"]]
58 -*** [[eMagiz Architecture (Menu)>>doc:Main.eMagiz Academy.Fundamentals.fundamental-emagiz-architecture.WebHome||target="blank"]]
59 -* [[Crash Course (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]
60 -** [[Crash Course API Gateway (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]]
61 -*** [[Setting up Exit gate (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-setting-up-exit-gate||target="blank"]]
62 -*** [[API User Management (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-user-management||target="blank"]]
63 -** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]]
64 -*** [[Understanding Design Architecture - Basic (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-design-understanding-design-architecture-basic||target="blank"]]
65 -* [[Intermediate (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]]
66 -** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Solution Architecture.WebHome||target="blank"]]
67 -* [[Advanced (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.WebHome||target="blank"]]
68 -** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Solution Architecture.WebHome||target="blank"]]
69 -* [[Expert (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.WebHome||target="blank"]]
70 -** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Solution Architecture.WebHome||target="blank"]]
71 -* [[Architecture (Search Result)>>url:https://docs.emagiz.com/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_space_facet=0%2FMain.&f_type=DOCUMENT&f_locale=en&f_locale=&f_locale=en&text=architecture||target="blank"]]
72 -)))
66 +As this is a more theoretical microlearning we do not have an assignment
73 73  
74 -(((
75 -{{toc/}}
76 -)))
77 -{{/container}}
78 -{{/container}}
68 +== 5. Key takeaways ==
69 +
70 +* The key aspects are:
71 + ** eMagiz can help you determine the correct size you need to configure via Design *> Architecture
72 + ** You need access to the on*premise location to perform the action
73 + ** Only change the wrapper.conf file. Nothing else
74 +
75 +
76 +
77 +== 6. Suggested Additional Readings ==
78 +
79 +None
80 +
81 +== 7. Silent demonstration video ==
82 +
83 +As this is a more theoretical microlearning we have no video for this
84 +
85 +)))((({{toc/}}))){{/container}}{{/container}}