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
