Re: [Architecture] Migration approach for APIM 2.6.0 to 3.0.0

[Samitha Chathuranga]

Hi,

@Amila Maha Arachchi 

> For me, writing a separate API is easier for us and the users both.
>
As Nuwan has described above, supporting to be migrated from any version
(2.1.0/2.2.0/2.5.0..) can  be a complex and error prone task and so not
healthy for us. Mainly it would need adding new REST APIs or changing
existing APIs to all these older versions and that is cumbersome.

@Dushan Abeyruwan 

> The other question is; its better CLI tool having a verbose option to be
> implemented.  maybe through (-v) which prints all the necessary details
> around the migration state rather someone to enable that via log4j
> separately.
>
Verbose mode is already configured in import-export tool and so available
for all the commands. So it is upto us to drop some logs from non-verbose
mode and include only in verbose mode. My feeling is that it is better to
log as much information in a non verbose mode too, because that would help
us dig through errors by default. Migration is not something done always
hence the logs are not a thing which would continuously pile up. And if we
limit some logs to verbose mode, then we may require to request our
customers to enable verbose mode and do migration again and send the logs.

Regards,
Samitha

On Fri, Sep 21, 2018 at 10:02 AM Nuwan Dias  wrote:

> Let's take this incrementally. We need to do lots of changes on every
> version to support this kind of migration. In addition to that the changes
> between the versions are not identical. So every migration needs duplicated
> work and testing to be carried out. Plus whatever changes we do to each of
> those old version have to shipped as WUM updates and the clients needs to
> get those WUM updates for proceeding. We all know that allowing too many
> options ends up with too many problems, in the end of the day ending up
> with too many frustrated customers.
>
> The migration to API Manager 3.0 is going to be the most sophisticated API
> Manager migration we have done so far. Given our history of migration
> experiences trying to do too many thing first up is not a good idea. So I
> really want us to focus on 2.6 to 3.0 migration and make it really smooth
> and robust before attempting anything else.
>
> Thanks,
> NuwanD.
>
> On Fri, Sep 21, 2018 at 9:51 AM Amila Maha Arachchi 
> wrote:
>
>> Dushan has a very good point (but I think Dushan has or expressed it
>> wrong). It seems that it has been decided to go with Approach 1. i.e.
>> adding the migration capabilities to the existing REST apis of 2.6.0. This
>> means, people using other versions such as 2.1.0, 2.5.0 wont be able to
>> migrate to 3.0 without coming to 2.6.0.
>>
>> If we had a separate API which can export from any version (lets say from
>> any version from 2.1.0 upwards) and import to 3.0, that is the ideal
>> solution. It is easy to fix issues as well. It is true that this tool will
>> be thrown away after sometime. But, we shouldn't expect all the code we
>> write to be used forever.
>>
>> For me, writing a separate API is easier for us and the users both.
>>
>> On Fri, Sep 21, 2018 at 3:05 AM Dushan Abeyruwan  wrote:
>>
>>> Hi Samitha,
>>>   Are we proceeding with the approach-2? if so, how does such migration
>>> approach benefited for someone who is trying to migrate from 2.5.0 or
>>> before? will there be any intermittent steps or this tool would take care
>>> of such intermittent steps?
>>>
>>> The other question is; its better CLI tool having a verbose option to be
>>> implemented.  maybe through (-v) which prints all the necessary details
>>> around the migration state rather someone to enable that via log4j
>>> separately.
>>>
>>> Cheers,
>>> Dushan
>>>
>>> On Wed, Sep 19, 2018 at 9:50 PM, Samitha Chathuranga 
>>> wrote:
>>>
 Hi all,

 Following is an update on the current progress of this task.

 Tasks done upto:

 1. 2.6.0 REST API and implementation changes.

- Change GET applications REST API to enable get all apps of a
given tenant too, instead of all tenants
- Support cross tenant APIs GET for migration only for super admin
- Return application keys too (conditionally) to use for migration
- Support cross tenant application export for migration for super
admin

 2. Export APIs as a bulk with export-apis command with import-export
 tool

- All the APIs are exported by single command but implementation is
as iterative api export, set by set separately (export sets of APIs
separately, instead of exporting all at once)
- API export resume capability (error handling) with the support of
two files migration-apis-export-metadata.yaml and last-succeeded-api.log
- *--force* flag with *export-apis* command will forcefully export
all the apis from beginning, disregarding the fact that all/some apis 
 were
exported successfully by last execution of command.
- Able to skip exporting particular 

Re: [Architecture] [carbon-dashboards][widget-generation-wizard]Create an autocomplete search using widget generation wizard

[Ruwini Wijesiri]

Hi,

If we use the name 'UniversalWidget' instead of 'ParentRenderer' as shown
below, it  will eliminate the backward compatibility issue.


*-universal-widget*

*-vizgrammar-renderer*
*-search-renderer*

Appreciate your thoughts on this approach.

Thanks,
Regards,
Ruwini

On Fri, Sep 21, 2018 at 9:50 AM Ruwini Wijesiri  wrote:

> Hi Sajith,
>
> Thanks for the response.
>
> I'll proceed with this approach.
>
> Thanks,
> Regards,
> Ruwini
>
> On Fri, Sep 21, 2018 at 9:44 AM Sajith Ariyarathna 
> wrote:
>
>> +1 for 2nd approach.
>> +1 for suggested migration implementation.
>>
>> Thanks.
>>
>> On Fri, Sep 21, 2018 at 9:38 AM Ruwini Wijesiri  wrote:
>>
>>> Hi Tanya,
>>>
>>> Thank you for the response.
>>>
>>> I think its better to handle this at the dashboard level by making "
 *UniversalWidget*" a reserved word and replacing it with  "
 *vizgrammar-renderer" *in the Dashboard json before passing it to
 Golden Layout. So that customers don't need to bother about any additional
 migration effort.

>>>
>>> +1 for this.
>>>
>>> Thanks,
>>> Regards,
>>> Ruwini.
>>>
>>> On Fri, Sep 21, 2018 at 8:37 AM Tanya Madurapperuma 
>>> wrote:
>>>
 +1 for the second approach.

>>>
>>>
>>> --
>>> Ruwini Wijesiri
>>> Software Engineer,
>>> WSO2 Inc.
>>>
>>> Mobile : +94716133480
>>>
>>> 
>>>
>>
>>
>> --
>> Sajith Janaprasad Ariyarathna
>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>> 
>>
>
>
> --
> Ruwini Wijesiri
> Software Engineer,
> WSO2 Inc.
>
> Mobile : +94716133480
>
> 
>


-- 
Ruwini Wijesiri
Software Engineer,
WSO2 Inc.

Mobile : +94716133480


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Migration approach for APIM 2.6.0 to 3.0.0

[Nuwan Dias]

Let's take this incrementally. We need to do lots of changes on every
version to support this kind of migration. In addition to that the changes
between the versions are not identical. So every migration needs duplicated
work and testing to be carried out. Plus whatever changes we do to each of
those old version have to shipped as WUM updates and the clients needs to
get those WUM updates for proceeding. We all know that allowing too many
options ends up with too many problems, in the end of the day ending up
with too many frustrated customers.

The migration to API Manager 3.0 is going to be the most sophisticated API
Manager migration we have done so far. Given our history of migration
experiences trying to do too many thing first up is not a good idea. So I
really want us to focus on 2.6 to 3.0 migration and make it really smooth
and robust before attempting anything else.

