Hi Manfred, The executor can be used with both. "BPEL only" support is for the tool we plan to provide for creation and deployment of simple workflows. We will consider extending it to support BPMN also when the next WSO2 BPS version is released with BPMN support.
On Mon, Apr 6, 2015 at 12:11 AM, Manfred Herrmann < [email protected]> wrote: > 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 > > -- *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
