Hi Chamila, On Thu, Aug 25, 2016 at 9:37 AM, Chamila Adhikarinayake <[email protected]> wrote:
> Hi Nandika/Vinod > > Thanks for the information related to BPMN. I'll check on BPMN User tasks > as a replacement for human tasks > > @jena, > The default implementation will execute for every lifecycle state change. > . Lifecycle state change happens based on the 'lifecycle action' . You > could create a custom workflow implementation to filter out based on this > action and create a custom one for selected state changes. > Can we do it in a way so that we can modify the lifecycle XML and integrate a workflow to a specific transition. Having to filter the lifecycle state from the BPMN side would result in complex BPMN process if a user wants to have different workflows for different lifecycle state transitions. The only concern with the above approach is that, it will differ from our other workflow implementations where we define them from a single place. Hence can we do a little study and see whether there is a way to define different workflows for different lifecycle transitions. Thanks, Janaka > > Thanks > Chamila. > > On Thu, Aug 25, 2016 at 9:14 AM, Nandika Jayawardana <[email protected]> > wrote: > >> Hi Chamila, >> >> This is a good initiative to move to BPMN. You can implement your human >> tasks as well as flow within the BPMN itself. Since BPMN is based on the >> rest api, you will not have the trouble of converting between soap and rest >> as well. In future, we can incorporate the BPMN editor (which is in >> progress ) to APIM product to allow the developers to customize the flow as >> required. >> We can take this as an initial step to convert all the workflows in APIM >> to BPMN. >> >> Regards >> Nandika >> >> On Thu, Aug 25, 2016 at 9:00 AM, Jenananthan Yogendran < >> [email protected]> wrote: >> >>> Hi Chamila, >>> >>> Will this workflow associated to all the life cycle status changes ? or >>> we can configure in such a way to associate the workflow to selected >>> lifecycle transition , e.g initial->create ,create->publish >>> >>> On Wed, Aug 24, 2016 at 2:35 PM, Chamila Adhikarinayake < >>> [email protected]> wrote: >>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Jenananthan Yogendran >>> *Senior Software Engineer,* >>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Nandika Jayawardana >> WSO2 Inc ; http://wso2.com >> lean.enterprise.middleware >> > > > > -- > 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 > > -- *Janaka Ranabahu* Associate Technical Lead, WSO2 Inc. http://wso2.com *E-mail: [email protected] <http://wso2.com>**M: **+94 718370861* Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