Thanks,
NuwanD.

On Fri, Sep 21, 2018 at 9:51 AM Amila Maha Arachchi  wrote:

> Dushan has a very good point (but I think Dushan has or expressed it
> wrong). It seems that it has been decided to go with Approach 1. i.e.
> adding the migration capabilities to the existing REST apis of 2.6.0. This
> means, people using other versions such as 2.1.0, 2.5.0 wont be able to
> migrate to 3.0 without coming to 2.6.0.
>
> If we had a separate API which can export from any version (lets say from
> any version from 2.1.0 upwards) and import to 3.0, that is the ideal
> solution. It is easy to fix issues as well. It is true that this tool will
> be thrown away after sometime. But, we shouldn't expect all the code we
> write to be used forever.
>
> For me, writing a separate API is easier for us and the users both.
>
> On Fri, Sep 21, 2018 at 3:05 AM Dushan Abeyruwan  wrote:
>
>> Hi Samitha,
>>   Are we proceeding with the approach-2? if so, how does such migration
>> approach benefited for someone who is trying to migrate from 2.5.0 or
>> before? will there be any intermittent steps or this tool would take care
>> of such intermittent steps?
>>
>> The other question is; its better CLI tool having a verbose option to be
>> implemented.  maybe through (-v) which prints all the necessary details
>> around the migration state rather someone to enable that via log4j
>> separately.
>>
>> Cheers,
>> Dushan
>>
>> On Wed, Sep 19, 2018 at 9:50 PM, Samitha Chathuranga 
>> wrote:
>>
>>> Hi all,
>>>
>>> Following is an update on the current progress of this task.
>>>
>>> Tasks done upto:
>>>
>>> 1. 2.6.0 REST API and implementation changes.
>>>
>>>- Change GET applications REST API to enable get all apps of a given
>>>tenant too, instead of all tenants
>>>- Support cross tenant APIs GET for migration only for super admin
>>>- Return application keys too (conditionally) to use for migration
>>>- Support cross tenant application export for migration for super
>>>admin
>>>
>>> 2. Export APIs as a bulk with export-apis command with import-export tool
>>>
>>>- All the APIs are exported by single command but implementation is
>>>as iterative api export, set by set separately (export sets of APIs
>>>separately, instead of exporting all at once)
>>>- API export resume capability (error handling) with the support of
>>>two files migration-apis-export-metadata.yaml and last-succeeded-api.log
>>>- *--force* flag with *export-apis* command will forcefully export
>>>all the apis from beginning, disregarding the fact that all/some apis 
>>> were
>>>exported successfully by last execution of command.
>>>- Able to skip exporting particular APIs (if they were failed once
>>>and not needed to export if execute the command next time without --force
>>>option)
>>>
>>> 3. Fixing the gaps, which had blocked functionality in APIM 3.0.0
>>> import-export tool related to API import/export process.
>>>
>>> Slight changes on the design of the approach is updated in the same doc
>>> shared previously. [1]
>>> Will be updating this thread on the progress and appreciate any concerns.
>>>
>>> [1]
>>> https://docs.google.com/document/d/1N8ZXPf1-dKpYf09w7AZ9M6RHXnsU2Orht37N1yETbnE/edit?usp=sharing
>>>
>>> Regards,
>>> Samitha
>>>
>>> On Fri, Sep 7, 2018 at 11:12 AM Samitha Chathuranga 
>>> wrote:
>>>
 Hi all,

 This is an update on the up to now state on this task. Had several
 discussions, design reviews within team and below doc [1] contains the
 overall design of migration process. And each operation executed at API
 export/import process (for migration) is detailed under Section 7 (*Using
 the Import Export CLI tool for migration - User Steps and Steps executed in
 each command*).

 Appreciate any comments and suggestions.

 Meanwhile I have worked on changing required REST APIs for this
 migration process and are almost done. API/App export related operations
 from CLI tool is done upto an extent allowing to be finalized based on
 finalized design.

 

Re: [Architecture] advantages of using IS as KM for APIM ?

[Manuri Amaya Perera]

On Sat, Sep 15, 2018 at 4:16 PM Youcef HILEM 
wrote:

> Hi,
>
> I am in the design phase of the future architecture of our APIM platform.
> Currently we do not deploy IS as KM.
>
> To not miss something I ask you to know if it is relevant to use IS as KM.
>
> What are the advantages of using IS as KM for APIM in a context where we
> have already tow IDP in our company?
> In other words what useful IS  features are missing in KM?
>
> Thanks,
> Youcef HILEM
>
>
>
> --
> Sent from:
> http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Architecture-f62919.html
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 

*Manuri Amaya Perera*

*Senior Software Engineer*

*WSO2 Inc.*

*Mobile: +94718010490*
*Blog: http://manuriamayaperera.blogspot.com
*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Migration approach for APIM 2.6.0 to 3.0.0

[Amila Maha Arachchi]

Dushan has a very good point (but I think Dushan has or expressed it
wrong). It seems that it has been decided to go with Approach 1. i.e.
adding the migration capabilities to the existing REST apis of 2.6.0. This
means, people using other versions such as 2.1.0, 2.5.0 wont be able to
migrate to 3.0 without coming to 2.6.0.

If we had a separate API which can export from any version (lets say from
any version from 2.1.0 upwards) and import to 3.0, that is the ideal
solution. It is easy to fix issues as well. It is true that this tool will
be thrown away after sometime. But, we shouldn't expect all the code we
write to be used forever.

For me, writing a separate API is easier for us and the users both.

On Fri, Sep 21, 2018 at 3:05 AM Dushan Abeyruwan  wrote:

