I2Camunda - Revision history

Pavel.lobko: /* geti2RestToken sub process */

2020-09-11T14:58:30Z

‎geti2RestToken sub process

Alexei.baranov: /* What is Camunda */

2020-09-11T14:16:36Z

‎What is Camunda

Alexei.baranov at 14:02, 11 September 2020

2020-09-11T14:02:56Z

Alexei.baranov: /* i2Camunda input parameters */

2020-09-11T13:29:28Z

‎i2Camunda input parameters

Alexei.baranov: /* i2Camunda input parameters */

2020-09-11T13:27:24Z

‎i2Camunda input parameters

Alexei.baranov: /* i2Camunda input parameters */

2020-09-11T13:03:05Z

‎i2Camunda input parameters

Alexei.baranov: /* i2Camunda input parameters */

2020-09-11T12:58:09Z

‎i2Camunda input parameters

Alexei.baranov: /* Authorized call using OAuth2 token */

2020-08-05T09:04:28Z

‎Authorized call using OAuth2 token

Alexei.baranov: /* Sample processes */

2020-08-04T16:05:44Z

‎Sample processes

Alexei.baranov: /* What is Camunda */

2020-08-04T12:56:40Z

‎What is Camunda

@@ Line 91: / Line 91: @@
 User will have to open this URL in his browser, and allow or decline the request of the client (ie Camunda PBM engine) for run programs with his (user) authority. This step is not shown on the process diagram, because it is not managed by Camunda BPM engine.<br/>
 At the same time, task "Get authorization token" will try to get access token from i2Rest Server using device_code that was obtained early<br/>
-If user still not decided to allow or decline the request, process will continue at the task "Show verification URL" again<br/>
+If user still did not decide to allow or to decline the request, process will continue at the task "Show verification URL" again<br/>
 When user allows i2Rest Server to issue access token for the client, task "Get authorization token" will be completed and access token will be returned to upper level process<br/>
 Another decision will raise BPMN error or create new incident<br/><br/>
 Of course, this process can be optimized for your needs, in this form it only demonstrates the possibility of building a OAuth2 flow using i2Camunda tasks<br/>

