Changes for page Command Queue

Last modified by Erik Bakker on 2024/02/22 13:38

From version 11.2
edited by Erik Bakker
on 2022/07/28 08:47
Change comment: Update document after refactoring.
To version 15.1
edited by Erik Bakker
on 2022/12/29 14:44
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -expert-data-handling-groovy-script
1 +Command Queue
Content
... ... @@ -1,5 +1,5 @@
1 1  {{container}}{{container layoutStyle="columns"}}(((
2 -In the crash course on the API Gateway we discussed the various options available to [[secure>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-security.WebHome||target="blank"]] your API Gateway properly. In this microlearning, we will expand our knowledge on that topic by looking at a special case of securing your API Gateway. That case is special as you use an external identity provider (IDP) to govern the roles and users that have rights on your API Gateway.
2 +Within the platform of eMagiz, sometimes you need to send a particular command from the eMagiz portal to retrieve information or execute a specific action. These commands can happen from the Deploy and the Manage phase. The two most noteworthy examples of the triggered command queue are the runtime dashboard functionalities and the message redelivery actions.
3 3  
4 4  Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
... ... @@ -9,50 +9,35 @@
9 9  
10 10  == 2. Key concepts ==
11 11  
12 -This microlearning focuses on using an external IDP to validate whether a user is authorized to execute a certain action on your API Gateway and what configuration is needed in eMagiz to make this work.
12 +This microlearning focuses on the command queue. The command queue communicates between the eMagiz portal and an eMagiz runtime.
13 13  
14 -* The Token and Issuer URL of the external IDP need to be known
15 -* Users and Roles under User Management need to be manually configured and maintained to keep them in sync with the external IDP
14 +* Commands towards a runtime, for example, to retrieve runtime information in the runtime dashboard, are sent via the command queue
15 +* You can monitor the command queue the same way as any other queue within your model
16 +* The command queue is prominently used when accessing the [[Runtime Dashboard>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-runtime-dashboard||target="blank"]] and when using [[Message Redelivery>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Message Redelivery.WebHome||target="blank"]]
16 16  
17 -== 3. External IDP ==
18 +== 3. Command queue ==
18 18  
19 -In the crash course on the API Gateway we discussed the various options available to [[secure>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-security.WebHome||target="blank"]] your API Gateway properly. In this microlearning, we will expand our knowledge on that topic by looking at a special case of securing your API Gateway. That case is special as you use an external identity provider (IDP) to govern the roles and users that have rights on your API Gateway.
20 +Within the platform of eMagiz, sometimes you need to send a particular command from the eMagiz portal to retrieve information or execute a specific action. These commands can happen from the Deploy and the Manage phase. The two most noteworthy examples of the triggered command queue are the runtime dashboard functionalities and the message redelivery actions.
20 20  
21 -When selecting the option OAuth2.0 (or OpenID Connect) you have the option to use the IDP provided by eMagiz which makes the configuration easy or you could use an external IDP which you have control over and want to use for this purposes.
22 +For example, when you navigate the Runtime Dashboard and click on a runtime, the eMagiz portal will send a command to the runtime via the command queue to retrieve the runtime state. So, for example, the same logic applies when you select a flow and stop it.
22 22  
23 -In this microlearning we will highlight what you need to configure in Design and Deploy to make this work within the tooling of eMagiz.
24 +For Message redelivery, the command queue retrieves all messages in the dead letter queue and resends messages via the command queue.
24 24  
25 -=== 3.1 Design ===
26 +{{info}}When all commands sent from the eMagiz portal are not working across models, something is probably broken in the backend of the eMagiz platform. In these cases, please contact us at [[support@emagiz.com>>mailto:support@emagiz.com]]{{/info}}
26 26  
27 -On the security level of the API Gateway in Design you need to select the desired option, for example OAuth2.0. Instead of not filling in the token and issuer URL, indicating that you want to use the eMagiz IDP, you need to fill these in to reference the IDP of your choice. Below you see an example of how this could be configured.
28 -
29 -[[image:Main.Images.Microlearning.WebHome@expert-securing-data-traffic-api-gw-security-external-idp-security-config-design.png]]
30 -
31 -Note that the environmentID in this example should be replaced with an actual environmentID that references your environment.
32 -
33 -=== 3.2 Deploy ===
34 -
35 -Normally, eMagiz will automatically update the User Management information based on the configuration in Design. However, because the identity check is not done by eMagiz but by an external party you need to manually enter the roles and users and configure the scope correctly on role level.
36 -
37 -To do so navigate to User Management in Deploy and add the users you want manually by pressing the New button and providing them with a name. Do subsequently the same for the roles. On role level do not forget to correctly enter the scope to make the call work. Note that the help text on the scope level gently reminds you what you need to do to make this work.
38 -
39 -[[image:Main.Images.Microlearning.WebHome@expert-securing-data-traffic-api-gw-security-external-idp-scope-configuration.png]]
40 -
41 -{{warning}}When implementing this you would be the first to do so with this setup. This means there might be some unexpected behavior when configuring this.{{/warning}}
42 -
43 43  == 4. Assignment ==
44 44  
45 -No assignment
30 +There is no assignment for this microlearning.
46 46  
47 47  == 5. Key takeaways ==
48 48  
49 -* The Token and Issuer URL of the external IDP need to be known
50 -* Users and Roles under User Management need to be manually configured and maintained to keep them in sync with the external IDP
51 -* When implementing this you would be the first to do so with this setup.
34 +* Commands towards a runtime, for example, to retrieve runtime information in the runtime dashboard, are sent via the command queue
35 +* You can monitor the command queue the same way as any other queue within your model
36 +* The command queue is prominently used when accessing the [[Runtime Dashboard>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-runtime-dashboard.WebHome||target="blank"]] and when using [[Message Redelivery>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Message Redelivery.WebHome||target="blank"]]
52 52  
53 53  == 6. Suggested Additional Readings ==
54 54  
55 -If you are interested in this topic and want more information, please read the help text provided by eMagiz.
40 +There are no suggested additional readings.
56 56  
57 57  == 7. Silent demonstration video ==
58 58