> Hi Samitha,
>   Are we proceeding with the approach-2? if so, how does such migration
> approach benefited for someone who is trying to migrate from 2.5.0 or
> before? will there be any intermittent steps or this tool would take care
> of such intermittent steps?
>
> The other question is; its better CLI tool having a verbose option to be
> implemented.  maybe through (-v) which prints all the necessary details
> around the migration state rather someone to enable that via log4j
> separately.
>
> Cheers,
> Dushan
>
> On Wed, Sep 19, 2018 at 9:50 PM, Samitha Chathuranga 
> wrote:
>
>> Hi all,
>>
>> Following is an update on the current progress of this task.
>>
>> Tasks done upto:
>>
>> 1. 2.6.0 REST API and implementation changes.
>>
>>- Change GET applications REST API to enable get all apps of a given
>>tenant too, instead of all tenants
>>- Support cross tenant APIs GET for migration only for super admin
>>- Return application keys too (conditionally) to use for migration
>>- Support cross tenant application export for migration for super
>>admin
>>
>> 2. Export APIs as a bulk with export-apis command with import-export tool
>>
>>- All the APIs are exported by single command but implementation is
>>as iterative api export, set by set separately (export sets of APIs
>>separately, instead of exporting all at once)
>>- API export resume capability (error handling) with the support of
>>two files migration-apis-export-metadata.yaml and last-succeeded-api.log
>>- *--force* flag with *export-apis* command will forcefully export
>>all the apis from beginning, disregarding the fact that all/some apis were
>>exported successfully by last execution of command.
>>- Able to skip exporting particular APIs (if they were failed once
>>and not needed to export if execute the command next time without --force
>>option)
>>
>> 3. Fixing the gaps, which had blocked functionality in APIM 3.0.0
>> import-export tool related to API import/export process.
>>
>> Slight changes on the design of the approach is updated in the same doc
>> shared previously. [1]
>> Will be updating this thread on the progress and appreciate any concerns.
>>
>> [1]
>> https://docs.google.com/document/d/1N8ZXPf1-dKpYf09w7AZ9M6RHXnsU2Orht37N1yETbnE/edit?usp=sharing
>>
>> Regards,
>> Samitha
>>
>> On Fri, Sep 7, 2018 at 11:12 AM Samitha Chathuranga 
>> wrote:
>>
>>> Hi all,
>>>
>>> This is an update on the up to now state on this task. Had several
>>> discussions, design reviews within team and below doc [1] contains the
>>> overall design of migration process. And each operation executed at API
>>> export/import process (for migration) is detailed under Section 7 (*Using
>>> the Import Export CLI tool for migration - User Steps and Steps executed in
>>> each command*).
>>>
>>> Appreciate any comments and suggestions.
>>>
>>> Meanwhile I have worked on changing required REST APIs for this
>>> migration process and are almost done. API/App export related operations
>>> from CLI tool is done upto an extent allowing to be finalized based on
>>> finalized design.
>>>
>>> [1]
>>> https://docs.google.com/document/d/1N8ZXPf1-dKpYf09w7AZ9M6RHXnsU2Orht37N1yETbnE/edit?usp=sharing
>>>
>>> Regards,
>>> Samitha
>>>
>>> On Wed, Aug 1, 2018 at 10:31 AM Samitha Chathuranga 
>>> wrote:
>>>
 Hi Nuwan,

 One main reason is that, if we follow approach 1, migration story
 cannot be done in single step. Specially two CLI tools will have to be
 used for the two sub steps of exporting and importing.

 And also normal API/Application export flow will change as major
 modifications will be required for certain aspects. i.e.

- bulk export/import
- correlate the difference in the format of archives supported by
2.6 vs 3.0
- exporting and importing additional artifacts such as throttle
policies, access tokens, user role permissions

 Importing the 2.6 format API/Applications to 3.0 would require
 completely new effort too. So anyway we will have to change the 3.0 import
 tool highly.

 And my perception is that normal import export and migration oriented

Re: [Architecture] [carbon-dashboards][widget-generation-wizard]Create an autocomplete search using widget generation wizard

[Ruwini Wijesiri]

Hi Sajith,

Thanks for the response.

I'll proceed with this approach.

Thanks,
Regards,
Ruwini

On Fri, Sep 21, 2018 at 9:44 AM Sajith Ariyarathna 
wrote:

> +1 for 2nd approach.
> +1 for suggested migration implementation.
>
> Thanks.
>
> On Fri, Sep 21, 2018 at 9:38 AM Ruwini Wijesiri  wrote:
>
>> Hi Tanya,
>>
>> Thank you for the response.
>>
>> I think its better to handle this at the dashboard level by making "
>>> *UniversalWidget*" a reserved word and replacing it with  "
>>> *vizgrammar-renderer" *in the Dashboard json before passing it to
>>> Golden Layout. So that customers don't need to bother about any additional
>>> migration effort.
>>>
>>
>> +1 for this.
>>
>> Thanks,
>> Regards,
>> Ruwini.
>>
>> On Fri, Sep 21, 2018 at 8:37 AM Tanya Madurapperuma 
>> wrote:
>>
>>> +1 for the second approach.
>>>
>>
>>
>> --
>> Ruwini Wijesiri
>> Software Engineer,
>> WSO2 Inc.
>>
>> Mobile : +94716133480
>>
>> 
>>
>
>
> --
> Sajith Janaprasad Ariyarathna
> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
> 
>


-- 
Ruwini Wijesiri
Software Engineer,
WSO2 Inc.

Mobile : +94716133480


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [carbon-dashboards][widget-generation-wizard]Create an autocomplete search using widget generation wizard

[Sajith Ariyarathna]

+1 for 2nd approach.
+1 for suggested migration implementation.

Thanks.

On Fri, Sep 21, 2018 at 9:38 AM Ruwini Wijesiri  wrote:

> Hi Tanya,
>
> Thank you for the response.
>
> I think its better to handle this at the dashboard level by making "
>> *UniversalWidget*" a reserved word and replacing it with  "
>> *vizgrammar-renderer" *in the Dashboard json before passing it to Golden
>> Layout. So that customers don't need to bother about any additional
>> migration effort.
>>
>
> +1 for this.
>
> Thanks,
> Regards,
> Ruwini.
>
> On Fri, Sep 21, 2018 at 8:37 AM Tanya Madurapperuma 
> wrote:
>
>> +1 for the second approach.
>>
>
>
> --
> Ruwini Wijesiri
> Software Engineer,
> WSO2 Inc.
>
> Mobile : +94716133480
>
> 
>


-- 
Sajith Janaprasad Ariyarathna
Senior Software Engineer; WSO2, Inc.;  http://wso2.com/

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release WSO2 Enterprise Integrator 6.4.0 RC1

[Prabushi Samarakoon]

Hi All,

I tested the following, and no issues found.

   - Template creation with new template dashboard
   - Mediator project creation
   - Synapse artifacts creation including proxy service, rest API,
   sequence, local entry, etc.
   - CApp creation
   - Add/ use connectors within the mediation flow
   - Error validation on source view
   - Data mapper diagram view
   - Add WSO2 EI 6.4.0 server and deploy artifacts

[+] Stable - Go ahead and release


Thanks,
Prabushi

On Thu, Sep 20, 2018 at 7:37 PM, Tharindu Edirisinghe 
wrote:

> Reviewed the security scanning reports (static and dynamic) and +1 from
> the Platform Security Team for proceeding with the release.
>
> On Thu, Sep 20, 2018 at 7:10 PM Asanka Abeyweera 
> wrote:
>
>> Hi All,
>>
>> I verified the basic functionality of a 2 node message broker cluster
>> using MySQL as the RDBMS.
>>
>>- Distributed Queues
>>- Multi-node subscription and publisher scenarios
>>- Multi-node topic scenarios
>>
>> [+] Stable - Go ahead and release
>>
>> On Thu, Sep 20, 2018 at 5:36 PM Nandika Jayawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> I verified the following functionality and found no issues.
>>>
>>> 1. BPMN process execution
>>> 2. Human Task execution
>>> 3. Micro Integrator execution with Apis, Endpoints, Datamapper in Docker
>>> containers
>>> 4. EI Tooling -> creating EI artifacts and Importing EI Artifacts.
>>> 5. Profile creator tool.
>>> 6. EI Analytics
>>>
>>> [+] Stable - Go ahead and release
>>>
>>> Regards
>>> Nandika
>>>
>>> On Thu, Sep 20, 2018 at 11:28 AM, Nirothipan Megalingham <
>>> nirothi...@wso2.com> wrote:
>>>
 Hi all,

 I have tested the following and found no issues

- Creating ESB Solution Projects and Templates in EI Tooling.
- Adding Server/Remote server in tooling and deploying the
artifacts.
- Creating Sample DSS projects.
- Creating Registry Resource / Connector exporter projects in
tooling.
- Deploying class mediators the server.
- Deploying sample schedule tasks with Micro Integrator profile.


 +1 for the release.

 Thanks
 Nirothipan


 On Thu, Sep 20, 2018 at 10:23 AM Danushka Madhuranga <
 danush...@wso2.com> wrote:

