Skip to Content
Last modified by Erik Bakker on 2024/09/02 16:02
From version 3.1
edited by Erik Bakker
on 2022/08/05 12:47
Change comment: There is no comment for this version
To version 4.1
edited by Erik Bakker
on 2022/10/03 11:26
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -3,9 +3,6 @@
3 3  
4 4  Should you have any questions, please contact academy@emagiz.com.
5 5  
6 -* Last update: October 20th, 2021
7 -* Required reading time: 10 minutes
8 -
9 9  == 1. Prerequisites ==
10 10  * Intermediate knowledge of the eMagiz platform
11 11  * Good working experience in the Design and Deploy Architecture phase.
... ... @@ -13,8 +13,6 @@
13 13  == 2. Key concepts ==
14 14  In the various microlearnings until the intermediate level, we have explained the [[eMagiz runtime>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-install-local-connector.WebHome||target="blank"]] itself . In short, it is the process that can make the flow components operational and execute the designated tasks of that flow. Please refer to these microlearnings for further information
15 15  
16 -
17 -
18 18  == 3. Specific eMagiz runtime considerations ==
19 19  
20 20  === 3.1 Messaging pattern runtimes ===
... ... @@ -23,11 +23,11 @@
23 23  
24 24  1. Sender or Receiver system is located in a public or private Cloud
25 25   * Put the Runtime on a Cloud Connector machine and ensure to use the connectivity options provided in eMagiz
26 -
21 +
27 27  2. Sender or Receiver system is located in a DMZ section of the client infrastructure
28 28   * Put the runtime inside the same DMZ zone to keep the runtime as close to the system as possible
29 29   * Ensure the management of the runtime is something workable for the client. Consider the updates that may occur as well as the fact that the runtime can no longer be managed by the eMagiz Portal
30 -
25 +
31 31  === 3.2 API Gateway pattern runtimes ===
32 32  
33 33  For these runtime the first choice is put all the Gateway Entry Flow and the Exit gates on the Cloud Connector machine. This way, the number of runtimes are kept to a minimum and there is full control over these runtime. In the exceptional case where the exit gate needs to connect to a system that is not accessible via the client firewalls, you can opt to put these exit gates only on a runtime that can be deployed on*premises. Please refer to the [microlearning around running part of the solution locally](advanced*api*management*running*part*of*your*api*gateway*solution*on*premise)