Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory

[Fathima Dilhasha]

Hi Manjula,

Thanks for the feedback.

Regarding 1. I agree with you that we can use role based mapping to
restrict accessibility to each project.
But we will be using the admin user to create apps in the JIRA instance.
Given that, I can't still find a way to solve the problem of having similar
named projects for two or more tenants.

Regarding 2. Are u referring to scenario 3 in the diagram? That is for
creating a project in an App Factory defined instance ? If so +1, an admin
user can be maintained to do that.

Thanks.
Regards,
Dilhasha

*M.N.F. Dilhasha*
Software Engineering Intern | *WSO2 Inc.*

email   :
*dilha...@wso2.com *mobile : +94 77 8449321

On Fri, Apr 3, 2015 at 9:44 AM, Manjula Rathnayake 
wrote:

> Hi all,
>
> This is regarding using a single JIRA instance for all apps in all tenants.
> 1. Using the role based access control, we can restrict users seeing other
> tenant applications.
> ex: foo tenant users are assigned to foo_role in jira.
> @Dilhasha, Please have a look at jira role mapping to jira projects.
>
> 2. Regarding the login issue, we can use a predefined system user in jira
> to create projects, assign users on behalf of other users.
>
> thank you.
>
>
> On Fri, Apr 3, 2015 at 12:50 AM, Fathima Dilhasha 
> wrote:
>
>> Hi,
>>
>> I have specified a flow chart and my suggestions regarding the scenarios
>> in [1].
>> 
>>
>> Please comment and point out any mistakes and suggest any other options
>> we can consider.
>>
>> [1]
>> https://docs.google.com/document/d/1qDRObBh4CLnO755TgyINWAey9c1X3W1BFI-hgkh9rlQ/edit?usp=sharing
>>
>> Thanks.
>> Regards,
>> Dilhasha
>>
>> *M.N.F. Dilhasha*
>> Software Engineering Intern | *WSO2 Inc.*
>>
>> email   :
>> *dilha...@wso2.com *mobile : +94 77 8449321
>>
>> On Wed, Apr 1, 2015 at 10:38 PM, Anuruddha Premalal 
>> wrote:
>>
>>> Hi Punnadi,
>>>
>>> We cannot store credentials in a configuration file since this is a per
>>> application configuration.
>>>
>>> Regards,
>>> Anuruddha.
>>>
>>> On Wed, Apr 1, 2015 at 9:43 AM, Punnadi Gunarathna 
>>> wrote:
>>>
 Hi Fathima,

 Can't we store the credentials in a configuration file, which are
 required  to create the JIRA instance?
 If that is possible, We can make use of Secure Vault to secure the
 plain text password.
 WDYT?
 On Apr 1, 2015 8:04 PM, "Fathima Dilhasha"  wrote:

> Hi,
>
> Okay, now I understand your first question. AFAIK, there is no way to
> customize authentication behavior, in a way that we can allow to have
> similar project names for different tenants. We can have groups of users
> and manage visibility of each project on a single JIRA instance, among
> users in that instance as specified in [1]
> 
> .
>
> What you are suggesting is to map a user in JIRA to a particular
> tenant in App Factory, is it?
>
> [1]
> https://confluence.atlassian.com/display/Cloud/Managing+project+visibility
>
> Thanks.
> Regards,
> Dilhasha
>
> *M.N.F. Dilhasha*
> Software Engineering Intern | *WSO2 Inc.*
>
> email   :
> *dilha...@wso2.com *mobile : +94 77 8449321
>
> On Wed, Apr 1, 2015 at 7:56 PM,  wrote:
>
>>  /s/pretty/pre
>>
>> Thanks & Regards
>> Danushka Fernando
>> Software Engineer
>> WSO2 inc. http://wso2.com/
>> Mobile : +94716332729
>>
>> *From:* Danushka Fernando 
>> *Sent:* Wednesday, April 1, 2015 7:30 PM
>> *To:* architecture 
>>
>> I understand that fact. What I was asking is can we customize the
>> authentication behavior. Are there extension points. Any way if there are
>> not you can have a pretty defined user for each tenant same as we do for
>> jenkins.
>>
>> Thanks & Regards
>> Danushka Fernando
>> Software Engineer
>> WSO2 inc. http://wso2.com/
>> Mobile : +94716332729
>>
>>
>> On Apr 1, 2015 7:14 PM, "Fathima Dilhasha"  wrote:
>>
>>> Hi danushka,
>>>
>>> The issue is with how the SOAP API for JIRA works. It requires admin
>>> username and password to establish a SOAP session, to create a project 
>>> via
>>> the SOAP API.
>>> If we are to create a project on a user specified JIRA instance, the
>>> username and password  (For that particular JIRA instance) are required.
>>>
>>> Thanks.
>>> Regards,
>>> Dilhasha
>>>
>>>
>>> *M.N.F. Dilhasha*
>>> Software Engineering Intern | *WSO2 Inc.*
>>>
>>> email   :
>>> *dilha...@wso2.com *mobile : +94 77 8449321
>>>
>>> On Wed, Apr 1, 2015 at 6:07 PM, Danushka Fernando <
>>> danush...@wso2.com> wrote:
>>>
 Hi
 Are there extension points in jira where we can extend
 authentication mechanism. BTW password is something

Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory

