Hi Pulasthi, you mentioned only BPS/BPEL-engine. What about the BPS/BPMN-activiti-engine? Should it not a prefered way to define workflows?
best regards Manfred 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 > > _______________________________________________ > 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
