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