> Hi All,
>
> I have tested the following,
>
> User interface stability in the management console
> Sequence creating editing and deleting using the management console
> Mediators (All the mediators) adding editing and deleting using the
> management console
> Endpoints (All the endpoints) creating editing and deleting using the
> management console
>
> [+] Stable - go ahead and release.
>
> Thanks,
>
>
> On Thu, Sep 20, 2018 at 9:27 AM, Malaka Gangananda 
> wrote:
>
>> Hi All,
>>
>> I have tested the following,
>>
>> VFS transport with following scenarios:
>> VFS transfer with file types  ascii and binary,
>> VFS absolute path test with sftp server
>> VFS SFTP server using passphrase protected keys
>>
>>
>> [+] Stable - go ahead and release.
>>
>> Thanks,
>>
>> On Thu, Sep 20, 2018 at 5:53 AM, Lahiru Madushanka <
>> lahirum...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> I have tested the following mediators.
>>> DBLookup
>>> DBReport
>>> Callout
>>> Cache
>>> ForEach
>>> Iterate
>>> Script
>>> Smooks
>>>
>>> and
>>>
>>> VFS transport
>>> InMemory message store + Message sampling processor
>>> IP based throttling
>>>
>>> [+] Stable - Go ahead and release
>>>
>>> Thanks,
>>> Lahiru
>>>
>>> On Wed, Sep 19, 2018 at 11:40 AM Shakila Sasikaran 
>>> wrote:
>>>
 Hi all,

 I have tested the following and no issues found.

 *Core:*
 Call
 Enqueue
 Send
 Loopback
 Sequence
 Respond
 Drop
 Call Template
 Enrich
 Property
 Log
 Filter
 Out
 In
 Validate
 Switch

 *Endpoints:*
 Address Endpoints
 LoadBalance Endpoints
 Failover Endpoints
 HTTP Endpoints
 WSDL Endpoints
 Indirect and Resolving Endpoints
 Default Endpoints
 Template Endpoints
 Recipient List Endpoints

 *Inbound Endpoints:*
 File inbound
 JMS inbound

 [+] Stable - Go ahead and release

 Thanks

 On Tue, Sep 18, 2018 at 10:04 PM, Dileesha Rajapakse <
 dilee...@wso2.com> wrote:

> Hi everyone,
>
> I have tested the RC1 in the following scenarios.
>
>1.  Tested the following EI Analytics features with embedded
>H2 and MySQL 5.7.
>   1. Overview Dashboard.
>   2. 

Re: [Architecture] [carbon-dashboards][widget-generation-wizard]Create an autocomplete search using widget generation wizard

[Ruwini Wijesiri]

Hi Tanya,

Thank you for the response.

I think its better to handle this at the dashboard level by making "
> *UniversalWidget*" a reserved word and replacing it with  "
> *vizgrammar-renderer" *in the Dashboard json before passing it to Golden
> Layout. So that customers don't need to bother about any additional
> migration effort.
>

+1 for this.

Thanks,
Regards,
Ruwini.

On Fri, Sep 21, 2018 at 8:37 AM Tanya Madurapperuma  wrote:

> +1 for the second approach.
>


-- 
Ruwini Wijesiri
Software Engineer,
WSO2 Inc.

Mobile : +94716133480


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Migration approach for APIM 2.6.0 to 3.0.0

[Dushan Abeyruwan]

Hi Samitha,
  Are we proceeding with the approach-2? if so, how does such migration
approach benefited for someone who is trying to migrate from 2.5.0 or
before? will there be any intermittent steps or this tool would take care
of such intermittent steps?

The other question is; its better CLI tool having a verbose option to be
implemented.  maybe through (-v) which prints all the necessary details
around the migration state rather someone to enable that via log4j
separately.

Cheers,
Dushan

On Wed, Sep 19, 2018 at 9:50 PM, Samitha Chathuranga 
wrote:

> Hi all,
>
> Following is an update on the current progress of this task.
>
> Tasks done upto:
>
> 1. 2.6.0 REST API and implementation changes.
>
>- Change GET applications REST API to enable get all apps of a given
>tenant too, instead of all tenants
>- Support cross tenant APIs GET for migration only for super admin
>- Return application keys too (conditionally) to use for migration
>- Support cross tenant application export for migration for super admin
>
> 2. Export APIs as a bulk with export-apis command with import-export tool
>
>- All the APIs are exported by single command but implementation is as
>iterative api export, set by set separately (export sets of APIs
>separately, instead of exporting all at once)
>- API export resume capability (error handling) with the support of
>two files migration-apis-export-metadata.yaml and
>last-succeeded-api.log
>- *--force* flag with *export-apis* command will forcefully export all
>the apis from beginning, disregarding the fact that all/some apis were
>exported successfully by last execution of command.
>- Able to skip exporting particular APIs (if they were failed once and
>not needed to export if execute the command next time without --force
>option)
>
> 3. Fixing the gaps, which had blocked functionality in APIM 3.0.0
> import-export tool related to API import/export process.
>
> Slight changes on the design of the approach is updated in the same doc
> shared previously. [1]
> Will be updating this thread on the progress and appreciate any concerns.
>
> [1] https://docs.google.com/document/d/1N8ZXPf1-
> dKpYf09w7AZ9M6RHXnsU2Orht37N1yETbnE/edit?usp=sharing
>
> Regards,
> Samitha
>
> On Fri, Sep 7, 2018 at 11:12 AM Samitha Chathuranga 
> wrote:
>
>> Hi all,
>>
>> This is an update on the up to now state on this task. Had several
>> discussions, design reviews within team and below doc [1] contains the
>> overall design of migration process. And each operation executed at API
>> export/import process (for migration) is detailed under Section 7 (*Using
>> the Import Export CLI tool for migration - User Steps and Steps executed in
>> each command*).
>>
>> Appreciate any comments and suggestions.
>>
>> Meanwhile I have worked on changing required REST APIs for this migration
>> process and are almost done. API/App export related operations from CLI
>> tool is done upto an extent allowing to be finalized based on finalized
>> design.
>>
>> [1] https://docs.google.com/document/d/1N8ZXPf1-
>> dKpYf09w7AZ9M6RHXnsU2Orht37N1yETbnE/edit?usp=sharing
>>
>> Regards,
>> Samitha
>>
>> On Wed, Aug 1, 2018 at 10:31 AM Samitha Chathuranga 
>> wrote:
>>
>>> Hi Nuwan,
>>>
>>> One main reason is that, if we follow approach 1, migration story
>>> cannot be done in single step. Specially two CLI tools will have to be
>>> used for the two sub steps of exporting and importing.
>>>
>>> And also normal API/Application export flow will change as major
>>> modifications will be required for certain aspects. i.e.
>>>
>>>- bulk export/import
>>>- correlate the difference in the format of archives supported by
>>>2.6 vs 3.0
>>>- exporting and importing additional artifacts such as throttle
>>>policies, access tokens, user role permissions
>>>
>>> Importing the 2.6 format API/Applications to 3.0 would require
>>> completely new effort too. So anyway we will have to change the 3.0 import
>>> tool highly.
>>>
>>> And my perception is that normal import export and migration oriented
>>> export-import are tow separate tasks and thought it is better to isolate
>>> the two objectives. (as similarly we do in earlier versions). We will also
>>> have to think about specific permissions required for the migration
>>> oriented export-import in same tool.
>>>
>>> Eventhough we may go with Approach 2, we can reuse the same code bases
>>> when possible.
>>>
>>> But anyway it is a matter of decision, whether we manage the normal
>>> import/export and migration-oriented-import/export separately. Approach
>>> 1 would result with some higher level of import/export while in approach 2,
>>> we could highlight it as a migration.
>>>
>>> Regards,
>>> Samitha
>>>
>>> On Tue, Jul 31, 2018 at 11:08 PM, Nuwan Dias  wrote:
>>>
 I would rather go with approach 1. In approach 2 you are suggesting to
 develop a separate web app and a separate tool, why do you think it is