[Manjula Rathnayake]

Hi all,

This is regarding using a single JIRA instance for all apps in all tenants.
1. Using the role based access control, we can restrict users seeing other
tenant applications.
ex: foo tenant users are assigned to foo_role in jira.
@Dilhasha, Please have a look at jira role mapping to jira projects.

2. Regarding the login issue, we can use a predefined system user in jira
to create projects, assign users on behalf of other users.

thank you.


On Fri, Apr 3, 2015 at 12:50 AM, Fathima Dilhasha  wrote:

> Hi,
>
> I have specified a flow chart and my suggestions regarding the scenarios
> in [1].
> 
>
> Please comment and point out any mistakes and suggest any other options we
> can consider.
>
> [1]
> https://docs.google.com/document/d/1qDRObBh4CLnO755TgyINWAey9c1X3W1BFI-hgkh9rlQ/edit?usp=sharing
>
> Thanks.
> Regards,
> Dilhasha
>
> *M.N.F. Dilhasha*
> Software Engineering Intern | *WSO2 Inc.*
>
> email   :
> *dilha...@wso2.com *mobile : +94 77 8449321
>
> On Wed, Apr 1, 2015 at 10:38 PM, Anuruddha Premalal 
> wrote:
>
>> Hi Punnadi,
>>
>> We cannot store credentials in a configuration file since this is a per
>> application configuration.
>>
>> Regards,
>> Anuruddha.
>>
>> On Wed, Apr 1, 2015 at 9:43 AM, Punnadi Gunarathna 
>> wrote:
>>
>>> Hi Fathima,
>>>
>>> Can't we store the credentials in a configuration file, which are
>>> required  to create the JIRA instance?
>>> If that is possible, We can make use of Secure Vault to secure the plain
>>> text password.
>>> WDYT?
>>> On Apr 1, 2015 8:04 PM, "Fathima Dilhasha"  wrote:
>>>
 Hi,

 Okay, now I understand your first question. AFAIK, there is no way to
 customize authentication behavior, in a way that we can allow to have
 similar project names for different tenants. We can have groups of users
 and manage visibility of each project on a single JIRA instance, among
 users in that instance as specified in [1]
 
 .

 What you are suggesting is to map a user in JIRA to a particular tenant
 in App Factory, is it?

 [1]
 https://confluence.atlassian.com/display/Cloud/Managing+project+visibility

 Thanks.
 Regards,
 Dilhasha

 *M.N.F. Dilhasha*
 Software Engineering Intern | *WSO2 Inc.*

 email   :
 *dilha...@wso2.com *mobile : +94 77 8449321

 On Wed, Apr 1, 2015 at 7:56 PM,  wrote:

>  /s/pretty/pre
>
> Thanks & Regards
> Danushka Fernando
> Software Engineer
> WSO2 inc. http://wso2.com/
> Mobile : +94716332729
>
> *From:* Danushka Fernando 
> *Sent:* Wednesday, April 1, 2015 7:30 PM
> *To:* architecture 
>
> I understand that fact. What I was asking is can we customize the
> authentication behavior. Are there extension points. Any way if there are
> not you can have a pretty defined user for each tenant same as we do for
> jenkins.
>
> Thanks & Regards
> Danushka Fernando
> Software Engineer
> WSO2 inc. http://wso2.com/
> Mobile : +94716332729
>
>
> On Apr 1, 2015 7:14 PM, "Fathima Dilhasha"  wrote:
>
>> Hi danushka,
>>
>> The issue is with how the SOAP API for JIRA works. It requires admin
>> username and password to establish a SOAP session, to create a project 
>> via
>> the SOAP API.
>> If we are to create a project on a user specified JIRA instance, the
>> username and password  (For that particular JIRA instance) are required.
>>
>> Thanks.
>> Regards,
>> Dilhasha
>>
>>
>> *M.N.F. Dilhasha*
>> Software Engineering Intern | *WSO2 Inc.*
>>
>> email   :
>> *dilha...@wso2.com *mobile : +94 77 8449321
>>
>> On Wed, Apr 1, 2015 at 6:07 PM, Danushka Fernando > > wrote:
>>
>>> Hi
>>> Are there extension points in jira where we can extend
>>> authentication mechanism. BTW password is something we don't have. We 
>>> have
>>> only username.
>>>
>>> Thanks & Regards
>>> Danushka Fernando
>>> Software Engineer
>>> WSO2 inc. http://wso2.com/
>>> Mobile : +94716332729
>>>
>>>
>>> On Apr 1, 2015 4:25 PM, "Fathima Dilhasha" 
>>> wrote:
>>>
 Hi,

 I need few other clarifications as well.

 So far,
 I have been successful in creating a JIRA project via SOAP only.
 This SOAP client requires username and password for the Jira instance.
 So, if we want to allow users to create projects in their JIRA
 instance, we will have to request for username and password for JIRA
 instance.

 Is that okay?
 We will not store any username or password, but we'll need it to
 create a SOAP session.

 WDYT?

