Skip to Content
Last modified by Danniar Firdausy on 2024/09/02 16:51
From version 2.1
edited by Erik Bakker
on 2022/06/10 08:37
Change comment: Imported from XAR
To version 9.1
edited by eMagiz
on 2022/06/13 10:53
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,0 +1,1 @@
1 +API Gateway - Introduction
Parent
... ... @@ -1,0 +1,1 @@
1 +WebHome
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.ebakker
1 +XWiki.eMagiz
Content
... ... @@ -1,16 +1,7 @@
1 -{{html wiki="true"}}
2 -<div class="ez-academy">
3 - <div class="ez-academy_body">
4 -
5 -<div class="doc">
6 -
7 -
8 -
9 -= API Gateway * Introduction =
10 -
1 +{{container}}{{container layoutStyle="columns"}}(((
11 11  In this microlearning, we will introduce the key concepts of the API Gateway as eMagiz provides this capability.
12 12  
13 -Should you have any questions, please contact academy@emagiz.com.
4 +Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
14 14  
15 15  * Last update: February 21st, 2021
16 16  * Required reading time: 5 minutes
... ... @@ -27,9 +27,9 @@
27 27  A typical landscape could look like this.
28 28  The API Gateway is located in the secured eMagiz Cloud and provides the ability to access it from external application users. A client of ACME Ltd. could be sending in Sales Orders directly from their systems (incoming integration 1). The incoming Sales order is then delivered back to the back office system of ACME and could send a response back with successful delivery. Inside the ACME Ltd. organization, various development teams are processing the sales order further. One of the things that need to take place is to perform an external credit check of that specific client (integration 2). Service C might be responsible for that and is processing the request/response synchronously.
29 29  
30 -<p align="center">[[image:releasenote-apigw-1.png||]]</p>
21 +[[image:Main.Images.Microlearning.WebHome@releasenote-apigw-1.png]]
31 31  
32 -**Key considerations when to use the API Gateway integration pattern**
23 +Key considerations when to use the API Gateway integration pattern
33 33  
34 34  Below is the list of considerations when to use the API Gateway.
35 35  
... ... @@ -52,12 +52,13 @@
52 52  
53 53  The API Gateway is fully embedded into the eMagiz Low-code Enterprise iPaaS so that users have a similar user experience when configuring the API Gateway, a Messaging integration, or an Event Stream. All the platform features in the different ILM phases can take into account the API Gateway configuration. What is important to realize is that the primary focus of the API Gateway configuration is to allow all configuration work to take place in the Design phase. You will find out that most or often all the Create models are automatically generated. Only in specific cases where specific customization is required, the created objects can be modified. Newly created Designs could result in the rework of the customization in the Create object.
54 54  
55 -<p align="center">[[image:releasenote-apigw-2.png||]]</p>
46 +[[image:Main.Images.Microlearning.WebHome@releasenote-apigw-2.png]]
56 56  
57 -**1. Capture your API Gateway**
48 +(% style="list-style-type: lower-roman" %)
49 +1. Capture your API Gateway
58 58  In this phase, the regular operations or message types can be captured with all the necessary information of that specific operation. At the system level, you can indicate that the system acts as a backend service provider that has certain API's available
59 59  
60 -**2. Design an API Gateway**
52 +2. Design an API Gateway
61 61  This is the central phase in the configuration of the API Gateway. The main idea is that the entire Gateway should be configured from the Design phase The front-end Gateway is the part where the external application user(s) can access the specific operation published and where the application user is authorized for. Specific operations can be configured and documented including parameters and response types. In the backend operation provider (an eMagiz system), the actual link to the backend operations can be registered including parameters. Frontend and backend operations can be connected at the moment an operation is exposed in the eMagiz API Gateway. Integrations or message types connected to a backend operation providing system are now able to have operations as child objects to get a better overview of what operations are available. Operations are still the integrations reported in the various parts of eMagiz * the message type becomes more of a group object.
62 62  
63 63  * In case the backend service provider has an OpenAPI 3.0 specification available, this can be imported to have everything directly configured. Documentation of what OpenAPI statements are supported can be found in the help texts.
... ... @@ -66,10 +66,10 @@
66 66  For transformations, the request & reply system messages can be created visually like in the platform. The same goes for the gateway model that can be created visually as well. There is no concept of a CDM message as in the Messaging pattern. The transformation & Enrichment can take place in the standard mapping tooling available. So the concepts of a Request message, Response message, Mapping are available via right-click options in the platform.
67 67  Other transformations to reach SOAP/XML-based backend operations are also possible by selecting what format the operation has in the backend operation. This will then automatically ensure the transformation considers the JSON to XML transformation. For other protocol transformations, the XML variant can be used and custom influenced in the Create phase.
68 68  
69 -**3. Create phase for the API gateway**
61 +3. Create phase for the API gateway
70 70  In the Create phase, integrations with backend operations can be added to the Create model as usual. The result is that the specific components are created automatically. Via the Create * API Gateway section, the components are listed for now. In the upcoming releases, the Create phase will be updated to embed the API Gateway components in the complete view.
71 -
72 -**4. Deploy the API Gateway**
63 +
64 +4. Deploy the API Gateway
73 73  In the Deploy Phase the application users can be registered, the API key is generated automatically, and access to the specific backend operations where that application user should have access granted. Furthermore, the components of the API Gateway are the following:
74 74  
75 75  * Gateway infra
... ... @@ -78,11 +78,9 @@
78 78  
79 79  These components can be made part of the Release and Deployment plans. The Deploy Architecture will contain the Cloud architecture to be deployed and can be applied with the Design Architecture. The API Gateway runs in the eMagiz Cloud exclusively for now.
80 80  
81 -**5. Manage phase specific to the API Gateway**
73 +5. Manage phase specific to the API Gateway
82 82  In this phase, everything works as usual. Error messages of eMagiz will be routed in the Error messages, and the queue statistics are available as a separate entry in the left-hand menu.
83 83  
84 -===== Practice =====
85 -
86 86  == 4. Assignment ==
87 87  
88 88  Review the video below to ensure all concepts are clear
... ... @@ -104,10 +104,6 @@
104 104  
105 105  This video provides an introduction to the API Gateway of eMagiz
106 106  
107 -<iframe width="1907" height="1073" src="https://www.youtube.com/embed/8TBXq9SVdL8" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
97 +<iframe width="1907" height="1073" src="https://www.youtube.com/embed/8TBXq9SVdL8" reference="Main.Videos.Microlearning.WebHome"/}}
108 108  
109 -</div>
110 -</div>
111 -</div>
112 -
113 -{{/html}}
99 +)))((({{toc/}}))){{/container}}{{/container}}