Re: [Architecture] [Dev] [VOTE] Release WSO2 Enterprise Integrator 6.4.0 RC1

[Tharindu Edirisinghe]

Reviewed the security scanning reports (static and dynamic) and +1 from the
Platform Security Team for proceeding with the release.

On Thu, Sep 20, 2018 at 7:10 PM Asanka Abeyweera  wrote:

> Hi All,
>
> I verified the basic functionality of a 2 node message broker cluster
> using MySQL as the RDBMS.
>
>- Distributed Queues
>- Multi-node subscription and publisher scenarios
>- Multi-node topic scenarios
>
> [+] Stable - Go ahead and release
>
> On Thu, Sep 20, 2018 at 5:36 PM Nandika Jayawardana 
> wrote:
>
>> Hi All,
>>
>> I verified the following functionality and found no issues.
>>
>> 1. BPMN process execution
>> 2. Human Task execution
>> 3. Micro Integrator execution with Apis, Endpoints, Datamapper in Docker
>> containers
>> 4. EI Tooling -> creating EI artifacts and Importing EI Artifacts.
>> 5. Profile creator tool.
>> 6. EI Analytics
>>
>> [+] Stable - Go ahead and release
>>
>> Regards
>> Nandika
>>
>> On Thu, Sep 20, 2018 at 11:28 AM, Nirothipan Megalingham <
>> nirothi...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> I have tested the following and found no issues
>>>
>>>- Creating ESB Solution Projects and Templates in EI Tooling.
>>>- Adding Server/Remote server in tooling and deploying the artifacts.
>>>- Creating Sample DSS projects.
>>>- Creating Registry Resource / Connector exporter projects in
>>>tooling.
>>>- Deploying class mediators the server.
>>>- Deploying sample schedule tasks with Micro Integrator profile.
>>>
>>>
>>> +1 for the release.
>>>
>>> Thanks
>>> Nirothipan
>>>
>>>
>>> On Thu, Sep 20, 2018 at 10:23 AM Danushka Madhuranga 
>>> wrote:
>>>
 Hi All,

 I have tested the following,

 User interface stability in the management console
 Sequence creating editing and deleting using the management console
 Mediators (All the mediators) adding editing and deleting using the
 management console
 Endpoints (All the endpoints) creating editing and deleting using the
 management console

 [+] Stable - go ahead and release.

 Thanks,


 On Thu, Sep 20, 2018 at 9:27 AM, Malaka Gangananda 
 wrote:

> Hi All,
>
> I have tested the following,
>
> VFS transport with following scenarios:
> VFS transfer with file types  ascii and binary,
> VFS absolute path test with sftp server
> VFS SFTP server using passphrase protected keys
>
>
> [+] Stable - go ahead and release.
>
> Thanks,
>
> On Thu, Sep 20, 2018 at 5:53 AM, Lahiru Madushanka <
> lahirum...@wso2.com> wrote:
>
>> Hi all,
>>
>> I have tested the following mediators.
>> DBLookup
>> DBReport
>> Callout
>> Cache
>> ForEach
>> Iterate
>> Script
>> Smooks
>>
>> and
>>
>> VFS transport
>> InMemory message store + Message sampling processor
>> IP based throttling
>>
>> [+] Stable - Go ahead and release
>>
>> Thanks,
>> Lahiru
>>
>> On Wed, Sep 19, 2018 at 11:40 AM Shakila Sasikaran 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have tested the following and no issues found.
>>>
>>> *Core:*
>>> Call
>>> Enqueue
>>> Send
>>> Loopback
>>> Sequence
>>> Respond
>>> Drop
>>> Call Template
>>> Enrich
>>> Property
>>> Log
>>> Filter
>>> Out
>>> In
>>> Validate
>>> Switch
>>>
>>> *Endpoints:*
>>> Address Endpoints
>>> LoadBalance Endpoints
>>> Failover Endpoints
>>> HTTP Endpoints
>>> WSDL Endpoints
>>> Indirect and Resolving Endpoints
>>> Default Endpoints
>>> Template Endpoints
>>> Recipient List Endpoints
>>>
>>> *Inbound Endpoints:*
>>> File inbound
>>> JMS inbound
>>>
>>> [+] Stable - Go ahead and release
>>>
>>> Thanks
>>>
>>> On Tue, Sep 18, 2018 at 10:04 PM, Dileesha Rajapakse <
>>> dilee...@wso2.com> wrote:
>>>
 Hi everyone,

 I have tested the RC1 in the following scenarios.

1.  Tested the following EI Analytics features with embedded H2
and MySQL 5.7.
   1. Overview Dashboard.
   2. Proxy Services Dashboard.
   3. API Dashboard.
   4. Sequence Dashboard.
   5. Endpoint Dashboard.
   6. Inbound Endpoint Dashboard
   7. Mediator Dashboard.
   8. Message Dashboard.
2. Tested the following in a two-node cluster.
   1. Scheduling Tasks in different time intervals and counts.
   2. Scheduling tasks with cron expressions.
3. Tested the creation and deployment (as CApps) of the
following with tooling.
   1. Proxy service.
   2. API.
   3. Sequence.
   4. REST API.
   5. Inbound Endpoint.
   6. Endpoint.

 No 

Re: [Architecture] [Dev] [VOTE] Release WSO2 Enterprise Integrator 6.4.0 RC1

[Asanka Abeyweera]

Hi All,

I verified the basic functionality of a 2 node message broker cluster using
MySQL as the RDBMS.

   - Distributed Queues
   - Multi-node subscription and publisher scenarios
   - Multi-node topic scenarios

[+] Stable - Go ahead and release

On Thu, Sep 20, 2018 at 5:36 PM Nandika Jayawardana 
wrote:

