Great! Is our gut feeling that the same is true also in other cases in which WSO2 products benefit from BPS (e.g. ES)? That would be good progress :-)
Best regards, Frank 2015-07-20 6:15 GMT+02:00 Chathura Ekanayake <chath...@wso2.com>: > Hi Frank, > > > This does not solve the problem of missing data: your selection may skip >> steps that produce data required by the selected steps. >> > > As discussed with Prabath and IS team, human tasks involved in these > workflows have the same input and output data. Input data is provided at > process instance creation (e.g. details of a new user) and output data is > whether the request is approved or not. Therefore, I think we assume that > tasks do not depend on outputs of other tasks. > > Regards, > Chathura > >> >> >> 2015-07-16 8:49 GMT+02:00 Chathura Ekanayake <chath...@wso2.com>: >> >>> From the implementation point of view, the BPEL workflow executor should >>> read the workflow template (which may be stored in the registry) and attach >>> template details to BPEL invocation request. So that the BPEL request >>> message will look like below: >>> >>> <body> >>> <addUserWorkflowRequest> >>> <template> >>> <step> >>> <name>step1</name> >>> <assignment>...</assignment> >>> </step> >>> <step> >>> <name>step2</name> >>> <assignment>...</assignment> >>> </step> >>> </template> >>> >>> <userData> >>> <username>smith</username> >>> <password>smithpass</password> >>> <roles> >>> <role>manager</role> >>> <role>inventoryStaff</role> >>> </roles> >>> </userData> >>> </addUserWorkflowRequest> >>> </body> >>> >>> BPEL workflow decides which tasks to execute by examining the >>> template/step/name part and assigns users to corresponding tasks using the >>> template/step/assignment part. <userData> element contains the actual >>> payload of the request, which may be used by human tasks to display >>> information about the user being added. >>> >>> Regards, >>> Chathura >>> >>> On Thu, Jul 16, 2015 at 12:00 PM, Chathura Ekanayake <chath...@wso2.com> >>> wrote: >>> >>>> I think we can clarify this further by looking in to user stories. I >>>> think the user experience of using IS workflows should be something like >>>> this: >>>> >>>> Scenario A - Associating a workflow with an action (e.g. Add user >>>> action): >>>> 1) Select the "Add user" attachment point from the list of published >>>> attachment points >>>> 2) Select a workflow from the list of registered workflows >>>> 3) Once selected, the selected workflow can be configured to create a >>>> template (as described in 4 and 5) >>>> 4) User is presented with all available tasks (i.e. steps) in the >>>> selected workflow >>>> 5) User can exclude certain tasks and assign users/roles to remaining >>>> tasks >>>> 6) User can specify an activation condition for the workflow >>>> >>>> Scenario B - Performing an action which has an associated workflow >>>> (e.g. Adding a user): >>>> 1) User fills in the add user form and click "Finish" >>>> 2) The associated workflow is triggered and relevant users performs >>>> tasks assigned to them using the BPS human task webapp >>>> 3) Once the workflow completes, it returns the approval status and IS >>>> decides whether to add the user based on the status >>>> >>>> Scenario C - Registering a workflow: >>>> 1) Deploy the required BPEL archive in BPS >>>> 2) Provide the URL of the BPEL endpoint as a configuration >>>> 3) Specify the list of configurable tasks (this is used for creating >>>> templates) >>>> >>>> Below are some questions: >>>> >>>> Scenario A: >>>> Can we specify multiple workflows for the same action? >>>> Do workflows always return a boolean value (i.e. approved / not >>>> approved)? >>>> >>>> Scenario B: >>>> Are we expecting the users to complete tasks (e.g. approval steps) >>>> using the BPS Human Task web app? Or are we providing an integrated human >>>> task UI in the IS management console? >>>> >>>> Scenario C: >>>> Are there any other steps involved in this? >>>> The list of tasks can also be extracted from the BPEL by locating >>>> b4p:peopleActivity elements. Then the user can remove certain tasks from >>>> the configurable tasks list, if those are mandatory. >>>> >>>> Regards, >>>> Chathura >>>> >>>> >>>> >>>> On Wed, Jul 15, 2015 at 9:40 PM, Prabath Siriwardena <prab...@wso2.com> >>>> wrote: >>>> >>>>> Thanks Frank for the suggestion. Yes - it would be great if we can >>>>> make the template generation easy. At the moment as we discussed with >>>>> Chathura, we are creating a parameterized BPEL workflow and parameters >>>>> are >>>>> picked from the user through the template (in IS). So the same BPEL >>>>> workflow will find different execution paths based on the template... >>>>> >>>>> Thanks & regards, >>>>> -Prabath >>>>> >>>>> >>>>> On Wed, Jul 15, 2015 at 6:02 AM, Frank Leymann <fr...@wso2.com> wrote: >>>>> >>>>>> As Chathura describes, "workflow templates" are not easy to design. >>>>>> This is why we discussed some months ago a "specialized language" to >>>>>> ensure >>>>>> that template design is easy. Another alternative is to consider CMMN >>>>>> which has been designed to make "skipping" more easy... Maybe that's >>>>>> another subject to be discussed when we meet early August in Colombo? >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Frank >>>>>> >>>>>> 2015-07-15 6:31 GMT+02:00 Chathura Ekanayake <chath...@wso2.com>: >>>>>> >>>>>>> According to the discussion we had last week, I think the users >>>>>>> assigned to tasks (e.g. approvers) as well as workflow steps have to be >>>>>>> configurable. That means, we can give a workflow covering many steps. >>>>>>> Then >>>>>>> steps required for a particular scenario (and users/roles for those >>>>>>> steps) >>>>>>> can be selected based on the configuration (i.e. workflow template). >>>>>>> >>>>>>> For example a workflow (workflow A) can be: >>>>>>> >>>>>>> Step1 -> Step2 -> Step3 -> Step4 >>>>>>> >>>>>>> And a workflow template (for workflow A) can be: >>>>>>> Step1 : role1 OR user2 >>>>>>> Step3 : role2 >>>>>>> >>>>>>> Above template triggers the workflow A by skipping tasks Step2 and >>>>>>> Step4. Therefore, a concrete workflow can support any template that >>>>>>> contains subset of its tasks. Then there is a problem if a workflow >>>>>>> contains conditional branches (i.e. if branches / OR gateways). In that >>>>>>> case, certain branches may not contain tasks specified in a template. >>>>>>> Therefore, what a template states is the tasks that can possibly >>>>>>> execute. >>>>>>> >>>>>>> The next problem is whether tasks have dependencies on other tasks >>>>>>> (e.g. output variables of task A can be consumed by task B). In that >>>>>>> case >>>>>>> if task A is skipped workflow may fail. Therefore, either we have to >>>>>>> design >>>>>>> workflows without having any dependencies among tasks or we should >>>>>>> support >>>>>>> restrictions on workflow templates (e.g. if task B is included then >>>>>>> task A >>>>>>> has to be included). >>>>>>> >>>>>>> Regards, >>>>>>> Chathura >>>>>>> >>>>>>> On Wed, Jul 15, 2015 at 1:42 AM, Prabath Siriwardena < >>>>>>> prab...@wso2.com> wrote: >>>>>>> >>>>>>>> BTW yes - lets have a discussion on this again - because this is >>>>>>>> not just IS thing - and can be used by any other product which needs to >>>>>>>> have workflow support.. >>>>>>>> >>>>>>>> Thanks & regards, >>>>>>>> -Prabath >>>>>>>> >>>>>>>> On Tue, Jul 14, 2015 at 1:07 PM, Prabath Siriwardena < >>>>>>>> prab...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Hi Suemdha, >>>>>>>>> >>>>>>>>> We discussed most of the stuff with the API Manager team before >>>>>>>>> doing this. >>>>>>>>> >>>>>>>>> At the moment API Manager implementation does not have any of >>>>>>>>> these capabilities and most of the time need to write a workflow or >>>>>>>>> modify >>>>>>>>> a workflow.. >>>>>>>>> >>>>>>>>> Thanks & regards, >>>>>>>>> -Prabath >>>>>>>>> >>>>>>>>> On Tue, Jul 14, 2015 at 1:03 PM, Sumedha Rubasinghe < >>>>>>>>> sume...@wso2.com> wrote: >>>>>>>>> >>>>>>>>>> Prabath, >>>>>>>>>> I think this has some overlaps and improvements compared to what >>>>>>>>>> we have done for API Manager about 2 years ago. >>>>>>>>>> Let's have a discussion on how to bring best of both worlds. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jul 15, 2015 at 12:49 AM, Prabath Siriwardena < >>>>>>>>>> prab...@wso2.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Isabelle, >>>>>>>>>>> >>>>>>>>>>> As per the offline chat - you talk about *workflow templates * >>>>>>>>>>> here.. >>>>>>>>>>> >>>>>>>>>>> The *workflow* implementation should be able to interpret the >>>>>>>>>>> *workflow >>>>>>>>>>> template*. >>>>>>>>>>> >>>>>>>>>>> Lets take for example the following sample template.. >>>>>>>>>>> >>>>>>>>>>> Step-1 Approvers : <role1> OR <role2> AND user1 >>>>>>>>>>> Step-2 Approvers : <role3> OR <role4> AND user3 >>>>>>>>>>> >>>>>>>>>>> There can be multiple workflow implementations supporting the >>>>>>>>>>> above - but the catch here is, when you have a concrete workflow >>>>>>>>>>> implementation it should announce which templates are supported by >>>>>>>>>>> it. That >>>>>>>>>>> is how the underneath framework knows - which templates are >>>>>>>>>>> supported by >>>>>>>>>>> which workflows. >>>>>>>>>>> >>>>>>>>>>> Its pointless to have workflow templates in the system without >>>>>>>>>>> having workflow implementations that support them. >>>>>>>>>>> >>>>>>>>>>> If there is a need to write a workflow template - then that >>>>>>>>>>> means - you are also going to write a workflow that knows how to >>>>>>>>>>> interpret >>>>>>>>>>> it. >>>>>>>>>>> >>>>>>>>>>> Users of the system need not to worrying about mapping templates >>>>>>>>>>> to the implementations (workflows). Since the each workflow >>>>>>>>>>> announces which >>>>>>>>>>> templates they support - the framework itself can do it. >>>>>>>>>>> >>>>>>>>>>> From user's point of view - what mostly matters is the workflow >>>>>>>>>>> template (please see the above example). Templates decide what >>>>>>>>>>> needs to be >>>>>>>>>>> done - and the workflow implementation decides how to do that. >>>>>>>>>>> >>>>>>>>>>> The user experience is like below. >>>>>>>>>>> >>>>>>>>>>> What do I need to know ? I need to associate a workflow for the >>>>>>>>>>> add-user operation. >>>>>>>>>>> >>>>>>>>>>> User first picks the *Attachment Point - *in this case add_user. >>>>>>>>>>> >>>>>>>>>>> Now - I need to specify under which conditions I need to execute >>>>>>>>>>> this work flow.. >>>>>>>>>>> >>>>>>>>>>> User fills the *Attachment Point Template* - execute this >>>>>>>>>>> workflow if user's email address is from WSO2. >>>>>>>>>>> >>>>>>>>>>> Now - I need to select what needs to be done during the add user >>>>>>>>>>> operation. >>>>>>>>>>> >>>>>>>>>>> User picks one of the available *workflow templates* - and fill >>>>>>>>>>> the data required. >>>>>>>>>>> >>>>>>>>>>> If there are more than one implementations for the picked* >>>>>>>>>>> workflow template *system will present you an option to pick >>>>>>>>>>> the workflow (rather unlikely) if not - system already associates >>>>>>>>>>> the >>>>>>>>>>> available workflow with the selected workflow template - user has to >>>>>>>>>>> nothing there. >>>>>>>>>>> >>>>>>>>>>> Thanks & regards, >>>>>>>>>>> -Prabath >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jul 14, 2015 at 11:36 AM, Isabelle Mauny < >>>>>>>>>>> isabe...@wso2.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Prabath, >>>>>>>>>>>> >>>>>>>>>>>> Couple of clarifications: >>>>>>>>>>>> - If a user ( customer ) adds a template, what would they need >>>>>>>>>>>> to write ? The template definition *AND* the implementation (i.e. >>>>>>>>>>>> executor) >>>>>>>>>>>> ? i.e other words they have to describe the interface to the >>>>>>>>>>>> workflow >>>>>>>>>>>> itself and then implement the workflow in say BPEL ? Or Java ? or >>>>>>>>>>>> whatever >>>>>>>>>>>> ? >>>>>>>>>>>> - How does a customer maps between the template and the >>>>>>>>>>>> executor ? (i.e. how do parameters defined in template becomes >>>>>>>>>>>> Receive data >>>>>>>>>>>> in BPEL for example) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Isabelle. >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------------------------- >>>>>>>>>>>> *Isabelle Mauny* >>>>>>>>>>>> VP, Product Management - WSO2, Inc. - http://wso2.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jul 14, 2015 at 6:22 PM, Prabath Siriwardena < >>>>>>>>>>>> prab...@wso2.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> It looks like still there are some confusions regarding IS >>>>>>>>>>>>> workflow implementation. So, thought of sharing my thoughts on >>>>>>>>>>>>> the design - >>>>>>>>>>>>> and hopefully this be helpful to clear out the doubts. >>>>>>>>>>>>> >>>>>>>>>>>>> AFAIK - the framework for the following is already implemented. >>>>>>>>>>>>> >>>>>>>>>>>>> Basic design principals. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Simplicity. Keep simple things simple and have provisions >>>>>>>>>>>>> to add more complex stuff >>>>>>>>>>>>> 2. Not coupled into any implementation. No hard coupling to >>>>>>>>>>>>> BPEL >>>>>>>>>>>>> 3. Not coupled into WSO2 BPS. (part of 2 as well) >>>>>>>>>>>>> 4. Not specific to IS >>>>>>>>>>>>> >>>>>>>>>>>>> Terminology: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. *Workflow* - implementation independent abstract >>>>>>>>>>>>> representation of the concrete workflow has two parts, >>>>>>>>>>>>> *initializer* and the *executor*. >>>>>>>>>>>>> >>>>>>>>>>>>> If its BPEL based workflows the initializer can be used to >>>>>>>>>>>>> initialize the BPEL and deploy it in the corresponding BPEL >>>>>>>>>>>>> engine. >>>>>>>>>>>>> >>>>>>>>>>>>> And the executor will execute the workflow in runtime. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. *Attachment Point* - you should be able to attach a >>>>>>>>>>>>> workflow to an *Attachment Point *and will get executed in >>>>>>>>>>>>> runtime when a request hits the corresponding *Attachment >>>>>>>>>>>>> Point*. >>>>>>>>>>>>> >>>>>>>>>>>>> Some examples of *Attachment Points* : add_user, delete_user, >>>>>>>>>>>>> add_role, add_xacml_policy, update_xacml_policy. >>>>>>>>>>>>> >>>>>>>>>>>>> *Attachment Points* - are independent from the *workflow*. >>>>>>>>>>>>> >>>>>>>>>>>>> *Attachment Points* are introduced into system via an OSGi >>>>>>>>>>>>> service. For example user_add, user_update, role_add - all those >>>>>>>>>>>>> Attachment >>>>>>>>>>>>> Points are announced into the system by a >>>>>>>>>>>>> UserManagerOperationListner. >>>>>>>>>>>>> >>>>>>>>>>>>> *Attachment Points *can be developed and deployed >>>>>>>>>>>>> independently. Once the system discovers the availability of an >>>>>>>>>>>>> *Attachment >>>>>>>>>>>>> Point *- it will display that to the user - so he can engage >>>>>>>>>>>>> and workflow to that *Attachment Point.* >>>>>>>>>>>>> >>>>>>>>>>>>> 3. *Attachment Point Template* >>>>>>>>>>>>> >>>>>>>>>>>>> These are coupled to specific* Attachment Points*. For >>>>>>>>>>>>> example, the *Attachment Point Template *- associated with >>>>>>>>>>>>> the user_add *Attachment Point* may look like following. >>>>>>>>>>>>> >>>>>>>>>>>>> *user match : <reg-ex>* >>>>>>>>>>>>> >>>>>>>>>>>>> Now the *Attachment Point* will invoke the associated >>>>>>>>>>>>> workflow executor only if the above criteria is met. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 4. *Workflow Template *: These templates should be announced >>>>>>>>>>>>> to the system along with the *workflow* implementation. This >>>>>>>>>>>>> template is independent from the *Attachment Point Template*. >>>>>>>>>>>>> This tell how to configure the workflow. With this approach you >>>>>>>>>>>>> can have >>>>>>>>>>>>> the same work flow - but configured in different ways based on >>>>>>>>>>>>> the* >>>>>>>>>>>>> Attachment Point*. >>>>>>>>>>>>> >>>>>>>>>>>>> Once example could be: >>>>>>>>>>>>> >>>>>>>>>>>>> Step-1 Approvers : <role1> OR <role2> AND user1 >>>>>>>>>>>>> Step-2 Approvers : <role3> OR <role4> AND user3 >>>>>>>>>>>>> >>>>>>>>>>>>> likewise... >>>>>>>>>>>>> >>>>>>>>>>>>> Okay - so far everything discussed above are related to the >>>>>>>>>>>>> core framework design. >>>>>>>>>>>>> >>>>>>>>>>>>> In IS 5.1.0 we need to have a concrete implementation of >>>>>>>>>>>>> followings.. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. *Attachment Points*- for all user / role related >>>>>>>>>>>>> operations. >>>>>>>>>>>>> 2. *Attachment Point Templates* - for all user / role >>>>>>>>>>>>> related operations. >>>>>>>>>>>>> 3. *Workflow* - initiator and executor for WSO2 BPS BPEL >>>>>>>>>>>>> implementation - and concrete multi-step approval BPEL workflow. >>>>>>>>>>>>> 4. *Workflow Templates*: A template for the multi-step >>>>>>>>>>>>> approval BPEL workflow >>>>>>>>>>>>> >>>>>>>>>>>>> Please let me know if you have any doubts or suggestions.. >>>>>>>>>>>>> also Johann/Pulsathi please verify whether the implementation is >>>>>>>>>>>>> done >>>>>>>>>>>>> according to this. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>> Prabath >>>>>>>>>>>>> >>>>>>>>>>>>> Twitter : @prabath >>>>>>>>>>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>>>>>>>>>>> >>>>>>>>>>>>> Mobile : +1 650 625 7950 >>>>>>>>>>>>> >>>>>>>>>>>>> http://blog.facilelogin.com >>>>>>>>>>>>> http://blog.api-security.org >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Thanks & Regards, >>>>>>>>>>> Prabath >>>>>>>>>>> >>>>>>>>>>> Twitter : @prabath >>>>>>>>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>>>>>>>>> >>>>>>>>>>> Mobile : +1 650 625 7950 >>>>>>>>>>> >>>>>>>>>>> http://blog.facilelogin.com >>>>>>>>>>> http://blog.api-security.org >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> /sumedha >>>>>>>>>> m: +94 773017743 >>>>>>>>>> b : bit.ly/sumedha >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> Architecture@wso2.org >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks & Regards, >>>>>>>>> Prabath >>>>>>>>> >>>>>>>>> Twitter : @prabath >>>>>>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>>>>>>> >>>>>>>>> Mobile : +1 650 625 7950 >>>>>>>>> >>>>>>>>> http://blog.facilelogin.com >>>>>>>>> http://blog.api-security.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks & Regards, >>>>>>>> Prabath >>>>>>>> >>>>>>>> Twitter : @prabath >>>>>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>>>>>> >>>>>>>> Mobile : +1 650 625 7950 >>>>>>>> >>>>>>>> http://blog.facilelogin.com >>>>>>>> http://blog.api-security.org >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Prabath >>>>> >>>>> Twitter : @prabath >>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>>> >>>>> Mobile : +1 650 625 7950 >>>>> >>>>> http://blog.facilelogin.com >>>>> http://blog.api-security.org >>>>> >>>> >>>> >>> >> >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
