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 <fr...@wso2.com> 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 <pulast...@wso2.com>: > >> 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 <fr...@wso2.com> 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 <pulast...@wso2.com>: >>> >>>> 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 <ta...@wso2.com> >>>> 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 <ta...@wso2.com> >>>>> 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 <joh...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Tanya, >>>>>>> >>>>>>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma <ta...@wso2.com >>>>>>> > 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 >>>> 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 >>> >>> >> >> >> -- >> *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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
