I agree, +1 for a form-based approach. Being able to make changes there and observe the output BPEL would help users learn the format and structure.
Thanks, Colin Roy-Ehri Software Engineer *WSO2, Inc. : wso2.com <http://wso2.com/>* *Mobile* : 812-219-6517 On Sat, Apr 25, 2015 at 6:07 AM, Frank Leymann <[email protected]> wrote: > Dear Pulasthi, > > having a way to define simple BPEL processes in a form-based manner would > be great! Do you have some details on this? > > > Best regards, > Frank > > 2015-04-20 8:42 GMT+02:00 Pulasthi Mahawithana <[email protected]>: > >> Hi Frank, >> >> We thought of having a simple form based approach at user end. We will >> use some BPELs as templates and get the inputs from a form to customize it. >> >> On Sat, Apr 11, 2015 at 8:02 PM, Frank Leymann <[email protected]> wrote: >> >>> Hi Pulasthi, >>> >>> when you have "users without BPEL knowledge" in mind, you assume that >>> these users have programming skills, correct? I.e. that they provide the >>> "workflow process" in JavaScript, for example, correct? >>> >>> Or do you work on a new very easy-to-use workflow language? >>> >>> >>> Best regards, >>> Frank >>> >>> 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana <[email protected]>: >>> >>>> Hi Frank, >>>> >>>> I sent a separate mail[1] with the architecture. Our main objective was >>>> to provide the workflow support for the events in IS and [1] was designed >>>> to address that. Furthermore we plan to provide a way to easily configure a >>>> workflow process and deploy it at BPS (for the users without BPEL >>>> knowlege). The work for that is in progress and we will update with the >>>> details soon. >>>> >>>> [1] [Architecture] Generic workflow support >>>> >>>> On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann <[email protected]> wrote: >>>> >>>>> Hi Pulasthi, hi Tanja, >>>>> >>>>> can you provide a consolidated architecture figure, please? Can you >>>>> also position in your architecture BPS? I assume the requirements you >>>>> address by your architecture is the ability to create an "on-ramp >>>>> workflow" >>>>> for ES, AM,... in a "fast" way, correct? >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> Best regards, >>>>> Frank >>>>> >>>>> 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana <[email protected]>: >>>>> >>>>>> Hi Tanya, >>>>>> >>>>>> The actual architecture is bit different from the one you mentioned >>>>>> here (I'll send a separate mail with details). The executors are >>>>>> responsible only for executing workflow in some manner (can be BPEL, Web >>>>>> Service or even some java code), and they can be registered as OSGI >>>>>> services. The persisting is done by the WorkflowManager before calling >>>>>> the >>>>>> executor. >>>>>> >>>>>> The WorkflowRequestHandler is the one responsible for creating >>>>>> workflow requests for an event, and handling the callback for the same >>>>>> event. So, what you said can be achieved at this point by customizing the >>>>>> workflow request creation (persist somewhere and provide link in workflow >>>>>> request). Since you create asset disabled and enable it after workflow >>>>>> completion it will work. However there are some events where we have to >>>>>> wait till the workflow completion to perform the actual action. That was >>>>>> the reason to persist the request. Also note that all workflow parameters >>>>>> are not set to the workflow executor. We can filter out parameters that >>>>>> won't be needed at workflow (I will send those details in a separate >>>>>> mail). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Johann and all, >>>>>>> >>>>>>> As per the offline chat with Pulasthi, the executor serialize the >>>>>>> workflow info and save in the database before calling the bpel service. >>>>>>> (see the diagram below) >>>>>>> >>>>>>> >>>>>>> So in our case if we are to use this component, we will have to do >>>>>>> a network call with all the information for the workflow request (might >>>>>>> include large files such as images and videos etc as admin needs to >>>>>>> approve >>>>>>> them) >>>>>>> Also at the call back we have to resend the same info back. >>>>>>> >>>>>>> We thought it would be more convienient and performance friendly, if >>>>>>> we persist those information at our end and provide an endpoint where >>>>>>> the >>>>>>> admin can access all the information. >>>>>>> >>>>>>> For an example, say asset creation process. >>>>>>> Once the user fills the asset creation form, we will persist that >>>>>>> info in a database with a flag so that it won't be visible in the store >>>>>>> to >>>>>>> the other users. And when triggering the workflow we send an endpoint >>>>>>> with >>>>>>> a token and admin can view the created asset info with that endpoint. >>>>>>> Admin >>>>>>> will be redirected to store to display the newly created (pending) >>>>>>> asset. >>>>>>> With that we don't need to worry about sending/rendering images at the >>>>>>> workflow admin application. >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> Thanks, >>>>>>> Tanya >>>>>>> >>>>>>> On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi Johann, >>>>>>>> >>>>>>>> Thanks for the response. >>>>>>>> IMO it is better if we can make the WorkflowRequestDAO more generic >>>>>>>> where we can plug any storing mechanism. WDYT? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tanya >>>>>>>> >>>>>>>> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Tanya, >>>>>>>>> >>>>>>>>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> We are in the process of implementing the workflow support for ES >>>>>>>>>> and came across the $Subject. >>>>>>>>>> Although many products have worflow support, seems there is no >>>>>>>>>> generic component to achieve this. >>>>>>>>>> >>>>>>>>>> The workflow executor for APIM [1] cannot be used platform wide >>>>>>>>>> since they pass the ApiMgtDAO to execute method in their executor. >>>>>>>>>> >>>>>>>>>> Similar issue is there with the IS workflow executor where they >>>>>>>>>> preserve the workflow information in the identity database [2] (refer >>>>>>>>>> addWorkflowEntry method) >>>>>>>>>> >>>>>>>>> >>>>>>>>> The work flow component that was designed for IS was designed with >>>>>>>>> the intension of extensibility. The workflow components are not >>>>>>>>> coupled in >>>>>>>>> anyway to identity components. If there is anything which is blocking >>>>>>>>> you >>>>>>>>> from achieving what you need then we will like to know about it so >>>>>>>>> that we >>>>>>>>> can fix our design. >>>>>>>>> >>>>>>>>> >>>>>>>>>> IMO other products should be able to use their own workflow info >>>>>>>>>> preservation mechanism. >>>>>>>>>> Ex: To store in the registry >>>>>>>>>> To store in a database >>>>>>>>>> Say in ES, we want to provide workflow support for asset >>>>>>>>>> creation. Storing asset level info in Identity database doesn't make >>>>>>>>>> sense. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Don't think of it as Identity database. Think of it as a database >>>>>>>>> coming from another feature repository. It can be any product like >>>>>>>>> IS. If >>>>>>>>> the same workflow component was developed by APIM then it would be AM_ >>>>>>>>> tables. Apart from the naming convention the functionality is generic >>>>>>>>> and >>>>>>>>> extensible. The table naming convention comes from which product team >>>>>>>>> develops it, thats all. >>>>>>>>> >>>>>>>>> Using Identity database in ES is not wrong. If you are installing >>>>>>>>> IS feature you have to install the database scripts also. I know >>>>>>>>> previously >>>>>>>>> APIM did the same mistake of copying the identity tables into apim >>>>>>>>> scripts >>>>>>>>> and not executing identity scripts. I know how much duplication it >>>>>>>>> made and >>>>>>>>> how much of problems we ran into. I am -1 on that. >>>>>>>>> >>>>>>>>> If you have a strong reason to move away from database, and use >>>>>>>>> registry then we need to think about making the data access layer >>>>>>>>> extensible, which is open for discussion. >>>>>>>>> >>>>>>>>> P.S. I know we haven't sent a mail to architecture regarding the >>>>>>>>> workflow component design. Will do soon. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Johann. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Appreciate your feedback. >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java >>>>>>>>>> [2] >>>>>>>>>> https://github.com/pulasthi7/carbon-identity/blob/feature/workflow-support/components/workflows/org.wso2.carbon.workflow.mgt/src/main/java/org/wso2/carbon/workflow/mgt/dao/WorkflowRequestDAO.java >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tanya >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Tanya Madurapperuma >>>>>>>>>> >>>>>>>>>> Software Engineer, >>>>>>>>>> WSO2 Inc. : wso2.com >>>>>>>>>> Mobile : +94718184439 >>>>>>>>>> Blog : http://tanyamadurapperuma.blogspot.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks & Regards, >>>>>>>>> >>>>>>>>> *Johann Dilantha Nallathamby* >>>>>>>>> Associate Technical Lead & Product Lead of WSO2 Identity Server >>>>>>>>> Integration Technologies Team >>>>>>>>> WSO2, Inc. >>>>>>>>> lean.enterprise.middleware >>>>>>>>> >>>>>>>>> Mobile - *+94777776950* >>>>>>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Tanya Madurapperuma >>>>>>>> >>>>>>>> Software Engineer, >>>>>>>> WSO2 Inc. : wso2.com >>>>>>>> Mobile : +94718184439 >>>>>>>> Blog : http://tanyamadurapperuma.blogspot.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Tanya Madurapperuma >>>>>>> >>>>>>> Software Engineer, >>>>>>> WSO2 Inc. : wso2.com >>>>>>> Mobile : +94718184439 >>>>>>> Blog : http://tanyamadurapperuma.blogspot.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Pulasthi Mahawithana* >>>>>> Software Engineer >>>>>> WSO2 Inc., http://wso2.com/ >>>>>> Mobile: +94-71-5179022 >>>>>> Blog: http://blog.pulasthi.org >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Pulasthi Mahawithana* >>>> Software Engineer >>>> WSO2 Inc., http://wso2.com/ >>>> Mobile: +94-71-5179022 >>>> Blog: http://blog.pulasthi.org >>>> >>> >>> >> >> >> -- >> *Pulasthi Mahawithana* >> Software Engineer >> WSO2 Inc., http://wso2.com/ >> Mobile: +94-71-5179022 >> Blog: http://blog.pulasthi.org >> > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
