Hi all, Following is a rough flow diagram related to this feature.
When user change the lifecycle from the publisher ui or through rest api, changeLifeCycleStatus() method gets invoked. From that method workflow executor's execute() get called. workflow executor is selected based on the workflow-extensions.xml (same as workflows in store) workflow request is done to BPS using a WS Workflow Executor . API related information with the worklowreferenceid will be sent to the BPS. client id and client secret for an oauth application will be sent to the bps. these credentials will be used to generate token to access the callback rest api to complete the workflow. Other aditional parameters are shown in the image. A new rest api is deployed in AM publisher as the callback url. once the workflow resume response comes back to this api , it loads the workflow executor based on the workflow type. Tenant loading happens based on the tenant domain (these values are store in the AM_WORKFLOWS table. these information can be retrieve using the workflow reference id). From the complete() method, Lifecycle state change is happended based on the wf status inside the complete() method. Lifecycle action will be used for the API lifecycle state change Oauth application credentials are passed with the wf request to the BPS. One alternative for this would be manually generating the oauth app and provide the client id and secret as pre-defined parameters in the business process archive file. In the default executor execte() method directly calls complete() method Any modifications and suggestions are highly appreciated. Thanks, Chamila On Mon, Aug 22, 2016 at 11:20 AM, Nuwan Dias <[email protected]> wrote: > Hi Chamila, > > I think its better to draw a diagram including API-M and BPS and describe > the parameters passed in-between :) > > Thanks, > NuwanD. > > On Mon, Aug 22, 2016 at 10:52 AM, Chamila Adhikarinayake < > [email protected]> wrote: > >> Hi All, >> >> This feature is to add workflow extension support to API lifecycle state >> changes. This feature will be similar to workflow extension support in API >> store. >> >> There will be two workflow extensions provided with this. WS Workflow >> Executor and Simple Workflow Executor. Simple Workflow Executor carries out >> an operation without any intervention by a workflow admin. WS Workflow >> Executor will call external service (In this case service in BPS) for >> workflow tasks. >> >> For this we are planning to introduce BPMN process instead of using BPEL. >> A new rest api will be added to publisher rest apis for the BPMN process to >> use as the callback service. This new rest api will be protected with a >> scope for workflow. >> >> Since the REST api is protected with OAuth tokens, we need a method to >> provide Oauth application information to BPS service. Current plan is to >> generate oauth application from the APIM side using dcr endpoint and pass >> the client id and secret to BPS service when invoking the workflow's >> execute method. BPMN process will then use these application information to >> generate token and using that it will invoke the callback rest api to >> continue the workflow. >> >> Lifecycle executor will be called based on the status of the workflow. >> >> A new UI will be added to Admin Portal to handle human tasks (to approve >> or reject) >> >> Any suggestion is highly appreciated. >> >> Thanks, >> Chamila >> >> -- >> Regards, >> Chamila Adhikarinayake >> Software Engineer >> WSO2, Inc. >> Mobile - +94712346437 >> Email - [email protected] >> Blog - http://helpfromadhi.blogspot.com/ >> > > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > -- Regards, Chamila Adhikarinayake Software Engineer WSO2, Inc. Mobile - +94712346437 Email - [email protected] Blog - http://helpfromadhi.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
