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

Reply via email to