Hi Pulasthi, thank you for info about BPMN implementation.
Is the workflow executor database a datastore for workflow-data at product-level? The called workflow engine stores the workflow-data for execution in BPS, right? This leads to redundant workflow-data. Why should/can I not install "BPS-frontent-features" in a product like IS or APIM? best regards Manfred 2015-04-06 14:42 GMT+02:00 Pulasthi Mahawithana <[email protected]>: > 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
