Dear all, I won't be in Sri Lanka first week of August as originally planned because of WSO2Con canceled. Should we set up a call during that week to review and discuss the next steps?
I would appreciate it! Best regards, Frank 2015-07-15 17:29 GMT+02:00 Isabelle Mauny <isabe...@wso2.com>: > All, > > I am still not clear on how a customer would add > A) a workflow template > B) the corresponding implementation ( in BPEL or something else) > > So yes +1 to review and enhance/standardize across the platform as > necessary. > > Isabelle. > > On Wednesday, July 15, 2015, 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 >>>> >>>> >>> >> > > -- > > ------------------------------------------------------------------------------------- > *Isabelle Mauny* > VP, Product Management - WSO2, Inc. - http://wso2.com/ > email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri > Lanka) +94 (0)774777663 > Landline: +1 (650) 745 4499 (USA) or +94 (11) 214 534 (SL) Extension : > 7302 > > > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