> Hi All,
>
> I verified the following functionality and found no issues.
>
> 1. BPMN process execution
> 2. Human Task execution
> 3. Micro Integrator execution with Apis, Endpoints, Datamapper in Docker
> containers
> 4. EI Tooling -> creating EI artifacts and Importing EI Artifacts.
> 5. Profile creator tool.
> 6. EI Analytics
>
> [+] Stable - Go ahead and release
>
> Regards
> Nandika
>
> On Thu, Sep 20, 2018 at 11:28 AM, Nirothipan Megalingham <
> nirothi...@wso2.com> wrote:
>
>> Hi all,
>>
>> I have tested the following and found no issues
>>
>>- Creating ESB Solution Projects and Templates in EI Tooling.
>>- Adding Server/Remote server in tooling and deploying the artifacts.
>>- Creating Sample DSS projects.
>>- Creating Registry Resource / Connector exporter projects in tooling.
>>- Deploying class mediators the server.
>>- Deploying sample schedule tasks with Micro Integrator profile.
>>
>>
>> +1 for the release.
>>
>> Thanks
>> Nirothipan
>>
>>
>> On Thu, Sep 20, 2018 at 10:23 AM Danushka Madhuranga 
>> wrote:
>>
>>> Hi All,
>>>
>>> I have tested the following,
>>>
>>> User interface stability in the management console
>>> Sequence creating editing and deleting using the management console
>>> Mediators (All the mediators) adding editing and deleting using the
>>> management console
>>> Endpoints (All the endpoints) creating editing and deleting using the
>>> management console
>>>
>>> [+] Stable - go ahead and release.
>>>
>>> Thanks,
>>>
>>>
>>> On Thu, Sep 20, 2018 at 9:27 AM, Malaka Gangananda 
>>> wrote:
>>>
 Hi All,

 I have tested the following,

 VFS transport with following scenarios:
 VFS transfer with file types  ascii and binary,
 VFS absolute path test with sftp server
 VFS SFTP server using passphrase protected keys


 [+] Stable - go ahead and release.

 Thanks,

 On Thu, Sep 20, 2018 at 5:53 AM, Lahiru Madushanka >>> > wrote:

> Hi all,
>
> I have tested the following mediators.
> DBLookup
> DBReport
> Callout
> Cache
> ForEach
> Iterate
> Script
> Smooks
>
> and
>
> VFS transport
> InMemory message store + Message sampling processor
> IP based throttling
>
> [+] Stable - Go ahead and release
>
> Thanks,
> Lahiru
>
> On Wed, Sep 19, 2018 at 11:40 AM Shakila Sasikaran 
> wrote:
>
>> Hi all,
>>
>> I have tested the following and no issues found.
>>
>> *Core:*
>> Call
>> Enqueue
>> Send
>> Loopback
>> Sequence
>> Respond
>> Drop
>> Call Template
>> Enrich
>> Property
>> Log
>> Filter
>> Out
>> In
>> Validate
>> Switch
>>
>> *Endpoints:*
>> Address Endpoints
>> LoadBalance Endpoints
>> Failover Endpoints
>> HTTP Endpoints
>> WSDL Endpoints
>> Indirect and Resolving Endpoints
>> Default Endpoints
>> Template Endpoints
>> Recipient List Endpoints
>>
>> *Inbound Endpoints:*
>> File inbound
>> JMS inbound
>>
>> [+] Stable - Go ahead and release
>>
>> Thanks
>>
>> On Tue, Sep 18, 2018 at 10:04 PM, Dileesha Rajapakse <
>> dilee...@wso2.com> wrote:
>>
>>> Hi everyone,
>>>
>>> I have tested the RC1 in the following scenarios.
>>>
>>>1.  Tested the following EI Analytics features with embedded H2
>>>and MySQL 5.7.
>>>   1. Overview Dashboard.
>>>   2. Proxy Services Dashboard.
>>>   3. API Dashboard.
>>>   4. Sequence Dashboard.
>>>   5. Endpoint Dashboard.
>>>   6. Inbound Endpoint Dashboard
>>>   7. Mediator Dashboard.
>>>   8. Message Dashboard.
>>>2. Tested the following in a two-node cluster.
>>>   1. Scheduling Tasks in different time intervals and counts.
>>>   2. Scheduling tasks with cron expressions.
>>>3. Tested the creation and deployment (as CApps) of the
>>>following with tooling.
>>>   1. Proxy service.
>>>   2. API.
>>>   3. Sequence.
>>>   4. REST API.
>>>   5. Inbound Endpoint.
>>>   6. Endpoint.
>>>
>>> No issues found.
>>>
>>> [+] Stable - Go ahead and release
>>>
>>> Regards.
>>>
>>> On Tue, Sep 18, 2018 at 2:03 PM Thishani Lucas 
>>> wrote:
>>>
 Hi All,

 We are pleased to announce the first release candidate of WSO2
 Enterprise Integrator 6.4.0.

 *Known Issues: *https://github.com/wso2/product-ei/issues

 *Source and 

Re: [Architecture] [Dev] [VOTE] Release WSO2 Enterprise Integrator 6.4.0 RC1

[Heshitha Hettihewa]

Hi all,

I've tested the following and found no issues,

   - EI Tooling templates dashboard, sample creation and execution.
   - ESB graphical editor and error reporting improvements.
   - Data mapper editor basic functionalities.
   - BPEL, BPMN tooling and runtime execution.
   - Developer studio server functions (Artifact deployment and server
   connection).
   - JMS inbound endpoint and Scheduled tasks.
   - CApp deployment and artifact deployment order.

[+] Stable - Go ahead and release

Thanks,
Heshitha.


On Thu, Sep 20, 2018 at 5:34 PM, Nandika Jayawardana 
wrote:

> Hi All,
>
> I verified the following functionality and found no issues.
>
> 1. BPMN process execution
> 2. Human Task execution
> 3. Micro Integrator execution with Apis, Endpoints, Datamapper in Docker
> containers
> 4. EI Tooling -> creating EI artifacts and Importing EI Artifacts.
> 5. Profile creator tool.
> 6. EI Analytics
>
> [+] Stable - Go ahead and release
>
> Regards
> Nandika
>
> On Thu, Sep 20, 2018 at 11:28 AM, Nirothipan Megalingham <
> nirothi...@wso2.com> wrote:
>
>> Hi all,
>>
>> I have tested the following and found no issues
>>
>>- Creating ESB Solution Projects and Templates in EI Tooling.
>>- Adding Server/Remote server in tooling and deploying the artifacts.
>>- Creating Sample DSS projects.
>>- Creating Registry Resource / Connector exporter projects in tooling.
>>- Deploying class mediators the server.
>>- Deploying sample schedule tasks with Micro Integrator profile.
>>
>>
>> +1 for the release.
>>
>> Thanks
>> Nirothipan
>>
>>
>> On Thu, Sep 20, 2018 at 10:23 AM Danushka Madhuranga 
>> wrote:
>>
>>> Hi All,
>>>
>>> I have tested the following,
>>>
>>> User interface stability in the management console
>>> Sequence creating editing and deleting using the management console
>>> Mediators (All the mediators) adding editing and deleting using the
>>> management console
>>> Endpoints (All the endpoints) creating editing and deleting using the
>>> management console
>>>
>>> [+] Stable - go ahead and release.
>>>
>>> Thanks,
>>>
>>>
>>> On Thu, Sep 20, 2018 at 9:27 AM, Malaka Gangananda 
>>> wrote:
>>>
 Hi All,

 I have tested the following,

 VFS transport with following scenarios:
 VFS transfer with file types  ascii and binary,
 VFS absolute path test with sftp server
 VFS SFTP server using passphrase protected keys


 [+] Stable - go ahead and release.

 Thanks,

 On Thu, Sep 20, 2018 at 5:53 AM, Lahiru Madushanka >>> > wrote:

