Skip to Content
Last modified by Waria on 2026/07/23 10:14
From version 36.1
edited by dfirdausy
on 2024/09/02 16:51
Change comment: There is no comment for this version
To version 37.1
edited by Waria
on 2026/07/23 10:14
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.dfirdausy
1 +XWiki.waria
Content
... ... @@ -46,7 +46,7 @@
46 46  * Design an API Gateway
47 47  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.
48 48  ** 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.
49 -** The security method for the entire Gateway can be set - at this moment the eMagiz API Gateway works with API keys that be handed out to application users. Users can be provided with such an API key, and users are assigned certain roles. These roles have in turn access to certain backend operations.
49 +** The authentication methods for the API Gateway can be set - You can determine if your API Gateway can handle OAuth 2.0, Basic Auth and/or API Key. OAuth 2.0 is enabled by default.
50 50  ** 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.
51 51  ** 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.
52 52   * Create phase for the API gateway