>>>

Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory

[Fathima Dilhasha]

Hi,

I have specified a flow chart and my suggestions regarding the scenarios in
[1].


Please comment and point out any mistakes and suggest any other options we
can consider.

[1]
https://docs.google.com/document/d/1qDRObBh4CLnO755TgyINWAey9c1X3W1BFI-hgkh9rlQ/edit?usp=sharing

Thanks.
Regards,
Dilhasha

*M.N.F. Dilhasha*
Software Engineering Intern | *WSO2 Inc.*

email   :
*dilha...@wso2.com *mobile : +94 77 8449321

On Wed, Apr 1, 2015 at 10:38 PM, Anuruddha Premalal 
wrote:

> Hi Punnadi,
>
> We cannot store credentials in a configuration file since this is a per
> application configuration.
>
> Regards,
> Anuruddha.
>
> On Wed, Apr 1, 2015 at 9:43 AM, Punnadi Gunarathna 
> wrote:
>
>> Hi Fathima,
>>
>> Can't we store the credentials in a configuration file, which are
>> required  to create the JIRA instance?
>> If that is possible, We can make use of Secure Vault to secure the plain
>> text password.
>> WDYT?
>> On Apr 1, 2015 8:04 PM, "Fathima Dilhasha"  wrote:
>>
>>> Hi,
>>>
>>> Okay, now I understand your first question. AFAIK, there is no way to
>>> customize authentication behavior, in a way that we can allow to have
>>> similar project names for different tenants. We can have groups of users
>>> and manage visibility of each project on a single JIRA instance, among
>>> users in that instance as specified in [1]
>>> 
>>> .
>>>
>>> What you are suggesting is to map a user in JIRA to a particular tenant
>>> in App Factory, is it?
>>>
>>> [1]
>>> https://confluence.atlassian.com/display/Cloud/Managing+project+visibility
>>>
>>> Thanks.
>>> Regards,
>>> Dilhasha
>>>
>>> *M.N.F. Dilhasha*
>>> Software Engineering Intern | *WSO2 Inc.*
>>>
>>> email   :
>>> *dilha...@wso2.com *mobile : +94 77 8449321
>>>
>>> On Wed, Apr 1, 2015 at 7:56 PM,  wrote:
>>>
  /s/pretty/pre

 Thanks & Regards
 Danushka Fernando
 Software Engineer
 WSO2 inc. http://wso2.com/
 Mobile : +94716332729

 *From:* Danushka Fernando 
 *Sent:* Wednesday, April 1, 2015 7:30 PM
 *To:* architecture 

 I understand that fact. What I was asking is can we customize the
 authentication behavior. Are there extension points. Any way if there are
 not you can have a pretty defined user for each tenant same as we do for
 jenkins.

 Thanks & Regards
 Danushka Fernando
 Software Engineer
 WSO2 inc. http://wso2.com/
 Mobile : +94716332729


 On Apr 1, 2015 7:14 PM, "Fathima Dilhasha"  wrote:

> Hi danushka,
>
> The issue is with how the SOAP API for JIRA works. It requires admin
> username and password to establish a SOAP session, to create a project via
> the SOAP API.
> If we are to create a project on a user specified JIRA instance, the
> username and password  (For that particular JIRA instance) are required.
>
> Thanks.
> Regards,
> Dilhasha
>
>
> *M.N.F. Dilhasha*
> Software Engineering Intern | *WSO2 Inc.*
>
> email   :
> *dilha...@wso2.com *mobile : +94 77 8449321
>
> On Wed, Apr 1, 2015 at 6:07 PM, Danushka Fernando 
> wrote:
>
>> Hi
>> Are there extension points in jira where we can extend authentication
>> mechanism. BTW password is something we don't have. We have only 
>> username.
>>
>> Thanks & Regards
>> Danushka Fernando
>> Software Engineer
>> WSO2 inc. http://wso2.com/
>> Mobile : +94716332729
>>
>>
>> On Apr 1, 2015 4:25 PM, "Fathima Dilhasha"  wrote:
>>
>>> Hi,
>>>
>>> I need few other clarifications as well.
>>>
>>> So far,
>>> I have been successful in creating a JIRA project via SOAP only.
>>> This SOAP client requires username and password for the Jira instance.
>>> So, if we want to allow users to create projects in their JIRA
>>> instance, we will have to request for username and password for JIRA
>>> instance.
>>>
>>> Is that okay?
>>> We will not store any username or password, but we'll need it to
>>> create a SOAP session.
>>>
>>> WDYT?
>>>
>>> Thanks.
>>> Regards,
>>> Dilhasha
>>>
>>> *M.N.F. Dilhasha*
>>> Software Engineering Intern | *WSO2 Inc.*
>>>
>>> email   :
>>> *dilha...@wso2.com *mobile : +94 77 8449321
>>>
>>> On Wed, Apr 1, 2015 at 2:34 PM, Fathima Dilhasha 
>>> wrote:
>>>
 The prices for cloud and server instances of JIRA are the same as
 mentioned in [1]
 .

 [1]https://www.atlassian.com/software/jira/pricing/?tab=cloud

 Thanks.

 *M.N.F. Dilhasha*
 Software Engineering Intern | *WSO2 Inc.*

 email   :
 *dilha...