> Hi all,
>
> I have tested the following mediators.
> DBLookup
> DBReport
> Callout
> Cache
> ForEach
> Iterate
> Script
> Smooks
>
> and
>
> VFS transport
> InMemory message store + Message sampling processor
> IP based throttling
>
> [+] Stable - Go ahead and release
>
> Thanks,
> Lahiru
>
> On Wed, Sep 19, 2018 at 11:40 AM Shakila Sasikaran 
> wrote:
>
>> Hi all,
>>
>> I have tested the following and no issues found.
>>
>> *Core:*
>> Call
>> Enqueue
>> Send
>> Loopback
>> Sequence
>> Respond
>> Drop
>> Call Template
>> Enrich
>> Property
>> Log
>> Filter
>> Out
>> In
>> Validate
>> Switch
>>
>> *Endpoints:*
>> Address Endpoints
>> LoadBalance Endpoints
>> Failover Endpoints
>> HTTP Endpoints
>> WSDL Endpoints
>> Indirect and Resolving Endpoints
>> Default Endpoints
>> Template Endpoints
>> Recipient List Endpoints
>>
>> *Inbound Endpoints:*
>> File inbound
>> JMS inbound
>>
>> [+] Stable - Go ahead and release
>>
>> Thanks
>>
>> On Tue, Sep 18, 2018 at 10:04 PM, Dileesha Rajapakse <
>> dilee...@wso2.com> wrote:
>>
>>> Hi everyone,
>>>
>>> I have tested the RC1 in the following scenarios.
>>>
>>>1.  Tested the following EI Analytics features with embedded H2
>>>and MySQL 5.7.
>>>   1. Overview Dashboard.
>>>   2. Proxy Services Dashboard.
>>>   3. API Dashboard.
>>>   4. Sequence Dashboard.
>>>   5. Endpoint Dashboard.
>>>   6. Inbound Endpoint Dashboard
>>>   7. Mediator Dashboard.
>>>   8. Message Dashboard.
>>>2. Tested the following in a two-node cluster.
>>>   1. Scheduling Tasks in different time intervals and counts.
>>>   2. Scheduling tasks with cron expressions.
>>>3. Tested the creation and deployment (as CApps) of the
>>>following with tooling.
>>>   1. Proxy service.
>>>   2. API.
>>>   3. Sequence.
>>>   4. REST API.
>>>   5. Inbound Endpoint.
>>>   6. Endpoint.
>>>
>>> No issues found.
>>>
>>> [+] Stable - Go ahead and release
>>>
>>> Regards.
>>>
>>> On Tue, Sep 18, 2018 at 2:03 PM Thishani 

Re: [Architecture] [Dev] [VOTE] Release WSO2 Enterprise Integrator 6.4.0 RC1

[Nandika Jayawardana]

Hi All,

I verified the following functionality and found no issues.

1. BPMN process execution
2. Human Task execution
3. Micro Integrator execution with Apis, Endpoints, Datamapper in Docker
containers
4. EI Tooling -> creating EI artifacts and Importing EI Artifacts.
5. Profile creator tool.
6. EI Analytics

[+] Stable - Go ahead and release

Regards
Nandika

On Thu, Sep 20, 2018 at 11:28 AM, Nirothipan Megalingham <
nirothi...@wso2.com> wrote:

> Hi all,
>
> I have tested the following and found no issues
>
>- Creating ESB Solution Projects and Templates in EI Tooling.
>- Adding Server/Remote server in tooling and deploying the artifacts.
>- Creating Sample DSS projects.
>- Creating Registry Resource / Connector exporter projects in tooling.
>- Deploying class mediators the server.
>- Deploying sample schedule tasks with Micro Integrator profile.
>
>
> +1 for the release.
>
> Thanks
> Nirothipan
>
>
> On Thu, Sep 20, 2018 at 10:23 AM Danushka Madhuranga 
> wrote:
>
>> Hi All,
>>
>> I have tested the following,
>>
>> User interface stability in the management console
>> Sequence creating editing and deleting using the management console
>> Mediators (All the mediators) adding editing and deleting using the
>> management console
>> Endpoints (All the endpoints) creating editing and deleting using the
>> management console
>>
>> [+] Stable - go ahead and release.
>>
>> Thanks,
>>
>>
>> On Thu, Sep 20, 2018 at 9:27 AM, Malaka Gangananda 
>> wrote:
>>
>>> Hi All,
>>>
>>> I have tested the following,
>>>
>>> VFS transport with following scenarios:
>>> VFS transfer with file types  ascii and binary,
>>> VFS absolute path test with sftp server
>>> VFS SFTP server using passphrase protected keys
>>>
>>>
>>> [+] Stable - go ahead and release.
>>>
>>> Thanks,
>>>
>>> On Thu, Sep 20, 2018 at 5:53 AM, Lahiru Madushanka 
>>> wrote:
>>>
 Hi all,

 I have tested the following mediators.
 DBLookup
 DBReport
 Callout
 Cache
 ForEach
 Iterate
 Script
 Smooks

 and

 VFS transport
 InMemory message store + Message sampling processor
 IP based throttling

 [+] Stable - Go ahead and release

 Thanks,
 Lahiru

 On Wed, Sep 19, 2018 at 11:40 AM Shakila Sasikaran 
 wrote:

> Hi all,
>
> I have tested the following and no issues found.
>
> *Core:*
> Call
> Enqueue
> Send
> Loopback
> Sequence
> Respond
> Drop
> Call Template
> Enrich
> Property
> Log
> Filter
> Out
> In
> Validate
> Switch
>
> *Endpoints:*
> Address Endpoints
> LoadBalance Endpoints
> Failover Endpoints
> HTTP Endpoints
> WSDL Endpoints
> Indirect and Resolving Endpoints
> Default Endpoints
> Template Endpoints
> Recipient List Endpoints
>
> *Inbound Endpoints:*
> File inbound
> JMS inbound
>
> [+] Stable - Go ahead and release
>
> Thanks
>
> On Tue, Sep 18, 2018 at 10:04 PM, Dileesha Rajapakse <
> dilee...@wso2.com> wrote:
>
>> Hi everyone,
>>
>> I have tested the RC1 in the following scenarios.
>>
>>1.  Tested the following EI Analytics features with embedded H2
>>and MySQL 5.7.
>>   1. Overview Dashboard.
>>   2. Proxy Services Dashboard.
>>   3. API Dashboard.
>>   4. Sequence Dashboard.
>>   5. Endpoint Dashboard.
>>   6. Inbound Endpoint Dashboard
>>   7. Mediator Dashboard.
>>   8. Message Dashboard.
>>2. Tested the following in a two-node cluster.
>>   1. Scheduling Tasks in different time intervals and counts.
>>   2. Scheduling tasks with cron expressions.
>>3. Tested the creation and deployment (as CApps) of the following
>>with tooling.
>>   1. Proxy service.
>>   2. API.
>>   3. Sequence.
>>   4. REST API.
>>   5. Inbound Endpoint.
>>   6. Endpoint.
>>
>> No issues found.
>>
>> [+] Stable - Go ahead and release
>>
>> Regards.
>>
>> On Tue, Sep 18, 2018 at 2:03 PM Thishani Lucas 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are pleased to announce the first release candidate of WSO2
>>> Enterprise Integrator 6.4.0.
>>>
>>> *Known Issues: *https://github.com/wso2/product-ei/issues
>>>
>>> *Source and Binary Distribution Files: *https://github.com/
>>> wso2/product-ei/releases/tag/v6.4.0-rc1
>>>
>>> *The Tag to be Voted Upon: *https://github.com/wso2/
>>> product-ei/tree/v6.4.0-rc1
>>>
>>> Please vote as follows:
>>>
>>> [+] Stable - Go ahead and release
>>> [-] Broken - Do not release (explain why)
>>>
>>> ~The WSO2 Integration Team~
>>>
>>> --
>>> *Thishani Lucas*
>>> *Software Engineer*
>>> *WSO2 Lanka (Private) Limited**: http://wso2.com 

