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 >> >> >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