Re: [Architecture] Generic workflow executor across the platform

[Frank Leymann]

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 :

> 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 
> 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 
>> 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 
>>> wrote:
>>>
 Hi Tanya,

 On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
 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 in

Re: [Architecture] [G-Reg] Lifecycle transition view improvements in G-Reg publisher

[Isuruwan Herath]

+1 to change the  tag into . Please see the diff of
scxml.xsd to enable this.

--- wso2greg-5.0.0-SNAPSHOT/repository/resources/scxml.xsd 2015-03-10
21:13:38.0 +0530
+++ ../wso2greg-5.0.0-SNAPSHOT/repository/resources/scxml.xsd 2015-04-02
17:38:54.547890501 +0530
@@ -78,9 +78,21 @@
 
 
 
-
+ 
 
 
+
+

+

+

+

+

+

+


+

+
 
+

+
 

 

Thanks!
Isuruwan

On Thu, Apr 2, 2015 at 6:45 AM, Sagara Gunathunga  wrote:

>
> +1
>
> We used to have custom JSP for same purpose but that is not user friendly
> and hard to understand, I guess it was introduced to match with JSP based
> admin console. Now we have GC with better UI experience and ES technology
> hence it's time to simplify this model so that user only define how many
> inputs and what are the types of these inputs  etc. while ES render nice UI
> based on user specification.
>
> One suggestion is instead of ,  is much meaningful
> to me also Isuruwan please mention full spec as XSD diff.
>
> Thanks !
>
> On Wed, Apr 1, 2015 at 11:29 PM, Isuruwan Herath 
> wrote:
>
>> Hi,
>>
>> In current g-reg we have the option of giving a transition UI for the
>> lifecycle transition in the management console. This UI is used to take the
>> user inputs for the executor logic.
>>
>> To incorporate this feature into the publisher view, we have come up with
>> the proposal of embedding a set of new elements in the LC definition. This
>> will be parsed from the publisher side and it will display a rendered page
>> for user inputs. To enable this we will modify the scxml.xsd and the user
>> will have to set the input parameters as follows:
>>
>> 
>> > class="org.wso2.carbon.governance.registry.extensions.executors.ServiceVersionExecutor">
>> **
>> *   *
>> *   > type="text-area"/>*
>> **
>> > value="/_system/governance/trunk/{@resourcePath}/{@version}/{@resourceName}"/>
>> > value="/_system/governance/branches/testing/{@resourcePath}/{@version}/{@resourceName}"/>
>> > value="application/vnd.wso2-service+xml"/>
>> > value="application/wsdl+xml"/>
>> > value="application/vnd.wso2.endpoint"/>
>> 
>> 
>> Appreciate any feedback about this approach.
>>
>> Thanks!
>> Isuruwan
>>
>> --
>> Isuruwan Herath
>> Technical Lead
>>
>> Contact: +94 776 273 296
>>
>
>
>
> --
> Sagara Gunathunga
>
> Senior Technical Lead; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services;http://ws.apache.org/
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
>
>


-- 
Isuruwan Herath
Technical Lead

Contact: +94 776 273 296
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generic workflow executor across the platform

[Pulasthi Mahawithana]

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  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 
> 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 
>> wrote:
>>
>>> Hi Tanya,
>>>
>>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
>>> 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.
>>>
>

Re: [Architecture] Generic workflow executor across the platform

[Tanya Madurapperuma]

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  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 
> wrote:
>
>> Hi Tanya,
>>
>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
>> 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 - *+9476950*
>> Blog - *http://nallaa.wordpress.com *
>>
>
>
>
> --
> Tanya Madurapperuma
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439
> Blog : http://tanyamadurapperuma.blogspot.com
>



-- 
Tanya Madurapperuma

Software Engineer,