[Architecture] [carbon-dashboards][widget-generation-wizard]Create an autocomplete search using widget generation wizard

[Ruwini Wijesiri]

Hi All,

The widget generation wizard enables user to create widgets by configuring
a data source and publisher information.

We have a requirement to enable user to create a autocomplete search bar
using the widget generation wizard. The user will specify a column of the
configured data source and the search bar will list down it's content. The
value(s) selected using this widget will be published to its subscribers.

There are 2 approaches to implement this;

*1. Include the autocomplete in react-vizgrammar *

*Drawbacks:*


   - All components available in react-vizgrammar are charts, since an
 autocomplete isn't a chart, putting it in react-vizgrammar
seems like a
 misfit.
 - The autocomplete is implemented using material-ui 1.5.0 and this
 requires react 16.3.0 or above. Currently, react-vizgrammar
is on react
 16.0.0, therefore react versions needs to be bumped. An
upgrade may cause
 issues in the existing implementation.

*2. Generalize the implementation universal-widget and introduce 2 new
modules to handle each type.*



*-parent-renderer*


*-vizgrammar-renderer**-search-renderer*


Current implementation of universal widget can be refactored as above,
where the '*parent-renderer*' will contain the implementations common to
all widgets such as publisher configuration creation, '*vizgrammar-renderer*'
contain implementation specific to rendering vizgrammar charts and '
*search-renderer*' contain implementation specific to rendering the search
bar.


*Drawbacks:*


   - Not backward compatible. The existing dashboards identifies the widget
 generation wizard by the name universal widget. Renaming
universal widget
 to '*parent-renderer' *will either require migration scripts to
 replace term universal widget with '*vizgrammar-renderer'
 or 'search-renderer' or this will need to be handled at
dashboard level.*

IMO i think the second approach would be better since;

   - Adding an autocomplete select along with charts seems a misfit
   - Scalable, can facilitate future introductions of other types of
   widgets into the widget generation wizard.


Any thoughts on these 2 approaches or any other approach is highly
appreciated.

Thanks,
Regards,
Ruwini

Ruwini Wijesiri
Software Engineer,
WSO2 Inc.

Mobile : +94716133480


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release WSO2 Enterprise Integrator 6.4.0 RC1

[Nirothipan Megalingham]

Hi all,

I have tested the following and found no issues

   - Creating ESB Solution Projects and Templates in EI Tooling.
   - Adding Server/Remote server in tooling and deploying the artifacts.
   - Creating Sample DSS projects.
   - Creating Registry Resource / Connector exporter projects in tooling.
   - Deploying class mediators the server.
   - Deploying sample schedule tasks with Micro Integrator profile.


+1 for the release.

Thanks
Nirothipan


On Thu, Sep 20, 2018 at 10:23 AM Danushka Madhuranga 
wrote:

> Hi All,
>
> I have tested the following,
>
> User interface stability in the management console
> Sequence creating editing and deleting using the management console
> Mediators (All the mediators) adding editing and deleting using the
> management console
> Endpoints (All the endpoints) creating editing and deleting using the
> management console
>
> [+] Stable - go ahead and release.
>
> Thanks,
>
>
> On Thu, Sep 20, 2018 at 9:27 AM, Malaka Gangananda 
> wrote:
>
>> Hi All,
>>
>> I have tested the following,
>>
>> VFS transport with following scenarios:
>> VFS transfer with file types  ascii and binary,
>> VFS absolute path test with sftp server
>> VFS SFTP server using passphrase protected keys
>>
>>
>> [+] Stable - go ahead and release.
>>
>> Thanks,
>>
>> On Thu, Sep 20, 2018 at 5:53 AM, Lahiru Madushanka 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have tested the following mediators.
>>> DBLookup
>>> DBReport
>>> Callout
>>> Cache
>>> ForEach
>>> Iterate
>>> Script
>>> Smooks
>>>
>>> and
>>>
>>> VFS transport
>>> InMemory message store + Message sampling processor
>>> IP based throttling
>>>
>>> [+] Stable - Go ahead and release
>>>
>>> Thanks,
>>> Lahiru
>>>
>>> On Wed, Sep 19, 2018 at 11:40 AM Shakila Sasikaran 
>>> wrote:
>>>
 Hi all,

 I have tested the following and no issues found.

 *Core:*
 Call
 Enqueue
 Send
 Loopback
 Sequence
 Respond
 Drop
 Call Template
 Enrich
 Property
 Log
 Filter
 Out
 In
 Validate
 Switch

 *Endpoints:*
 Address Endpoints
 LoadBalance Endpoints
 Failover Endpoints
 HTTP Endpoints
 WSDL Endpoints
 Indirect and Resolving Endpoints
 Default Endpoints
 Template Endpoints
 Recipient List Endpoints

 *Inbound Endpoints:*
 File inbound
 JMS inbound

 [+] Stable - Go ahead and release

 Thanks

 On Tue, Sep 18, 2018 at 10:04 PM, Dileesha Rajapakse >>> > wrote:

> Hi everyone,
>
> I have tested the RC1 in the following scenarios.
>
>1.  Tested the following EI Analytics features with embedded H2
>and MySQL 5.7.
>   1. Overview Dashboard.
>   2. Proxy Services Dashboard.
>   3. API Dashboard.
>   4. Sequence Dashboard.
>   5. Endpoint Dashboard.
>   6. Inbound Endpoint Dashboard
>   7. Mediator Dashboard.
>   8. Message Dashboard.
>2. Tested the following in a two-node cluster.
>   1. Scheduling Tasks in different time intervals and counts.
>   2. Scheduling tasks with cron expressions.
>3. Tested the creation and deployment (as CApps) of the following
>with tooling.
>   1. Proxy service.
>   2. API.
>   3. Sequence.
>   4. REST API.
>   5. Inbound Endpoint.
>   6. Endpoint.
>
> No issues found.
>
> [+] Stable - Go ahead and release
>
> Regards.
>
> On Tue, Sep 18, 2018 at 2:03 PM Thishani Lucas 
> wrote:
>
>> Hi All,
>>
>> We are pleased to announce the first release candidate of WSO2
>> Enterprise Integrator 6.4.0.
>>
>> *Known Issues: *https://github.com/wso2/product-ei/issues
>>
>> *Source and Binary Distribution Files: *
>> https://github.com/wso2/product-ei/releases/tag/v6.4.0-rc1
>>
>> *The Tag to be Voted Upon: *
>> https://github.com/wso2/product-ei/tree/v6.4.0-rc1
>>
>> Please vote as follows:
>>
>> [+] Stable - Go ahead and release
>> [-] Broken - Do not release (explain why)
>>
>> ~The WSO2 Integration Team~
>>
>> --
>> *Thishani Lucas*
>> *Software Engineer*
>> *WSO2 Lanka (Private) Limited**: http://wso2.com *
>> *lean.enterprise.middle-ware*
>>
>> *Tel: +94 77 2556931 *
>>
>> *LinkedIn: https://www.linkedin.com/in/thishani-lucas/
>> *
>>
>>
>> 
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> *Dileesha Rajapakse*
> Software Engineer | WSO2 Inc.
> Mobile: +94 772555933
> http://www.dilee.me
>
>
> ___
> Dev mailing list
> d...@wso2.org
>