@@ Line 9: / Line 9: @@
 </i>
 More details can be found at the [https://www.camunda.com Camunda's official site]<br/>
-We are not describing here the process of Camunda implementation and customization. There are a lot of guides available at Camunda official site and forums.<br/>
+We are not describing here the process of Camunda implementation and customization. There are lot of guides available at Camunda official site and forums.<br/>
 It is possible to start working with i2Camunda on top of Camunda Open Source Community Edition (https://camunda.com/download/). You can install it on any supported environment: https://docs.camunda.org/manual/latest/introduction/supported-environments/

@@ Line 1: / Line 1: @@
 {{DISPLAYTITLE:What is i2Camunda?}}
 i2Camunda is a separate extension for i2Rest Server, which is designed to organize the interaction of the Camunda BPM engine with IBM i programs and commands via i2Rest Server APIs.<br/>
 __TOC__

@@ Line 30: / Line 30: @@
 * [[i2Camunda_i2rest_request_authorize|i2rest_request_authorize]] - to request user and device codes (first step of OAuth2 Device code flow)
 * [[i2Camunda_i2rest_request_bridge_authorize|i2rest_request_bridge_authorize]] - to submit the request for Bridge device code and bridge user code (first step of OAuth2 Access code flow in i2Rest Bridge mode)
-* [[i2Camunda_i2rest_wait_authorization|i2rest_wait_authorization]] - to get OAuth2 token (last step of OAuth2 Device code flow)
+* [[i2Camunda_i2rest_wait_authorization|i2rest_wait_authorization]] - to get OAuth2 token (last step of OAuth2 Device code flow or second step of Authorization code flow in i2Rest bridge mode)
-* [[i2Camunda_i2rest_get_access_token|i2rest_get_access_token]] - to get Access code (second step of OAuth2 Access code flow in i2Rest Bridge mode)
+* [[i2Camunda_i2rest_get_access_token|i2rest_get_access_token]] - to get Access token (last step of Authorization code flow in i2Rest Bridge mode)
 * [[i2Camunda_i2rest_get_fresh_token|i2rest_get_fresh_token]] - to present refresh token and exchange it to new access token (OAuth2 Refresh token flow)
 * [[i2Camunda_i2rest_request_client_credentials_token|i2rest_request_client_credentials_token]] - to obtain OAuth2 Client credentials token

@@ Line 31: / Line 31: @@
 * [[i2Camunda_i2rest_request_bridge_authorize|i2rest_request_bridge_authorize]] - to submit the request for Bridge device code and bridge user code (first step of OAuth2 Access code flow in i2Rest Bridge mode)
 * [[i2Camunda_i2rest_wait_authorization|i2rest_wait_authorization]] - to get OAuth2 token (last step of OAuth2 Device code flow)
 * [[i2Camunda_i2rest_get_fresh_token|i2rest_get_fresh_token]] - to present refresh token and exchange it to new access token (OAuth2 Refresh token flow)
 * [[i2Camunda_i2rest_request_client_credentials_token|i2rest_request_client_credentials_token]] - to obtain OAuth2 Client credentials token

@@ Line 62: / Line 62: @@
 [[File:Simple I2RESTECHO i2camunda parameters.PNG|700px]]<br/>
 ==Authorized call using OAuth2 token==
-This case shows the ability to make authorized calls to RPGLE programs. We will demonstrate it on the basis of the scenario [[Configuring_OAuth2_authorization|Configuring i2Rest Service with OAuth2 parameters]]. This scenario demonstrates classic [https://tools.ietf.org/html/rfc8628 OAuth2 Device flow] that can be used for all browserless devices. We are also demonstrate this flow with out i2Rest Client - see [[Device_flow_description|here]]<br/>
+This case shows the ability to make authorized calls to RPGLE programs. We will demonstrate it on the basis of the scenario [[Configuring_OAuth2_authorization|i2Rest Service with OAuth2 parameters]]. This scenario demonstrates classic [https://tools.ietf.org/html/rfc8628 OAuth2 Device flow] that can be used for all browserless devices. We are also demonstrate this flow with out i2Rest Client - see [[Device_flow_description|here]]<br/>
 To simplify the process, we will divide overall BPMN to two separate processes - main process and external sub process which will implement logic for obtaining OAuth2 token from i2Rest Server. This solution also allows the sub process to be reused in other processes where communication with the server using a OAuth2 token is required<br/>
 ===Main process===

← Older revision		Revision as of 16:05, 4 August 2020
Line 61:		Line 61:
	Do not forget to enter actual URL of your i2Rest Server instance at the i2camunda_parameters input mapping:<br/>		Do not forget to enter actual URL of your i2Rest Server instance at the i2camunda_parameters input mapping:<br/>
	[[File:Simple I2RESTECHO i2camunda parameters.PNG\|700px]]<br/>		[[File:Simple I2RESTECHO i2camunda parameters.PNG\|700px]]<br/>
		+	==Authorized call using OAuth2 token==
		+	This case shows the ability to make authorized calls to RPGLE programs. We will demonstrate it on the basis of the scenario [[Configuring_OAuth2_authorization\|Configuring i2Rest Service with OAuth2 parameters]]. This scenario demonstrates classic [https://tools.ietf.org/html/rfc8628 OAuth2 Device flow] that can be used for all browserless devices. We are also demonstrate this flow with out i2Rest Client - see [[Device_flow_description\|here]]<br/>
		+	To simplify the process, we will divide overall BPMN to two separate processes - main process and external sub process which will implement logic for obtaining OAuth2 token from i2Rest Server. This solution also allows the sub process to be reused in other processes where communication with the server using a OAuth2 token is required<br/>
		+	===Main process===
		+	This process is extremely simple. At the first step, we call the sub process to get the token. At the second step, we call the RPGLE demo program using the OAuth2 token.<br/>
		+	[[File:Calli2Rest main.png\|500px]]<br/>
		+	Source: [https://www.i2rest.com/download/i2Camunda_samples/calli2Rest.bpmn https://www.i2rest.com/download/i2Camunda_samples/calli2Rest.bpmn]<br/>
		+	Again, we have to update some parameters of tasks:<br/>
		+	[[File:Calli2Rest setup first step.PNG\|700px]]<br/>
		+	and<br/>
		+	[[File:Calli2Rest setup second step.PNG\|700px]]<br/>
		+	Of course, in more sophisticated process we can define these parameters at the entire process level (for example, in process start listener)<br/>
		+	===geti2RestToken sub process===
		+	This sub process will encapsulate all logic related with obtaining of OAuth2 token from i2Rest Server<br/>
		+	[[File:Geti2RestToken.png\|700px]]<br/>
		+	Source: [https://www.i2rest.com/download/i2Camunda_samples/geti2RestToken.bpmn https://www.i2rest.com/download/i2Camunda_samples/geti2RestToken.bpmn]<br/>
		+	First, it will take parameters from upper level process (see process start listener):
		+	:* authorization_endpoint
		+	:* token_endpoint
		+	:* client_id
		+	:* client_secret
		+	:* refresh_token
		+	Than, if refresh_token parameter has been passed, it will try to get new token using refresh_token (leftmost activity on the diagram).<br/>
		+	In case of successful call, the sub process will return token and new refresh_token to the upper level process<br/>
		+	If refresh_token is absent, or in case of any error during the previous step, the subprocess will try to request the user_code, device_code and verification_url from i2Rest Server (second activity from the left)<br/>
		+	In case of unrecoverable errors (for example, Client is unauthorized or i2Rest Server is unavailable), sub process will raise BPMN errors. Now our main process has no Error boundary events, it means that incident will be created.<br/>
		+	The next step is the User Task. It will show the user the results of the previous call. Among with other parameters, the user will see the address at which he can authorize a request to receive a token, it will be shown in process variable url_complete:<br/>
		+	[[File:Geti2RestToken 3.PNG\|700px]]<br/>
		+	User will have to open this URL in his browser, and allow or decline the request of the client (ie Camunda PBM engine) for run programs with his (user) authority. This step is not shown on the process diagram, because it is not managed by Camunda BPM engine.<br/>
		+	At the same time, task "Get authorization token" will try to get access token from i2Rest Server using device_code that was obtained early<br/>
		+	If user still not decided to allow or decline the request, process will continue at the task "Show verification URL" again<br/>
		+	When user allows i2Rest Server to issue access token for the client, task "Get authorization token" will be completed and access token will be returned to upper level process<br/>
		+	Another decision will raise BPMN error or create new incident<br/><br/>
		+	Of course, this process can be optimized for your needs, in this form it only demonstrates the possibility of building a OAuth2 flow using i2Camunda tasks<br/>