date:20180820

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

2018-08-20 Thread Nuwan Dias

I don't think we should decide the priority of the feature based on how
easy it is to implement. The priority should be decided based on its
importance. To me, someone forgetting a password is far more likely than
someone wanting to change it. So I would consider 'Forgot Password' as a
must have feature and 'Change Password' as a good to have one.

The other reason this thread made me think about the 'Forgot Password'
feature is that if we implement that feature, we can address the change
password capability through the same feature. We don't have to implement
two features to address the two use cases. So, two birds with one stone.
Less code, less bugs and less work.

On Tue, Aug 21, 2018 at 1:34 AM Ishara Cooray  wrote:

> +1 to implement change password feature first as it is simpler than forgot
> password feature which involves user verification.
> Also for the forgot password feature we can either send an email with a
> temporary password or redirect to the change password.
> Even if we send a temporary password we will need to ask to change the
> password.
>
> Hi Vithursa,
>
> I would suggest having another required property call *retypeNewPassword *for
> new password verification.
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Mon, Aug 20, 2018 at 5:08 PM, roshan wijesena 
> wrote:
>
>> Do we have any send an email to user feature in apim 3 road map ?
>>
>> On Mon, Aug 20, 2018 at 7:56 PM Sanjeewa Malalgoda 
>> wrote:
>>
>>> Forgot password feature should comes with some sort of user
>>> verification(enter security question or send email verification, sms
>>> verification etc).
>>> That feature need to implement with some extensions as all are not using
>>> same verification process.
>>> So i think we can first complete this and come back to that feature.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>> On Mon, Aug 20, 2018 at 11:42 AM Mushthaq Rumy 
>>> wrote:
>>>
 +1. I too think that forgot password option is more important and it is
 not yet implemented. I would prefer if we start on that first.

 Thanks & Regards,
 Mushthaq

 On Mon, Aug 20, 2018 at 11:40 AM Nuwan Dias  wrote:

> Do we have a forgot password option on the Store? I would think that
> is more important for an API Store than a change password functionality.
>
> On Mon, Aug 20, 2018 at 11:22 AM Vithursa Mahendrarajah <
> vithu...@wso2.com> wrote:
>
>> Hi all,
>> I am working on $subject in APIM 3.0.0. Planned flow of
>> implementation is as follows:
>>
>> [image: new_password_mail.png]
>> We have SCIM API [1] for updating user-info. A separate REST API can
>> be implemented to provide the feature to change password by wrapping
>> mentioned SCIM API. The sample resource could be as,
>>
>> PasswordChangeRequest:
>> title: Request for changing password
>> required:
>>   - username
>>   - currentPassword
>>   - newPassword
>> properties:
>>   username:
>> type: string
>>   currentPassword:
>> type: string
>>   newPassword:
>> type: string
>>
>> Please provide your thoughts and feedback on this.
>>
>> Thanks,
>> Vithursa
>> --
>> Vithursa Mahendrarajah
>> Software Engineer
>> WSO2 Inc. - http ://wso2.com
>> Mobile  : +947*66695643*
>>
>>
>> *  
>> *
>>
>
>
> --
> Nuwan Dias
>
> Director - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


 --
 Mushthaq Rumy
 *Senior Software Engineer*
 Mobile : +94 (0) 779 492140
 Email : musht...@wso2.com
 WSO2, Inc.; http://wso2.com/
 lean . enterprise . middleware.

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

>>>
>>>
>>> --
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94 712933253
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

2018-08-20 Thread Ishara Cooray

+1 to implement change password feature first as it is simpler than forgot
password feature which involves user verification.
Also for the forgot password feature we can either send an email with a
temporary password or redirect to the change password.
Even if we send a temporary password we will need to ask to change the
password.

Hi Vithursa,

I would suggest having another required property call *retypeNewPassword *for
new password verification.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Aug 20, 2018 at 5:08 PM, roshan wijesena 
wrote:

> Do we have any send an email to user feature in apim 3 road map ?
>
> On Mon, Aug 20, 2018 at 7:56 PM Sanjeewa Malalgoda 
> wrote:
>
>> Forgot password feature should comes with some sort of user
>> verification(enter security question or send email verification, sms
>> verification etc).
>> That feature need to implement with some extensions as all are not using
>> same verification process.
>> So i think we can first complete this and come back to that feature.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>> On Mon, Aug 20, 2018 at 11:42 AM Mushthaq Rumy  wrote:
>>
>>> +1. I too think that forgot password option is more important and it is
>>> not yet implemented. I would prefer if we start on that first.
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>>
>>> On Mon, Aug 20, 2018 at 11:40 AM Nuwan Dias  wrote:
>>>
 Do we have a forgot password option on the Store? I would think that is
 more important for an API Store than a change password functionality.

 On Mon, Aug 20, 2018 at 11:22 AM Vithursa Mahendrarajah <
 vithu...@wso2.com> wrote:

> Hi all,
> I am working on $subject in APIM 3.0.0. Planned flow of implementation
> is as follows:
>
> [image: new_password_mail.png]
> We have SCIM API [1] for updating user-info. A separate REST API can
> be implemented to provide the feature to change password by wrapping
> mentioned SCIM API. The sample resource could be as,
>
> PasswordChangeRequest:
> title: Request for changing password
> required:
>   - username
>   - currentPassword
>   - newPassword
> properties:
>   username:
> type: string
>   currentPassword:
> type: string
>   newPassword:
> type: string
>
> Please provide your thoughts and feedback on this.
>
> Thanks,
> Vithursa
> --
> Vithursa Mahendrarajah
> Software Engineer
> WSO2 Inc. - http ://wso2.com
> Mobile  : +947*66695643*
>
>
> *  
> *
>


 --
 Nuwan Dias

 Director - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729
 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

>>>
>>>
>>> --
>>> Mushthaq Rumy
>>> *Senior Software Engineer*
>>> Mobile : +94 (0) 779 492140
>>> Email : musht...@wso2.com
>>> WSO2, Inc.; http://wso2.com/
>>> lean . enterprise . middleware.
>>>
>>> 
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94 712933253
>>
>> blog :http://sanjeewamalalgoda.
>> blogspot.com/ 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM 3.0.0 - Supporting product upgrades as a first class feature

2018-08-20 Thread Uvindra Dias Jayasinha

On 20 August 2018 at 16:58, Ishara Cooray  wrote:

> For me, PRODUCT_VERSION column in every table seems to be redundant.
> Could you please explain the reason for introducing this column in each
> table? Is this for auditing?
>

The reason for this is so the on the fly migration code is able to detect
if it needs to migrate a given row. For example if running version 3.1.0,

1. A row from a table is retrieved
2. If the value of the PRODUCT_VERSION  column of the row is 3.0.0
migration code will run to convert the data and update the value of
PRODUCT_VERSION to 3.1.0 once row migration has occurred.
3. On subsequent retrievals of the same row since PRODUCT_VERSION is 3.1.0
migration code will not execute against the row.


> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Mon, Aug 20, 2018 at 4:03 PM, Uvindra Dias Jayasinha 
> wrote:
>
>> Small calcification regarding this statement,
>>
>> For the 3.0.0 release we just need to implement steps *1* and *2* above.
>>> Step *3* can be done for all subsequent releases.
>>>
>>
>> I specifically meant the changes to the DB schema when it comes to steps
>> 1 and 2 . Obviously no migration logic will be needed for 3.0.0 itself
>>
>> On 20 August 2018 at 15:58, Uvindra Dias Jayasinha 
>> wrote:
>>
>>> In the past the APIM product has relied on an external component such as
>>> a migration client for upgrading from a given product version to a higher
>>> version.The end user was required to configure the latest product that they
>>> are upgrading to against their current data(databases, synapse files,
>>> registry) and run the migration client manually to upgrade the product.
>>> This can be a cumbersome and error prone process to accomplish for end
>>> users, making product version upgrades time consuming.
>>>
>>> To overcome the above problem on the fly upgrades were proposed where
>>> the product code detects if relevant data being accessed needs to be
>>> migrated to the latest version and migrates the data when the code is
>>> executed when the respective feature is used. Upgrading product data is
>>> much easier from 3.0.0 onwards because all data related to the product is
>>> stored in a central database.This means that the end user does not need to
>>> get involved in upgrading, it happens without them even being aware as they
>>> use the latest version of the product by pointing it against their current
>>> database.This makes for a more pleasant user experience when upgrading,
>>> putting the burden of the upgrade to be added by the developer into the
>>> functional code itself.
>>>
>>> The following outlines a design that can be supported from 3.0.0 onwards
>>> to outline a uniform way of handling product upgrades. This is inspired by
>>> the methodology used by FlywayDB to enable DB migrations[1]  but also
>>> taking into account the requirement of being able to run on the fly at
>>> runtime(Note: DB schema changes between releases will need to be handled
>>> via DB vendor specific scripts prepared by the team to be run by the
>>> customer against their DB).
>>>
>>>
>>> *1.* A new table will be added to the schema called
>>> PRODUCT_VERSION_AUDIT to track the product version upgrades that take place
>>> on a given dataset
>>>
>>> PRODUCT_VERSION_AUDIT
>>> VERSION VARCHAR(5)
>>> CREATED_TIME TIMESTAMP(6)
>>>
>>> If a user begins using APIM version 3.0.0 and then upgrades to version
>>> 3.1.0 the table will contain the following values,
>>>
>>> VERSION CREATED_TIME
>>> 3.0.0 2018-11-11 13:23:44
>>> 3.1.0 2019-10-14 9:26:22
>>>
>>> This gives a historical view of the product versions a customer has been
>>> using. A new row will be inserted into the table when a given product
>>> version is started for the first time.
>>>
>>>
>>>
>>> *2*. Each table in the database will have a new column called
>>> PRODUCT_VERSION(VARCHAR(5)) added. When a row is inserted for the first
>>> time it will populate this column with the current product version being
>>> used.
>>> For example the AM_API table could have the following entries for a
>>> customer using APIM 3.0.0,
>>>
>>> UUID PROVIDER NAME VERSION CONTEXT PRODUCT_VERSION
>>> 123e4567-e89b-12d3-a456-42665544 admin abc 1.0.0 /abc 3.0.0
>>> 00112233-4455-6677-8899-aabbccddeeff admin xyz 1.0.0 /xyz 3.0.0
>>>
>>>
>>> Lets assume when upgrading to 3.1.0 the leading '/' character in the
>>> context needs to be removed. On the fly migration code will run when a
>>> given row is accessed by the DAO layer to remove the '/'. Once the
>>> migration of the row is completed the PRODUCT_VERSION column will be
>>> updated with the value 3.1.0 to signify that the migration for this row has
>>> been completed. The PRODUCT_VERSION column can be validated to check if
>>> migration code needs to be executed. So assuming the API abc is accessed
>>> first the table will look as follows after migration,
>>>
>>>
>>> UUID

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

2018-08-20 Thread roshan wijesena

Do we have any send an email to user feature in apim 3 road map ?

On Mon, Aug 20, 2018 at 7:56 PM Sanjeewa Malalgoda 
wrote:

> Forgot password feature should comes with some sort of user
> verification(enter security question or send email verification, sms
> verification etc).
> That feature need to implement with some extensions as all are not using
> same verification process.
> So i think we can first complete this and come back to that feature.
>
> Thanks,
> sanjeewa.
>
>
> On Mon, Aug 20, 2018 at 11:42 AM Mushthaq Rumy  wrote:
>
>> +1. I too think that forgot password option is more important and it is
>> not yet implemented. I would prefer if we start on that first.
>>
>> Thanks & Regards,
>> Mushthaq
>>
>> On Mon, Aug 20, 2018 at 11:40 AM Nuwan Dias  wrote:
>>
>>> Do we have a forgot password option on the Store? I would think that is
>>> more important for an API Store than a change password functionality.
>>>
>>> On Mon, Aug 20, 2018 at 11:22 AM Vithursa Mahendrarajah <
>>> vithu...@wso2.com> wrote:
>>>
 Hi all,
 I am working on $subject in APIM 3.0.0. Planned flow of implementation
 is as follows:

 [image: new_password_mail.png]
 We have SCIM API [1] for updating user-info. A separate REST API can be
 implemented to provide the feature to change password by wrapping mentioned
 SCIM API. The sample resource could be as,

 PasswordChangeRequest:
 title: Request for changing password
 required:
   - username
   - currentPassword
   - newPassword
 properties:
   username:
 type: string
   currentPassword:
 type: string
   newPassword:
 type: string

 Please provide your thoughts and feedback on this.

 Thanks,
 Vithursa
 --
 Vithursa Mahendrarajah
 Software Engineer
 WSO2 Inc. - http ://wso2.com
 Mobile  : +947*66695643*


 *  
 *

>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Director - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Mushthaq Rumy
>> *Senior Software Engineer*
>> Mobile : +94 (0) 779 492140
>> Email : musht...@wso2.com
>> WSO2, Inc.; http://wso2.com/
>> lean . enterprise . middleware.
>>
>> 
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94 712933253
>
> blog
> :http://sanjeewamalalgoda.blogspot.com/
> 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM 3.0.0 - Supporting product upgrades as a first class feature

2018-08-20 Thread Ishara Cooray

For me, PRODUCT_VERSION column in every table seems to be redundant.
Could you please explain the reason for introducing this column in each
table? Is this for auditing?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, Aug 20, 2018 at 4:03 PM, Uvindra Dias Jayasinha 
wrote:

> Small calcification regarding this statement,
>
> For the 3.0.0 release we just need to implement steps *1* and *2* above.
>> Step *3* can be done for all subsequent releases.
>>
>
> I specifically meant the changes to the DB schema when it comes to steps 1
> and 2 . Obviously no migration logic will be needed for 3.0.0 itself
>
> On 20 August 2018 at 15:58, Uvindra Dias Jayasinha 
> wrote:
>
>> In the past the APIM product has relied on an external component such as
>> a migration client for upgrading from a given product version to a higher
>> version.The end user was required to configure the latest product that they
>> are upgrading to against their current data(databases, synapse files,
>> registry) and run the migration client manually to upgrade the product.
>> This can be a cumbersome and error prone process to accomplish for end
>> users, making product version upgrades time consuming.
>>
>> To overcome the above problem on the fly upgrades were proposed where the
>> product code detects if relevant data being accessed needs to be migrated
>> to the latest version and migrates the data when the code is executed when
>> the respective feature is used. Upgrading product data is much easier from
>> 3.0.0 onwards because all data related to the product is stored in a
>> central database.This means that the end user does not need to get involved
>> in upgrading, it happens without them even being aware as they use the
>> latest version of the product by pointing it against their current
>> database.This makes for a more pleasant user experience when upgrading,
>> putting the burden of the upgrade to be added by the developer into the
>> functional code itself.
>>
>> The following outlines a design that can be supported from 3.0.0 onwards
>> to outline a uniform way of handling product upgrades. This is inspired by
>> the methodology used by FlywayDB to enable DB migrations[1]  but also
>> taking into account the requirement of being able to run on the fly at
>> runtime(Note: DB schema changes between releases will need to be handled
>> via DB vendor specific scripts prepared by the team to be run by the
>> customer against their DB).
>>
>>
>> *1.* A new table will be added to the schema called
>> PRODUCT_VERSION_AUDIT to track the product version upgrades that take place
>> on a given dataset
>>
>> PRODUCT_VERSION_AUDIT
>> VERSION VARCHAR(5)
>> CREATED_TIME TIMESTAMP(6)
>>
>> If a user begins using APIM version 3.0.0 and then upgrades to version
>> 3.1.0 the table will contain the following values,
>>
>> VERSION CREATED_TIME
>> 3.0.0 2018-11-11 13:23:44
>> 3.1.0 2019-10-14 9:26:22
>>
>> This gives a historical view of the product versions a customer has been
>> using. A new row will be inserted into the table when a given product
>> version is started for the first time.
>>
>>
>>
>> *2*. Each table in the database will have a new column called
>> PRODUCT_VERSION(VARCHAR(5)) added. When a row is inserted for the first
>> time it will populate this column with the current product version being
>> used.
>> For example the AM_API table could have the following entries for a
>> customer using APIM 3.0.0,
>>
>> UUID PROVIDER NAME VERSION CONTEXT PRODUCT_VERSION
>> 123e4567-e89b-12d3-a456-42665544 admin abc 1.0.0 /abc 3.0.0
>> 00112233-4455-6677-8899-aabbccddeeff admin xyz 1.0.0 /xyz 3.0.0
>>
>>
>> Lets assume when upgrading to 3.1.0 the leading '/' character in the
>> context needs to be removed. On the fly migration code will run when a
>> given row is accessed by the DAO layer to remove the '/'. Once the
>> migration of the row is completed the PRODUCT_VERSION column will be
>> updated with the value 3.1.0 to signify that the migration for this row has
>> been completed. The PRODUCT_VERSION column can be validated to check if
>> migration code needs to be executed. So assuming the API abc is accessed
>> first the table will look as follows after migration,
>>
>>
>> UUID PROVIDER NAME VERSION CONTEXT PRODUCT_VERSION
>> 123e4567-e89b-12d3-a456-42665544 admin abc 1.0.0 abc 3.1.0
>> 00112233-4455-6677-8899-aabbccddeeff admin xyz 1.0.0 /xyz 3.0.0
>>
>>
>> As a pre-requisite the product team will need to create respective DB
>> scripts for the schema changes that will take place with a given release.
>> This will only include schema modifications. Customer will need to run
>> these manually against their DB but actual data migration will take place
>> automatically under the hood.
>>
>>
>> *3*. New Java interfaces will be added for each DB entity that will
>> responsible for migrating the respective entity. For example for APIs

Re: [Architecture] [SP] [Siddhi]Change Data Capture for WSO2SP

2018-08-20 Thread Chathuranga Siriwardhana

Hi all,

I tried the CDC for MySQL with Debezium[1] and implemented as a simple java
program using embedded debezium[2].
Currently I am trying the Embedded Debezium for Oracle. The respected java
code can be found here.

https://github.com/chathuranga95/Embedded-Debezium-CDC/blob/master/src/main/java/io/debezium/App.java

Please note that the runMysqlCDC() is returning the MySQL database change
event details with row data and currently runOracleCDC() is not producing
expected output. Find the details of configuration from [2].

I also got started with the user story for this functionality. The source
will be as follows for MySQL bin-log CDC.


@source(type=’cdc’ , url=’jdbc:mysql://root:root@localhost:3306/dbStudents’,

@map(type='json', fail.on.missing.attribute='false'
,@attributes(operation=’$.operation, beforeID=’$.before.id’, beforeName=’$.
before.name’, afterID=’$.after.id’, afterName=’$.after.name’)))

define stream cdcEvent(operation String, beforeID String, beforeName
String, afterID String, afterName String);

[1] http://debezium.io/
[2] http://debezium.io/docs/embedded/

Best regards,
Chathuranga Siriwardhana,
Software Engineering Intern.
Mobile: +94713604485


On Tue, Jul 24, 2018 at 6:38 PM Niveathika Rajendran 
wrote:

> Hi Chathuranga,
>
> As discussed offline let's look at Debizum[1] as well especially
> embedded Debizium[2], which removes the dependency on Kafka[3]
>
> Also, shall we have a User Story review for the above functionality?
>
> [1] http://debezium.io/
> [2] http://debezium.io/docs/embedded/
> [3] Mail Thread : CDC (Change Data Capture) for Product-SP
>
> Best Regards,
> *Niveathika Rajendran,*
> *Software Engineer.*
> *Mobile : +94 077 903 7536*
>
>
>
>
>
> On Tue, Jul 24, 2018 at 12:25 PM Chathuranga Siriwardhana <
> chathuran...@wso2.com> wrote:
>
>>
>>
>>
>>
>>
>>
>>
>> *Hi all,I am currently working on the 'Change Data Capture for WSO2SP'.
>> As the first part of the project, I have to capture the change
>> events(INSERT, UPDATE, DELETE mainly) of a few databases using java. Mainly
>> I have focused on MySQL, MS-SQL server, ORACLE and PostgreSQL databases.For
>> now, I have used the following approaches to try to capture the change data
>> of relevant databases.DatabaseMethod UsedUsed connectors /
>> APIs.OutcomeStatusCommentsReferencesMySQLBinlog file based java event
>> listening. (Asynchronous)Mysql-binlog-connector-java(Apache 2.0
>> License)Change events(INSERT, UPDATE, DELETE) can be captured along with
>> the relevant row data.Complete[1]OracleDBDatabase Change Notification
>> feature based java event listeningOracle jdbc driverChange events(INSERT,
>> UPDATE, DELETE) can be captured without row data.Partially
>> Complete[2]PostgreSQLListen Notify functionality of the Postgres with
>> table-wise configuration and polling in the program.Postgres jdbc
>> driverChange events(INSERT, UPDATE, DELETE) without row data.IncompleteThis
>> method was discarded because a trigger should be written into each table in
>> order to get change events from that table.[3], [4]PostgreSQLReplication
>> Data based java pollingPhysical and Logical replication APIChange
>> events(INSERT, UPDATE, DELETE) can be captured. Row data is not returning
>> for DELETE event.Partially Complete[5]MS-SQL ServerTransaction Log based
>> java pollingMs-sql jdbc connectorOn progress; Transaction log is
>> read.On-going.[6], [7][1]
>> https://github.com/shyiko/mysql-binlog-connector-java
>> [2]
>> https://docs.oracle.com/cd/E11882_01/java.112/e16548/dbchgnf.htm#JJDBC28820
>> [3]
>> https://www.postgresql.org/docs/current/static/sql-notify.html
>> [4]
>> https://www.postgresql.org/docs/current/static/sql-listen.html
>> [5]
>> https://jdbc.postgresql.org/documentation/head/replication.html
>> [6]https://docs.microsoft.com/en-us/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-2017
>> [7]
>> https://dzone.com/articles/how-use-sql-server-transaction
>> *Please find
>> the shared Google Sheet containing above table. You may comment about the
>> existing approaches / mention any new approaches.
>>
>> Best regards,
>> Chathuranga Siriwardhana,
>> Software Engineering Intern.
>> Mobile: +94713604485
>>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM 3.0.0 - Supporting product upgrades as a first class feature

2018-08-20 Thread Uvindra Dias Jayasinha

Small calcification regarding this statement,

For the 3.0.0 release we just need to implement steps *1* and *2* above.
> Step *3* can be done for all subsequent releases.
>

I specifically meant the changes to the DB schema when it comes to steps 1
and 2 . Obviously no migration logic will be needed for 3.0.0 itself

On 20 August 2018 at 15:58, Uvindra Dias Jayasinha  wrote:

> In the past the APIM product has relied on an external component such as a
> migration client for upgrading from a given product version to a higher
> version.The end user was required to configure the latest product that they
> are upgrading to against their current data(databases, synapse files,
> registry) and run the migration client manually to upgrade the product.
> This can be a cumbersome and error prone process to accomplish for end
> users, making product version upgrades time consuming.
>
> To overcome the above problem on the fly upgrades were proposed where the
> product code detects if relevant data being accessed needs to be migrated
> to the latest version and migrates the data when the code is executed when
> the respective feature is used. Upgrading product data is much easier from
> 3.0.0 onwards because all data related to the product is stored in a
> central database.This means that the end user does not need to get involved
> in upgrading, it happens without them even being aware as they use the
> latest version of the product by pointing it against their current
> database.This makes for a more pleasant user experience when upgrading,
> putting the burden of the upgrade to be added by the developer into the
> functional code itself.
>
> The following outlines a design that can be supported from 3.0.0 onwards
> to outline a uniform way of handling product upgrades. This is inspired by
> the methodology used by FlywayDB to enable DB migrations[1]  but also
> taking into account the requirement of being able to run on the fly at
> runtime(Note: DB schema changes between releases will need to be handled
> via DB vendor specific scripts prepared by the team to be run by the
> customer against their DB).
>
>
> *1.* A new table will be added to the schema called PRODUCT_VERSION_AUDIT
> to track the product version upgrades that take place on a given dataset
>
> PRODUCT_VERSION_AUDIT
> VERSION VARCHAR(5)
> CREATED_TIME TIMESTAMP(6)
>
> If a user begins using APIM version 3.0.0 and then upgrades to version
> 3.1.0 the table will contain the following values,
>
> VERSION CREATED_TIME
> 3.0.0 2018-11-11 13:23:44
> 3.1.0 2019-10-14 9:26:22
>
> This gives a historical view of the product versions a customer has been
> using. A new row will be inserted into the table when a given product
> version is started for the first time.
>
>
>
> *2*. Each table in the database will have a new column called
> PRODUCT_VERSION(VARCHAR(5)) added. When a row is inserted for the first
> time it will populate this column with the current product version being
> used.
> For example the AM_API table could have the following entries for a
> customer using APIM 3.0.0,
>
> UUID PROVIDER NAME VERSION CONTEXT PRODUCT_VERSION
> 123e4567-e89b-12d3-a456-42665544 admin abc 1.0.0 /abc 3.0.0
> 00112233-4455-6677-8899-aabbccddeeff admin xyz 1.0.0 /xyz 3.0.0
>
>
> Lets assume when upgrading to 3.1.0 the leading '/' character in the
> context needs to be removed. On the fly migration code will run when a
> given row is accessed by the DAO layer to remove the '/'. Once the
> migration of the row is completed the PRODUCT_VERSION column will be
> updated with the value 3.1.0 to signify that the migration for this row has
> been completed. The PRODUCT_VERSION column can be validated to check if
> migration code needs to be executed. So assuming the API abc is accessed
> first the table will look as follows after migration,
>
>
> UUID PROVIDER NAME VERSION CONTEXT PRODUCT_VERSION
> 123e4567-e89b-12d3-a456-42665544 admin abc 1.0.0 abc 3.1.0
> 00112233-4455-6677-8899-aabbccddeeff admin xyz 1.0.0 /xyz 3.0.0
>
>
> As a pre-requisite the product team will need to create respective DB
> scripts for the schema changes that will take place with a given release.
> This will only include schema modifications. Customer will need to run
> these manually against their DB but actual data migration will take place
> automatically under the hood.
>
>
> *3*. New Java interfaces will be added for each DB entity that will
> responsible for migrating the respective entity. For example for APIs we
> can have,
>
> public interface APIMigrator {
> API migrate(PreparedStatement statement) throws MigrationException;}
>
>
>
> This will accept the PreparedStatement created for data retrieval and
> returns the migrated API object. The implemenataion of the above could look
> as follows,
>
> public class APIMigratorImpl implements APIMigrator {
>
> public API migrate(PreparedStatement statement) throws MigrationException 
> {
>   API api = null;
>   try (ResultSet

[Architecture] APIM 3.0.0 - Supporting product upgrades as a first class feature

2018-08-20 Thread Uvindra Dias Jayasinha

In the past the APIM product has relied on an external component such as a
migration client for upgrading from a given product version to a higher
version.The end user was required to configure the latest product that they
are upgrading to against their current data(databases, synapse files,
registry) and run the migration client manually to upgrade the product.
This can be a cumbersome and error prone process to accomplish for end
users, making product version upgrades time consuming.

To overcome the above problem on the fly upgrades were proposed where the
product code detects if relevant data being accessed needs to be migrated
to the latest version and migrates the data when the code is executed when
the respective feature is used. Upgrading product data is much easier from
3.0.0 onwards because all data related to the product is stored in a
central database.This means that the end user does not need to get involved
in upgrading, it happens without them even being aware as they use the
latest version of the product by pointing it against their current
database.This makes for a more pleasant user experience when upgrading,
putting the burden of the upgrade to be added by the developer into the
functional code itself.

The following outlines a design that can be supported from 3.0.0 onwards to
outline a uniform way of handling product upgrades. This is inspired by the
methodology used by FlywayDB to enable DB migrations[1]  but also taking
into account the requirement of being able to run on the fly at
runtime(Note: DB schema changes between releases will need to be handled
via DB vendor specific scripts prepared by the team to be run by the
customer against their DB).


*1.* A new table will be added to the schema called PRODUCT_VERSION_AUDIT
to track the product version upgrades that take place on a given dataset

PRODUCT_VERSION_AUDIT
VERSION VARCHAR(5)
CREATED_TIME TIMESTAMP(6)

If a user begins using APIM version 3.0.0 and then upgrades to version
3.1.0 the table will contain the following values,

VERSION CREATED_TIME
3.0.0 2018-11-11 13:23:44
3.1.0 2019-10-14 9:26:22

This gives a historical view of the product versions a customer has been
using. A new row will be inserted into the table when a given product
version is started for the first time.



*2*. Each table in the database will have a new column called
PRODUCT_VERSION(VARCHAR(5)) added. When a row is inserted for the first
time it will populate this column with the current product version being
used.
For example the AM_API table could have the following entries for a
customer using APIM 3.0.0,

UUID PROVIDER NAME VERSION CONTEXT PRODUCT_VERSION
123e4567-e89b-12d3-a456-42665544 admin abc 1.0.0 /abc 3.0.0
00112233-4455-6677-8899-aabbccddeeff admin xyz 1.0.0 /xyz 3.0.0


Lets assume when upgrading to 3.1.0 the leading '/' character in the
context needs to be removed. On the fly migration code will run when a
given row is accessed by the DAO layer to remove the '/'. Once the
migration of the row is completed the PRODUCT_VERSION column will be
updated with the value 3.1.0 to signify that the migration for this row has
been completed. The PRODUCT_VERSION column can be validated to check if
migration code needs to be executed. So assuming the API abc is accessed
first the table will look as follows after migration,


UUID PROVIDER NAME VERSION CONTEXT PRODUCT_VERSION
123e4567-e89b-12d3-a456-42665544 admin abc 1.0.0 abc 3.1.0
00112233-4455-6677-8899-aabbccddeeff admin xyz 1.0.0 /xyz 3.0.0


As a pre-requisite the product team will need to create respective DB
scripts for the schema changes that will take place with a given release.
This will only include schema modifications. Customer will need to run
these manually against their DB but actual data migration will take place
automatically under the hood.


*3*. New Java interfaces will be added for each DB entity that will
responsible for migrating the respective entity. For example for APIs we
can have,

public interface APIMigrator {
API migrate(PreparedStatement statement) throws MigrationException;}



This will accept the PreparedStatement created for data retrieval and
returns the migrated API object. The implemenataion of the above could look
as follows,

public class APIMigratorImpl implements APIMigrator {

public API migrate(PreparedStatement statement) throws MigrationException {
API api = null;
try (ResultSet rs = statement.executeQuery()) {
while (rs.next()) {
String dataProductVersion = rs.getString("PRODUCT_VERSION");

// Assume that currentProductVersion == "3.2.0"

while (!currentProductVersion.equals(dataProductVersion)) }
if ("3.0.0".equals(dataProductVersion)) {
// Logic to migrate data to next available version 3.1.0
// And update the PRODUCT_VERSION column of the row to 
3.1.0

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

2018-08-20 Thread Sanjeewa Malalgoda

Forgot password feature should comes with some sort of user
verification(enter security question or send email verification, sms
verification etc).
That feature need to implement with some extensions as all are not using
same verification process.
So i think we can first complete this and come back to that feature.

Thanks,
sanjeewa.


On Mon, Aug 20, 2018 at 11:42 AM Mushthaq Rumy  wrote:

> +1. I too think that forgot password option is more important and it is
> not yet implemented. I would prefer if we start on that first.
>
> Thanks & Regards,
> Mushthaq
>
> On Mon, Aug 20, 2018 at 11:40 AM Nuwan Dias  wrote:
>
>> Do we have a forgot password option on the Store? I would think that is
>> more important for an API Store than a change password functionality.
>>
>> On Mon, Aug 20, 2018 at 11:22 AM Vithursa Mahendrarajah <
>> vithu...@wso2.com> wrote:
>>
>>> Hi all,
>>> I am working on $subject in APIM 3.0.0. Planned flow of implementation
>>> is as follows:
>>>
>>> [image: new_password_mail.png]
>>> We have SCIM API [1] for updating user-info. A separate REST API can be
>>> implemented to provide the feature to change password by wrapping mentioned
>>> SCIM API. The sample resource could be as,
>>>
>>> PasswordChangeRequest:
>>> title: Request for changing password
>>> required:
>>>   - username
>>>   - currentPassword
>>>   - newPassword
>>> properties:
>>>   username:
>>> type: string
>>>   currentPassword:
>>> type: string
>>>   newPassword:
>>> type: string
>>>
>>> Please provide your thoughts and feedback on this.
>>>
>>> Thanks,
>>> Vithursa
>>> --
>>> Vithursa Mahendrarajah
>>> Software Engineer
>>> WSO2 Inc. - http ://wso2.com
>>> Mobile  : +947*66695643*
>>>
>>>
>>> *  
>>> *
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Director - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> Mushthaq Rumy
> *Senior Software Engineer*
> Mobile : +94 (0) 779 492140
> Email : musht...@wso2.com
> WSO2, Inc.; http://wso2.com/
> lean . enterprise . middleware.
>
> 
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94 712933253

blog
:http://sanjeewamalalgoda.blogspot.com/

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

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

2018-08-20 Thread Mushthaq Rumy

+1. I too think that forgot password option is more important and it is not
yet implemented. I would prefer if we start on that first.

Thanks & Regards,
Mushthaq

On Mon, Aug 20, 2018 at 11:40 AM Nuwan Dias  wrote:

> Do we have a forgot password option on the Store? I would think that is
> more important for an API Store than a change password functionality.
>
> On Mon, Aug 20, 2018 at 11:22 AM Vithursa Mahendrarajah 
> wrote:
>
>> Hi all,
>> I am working on $subject in APIM 3.0.0. Planned flow of implementation is
>> as follows:
>>
>> [image: new_password_mail.png]
>> We have SCIM API [1] for updating user-info. A separate REST API can be
>> implemented to provide the feature to change password by wrapping mentioned
>> SCIM API. The sample resource could be as,
>>
>> PasswordChangeRequest:
>> title: Request for changing password
>> required:
>>   - username
>>   - currentPassword
>>   - newPassword
>> properties:
>>   username:
>> type: string
>>   currentPassword:
>> type: string
>>   newPassword:
>> type: string
>>
>> Please provide your thoughts and feedback on this.
>>
>> Thanks,
>> Vithursa
>> --
>> Vithursa Mahendrarajah
>> Software Engineer
>> WSO2 Inc. - http ://wso2.com
>> Mobile  : +947*66695643*
>>
>>
>> *  
>> *
>>
>
>
> --
> Nuwan Dias
>
> Director - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Mushthaq Rumy
*Senior Software Engineer*
Mobile : +94 (0) 779 492140
Email : musht...@wso2.com
WSO2, Inc.; http://wso2.com/
lean . enterprise . middleware.


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

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

2018-08-20 Thread Nuwan Dias

Do we have a forgot password option on the Store? I would think that is
more important for an API Store than a change password functionality.

On Mon, Aug 20, 2018 at 11:22 AM Vithursa Mahendrarajah 
wrote:

> Hi all,
> I am working on $subject in APIM 3.0.0. Planned flow of implementation is
> as follows:
>
> [image: new_password_mail.png]
> We have SCIM API [1] for updating user-info. A separate REST API can be
> implemented to provide the feature to change password by wrapping mentioned
> SCIM API. The sample resource could be as,
>
> PasswordChangeRequest:
> title: Request for changing password
> required:
>   - username
>   - currentPassword
>   - newPassword
> properties:
>   username:
> type: string
>   currentPassword:
> type: string
>   newPassword:
> type: string
>
> Please provide your thoughts and feedback on this.
>
> Thanks,
> Vithursa
> --
> Vithursa Mahendrarajah
> Software Engineer
> WSO2 Inc. - http ://wso2.com
> Mobile  : +947*66695643*
>
>
> *  
> *
>


-- 
Nuwan Dias

Director - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

Re: [Architecture] APIM 3.0.0 - Supporting product upgrades as a first class feature

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

Re: [Architecture] APIM 3.0.0 - Supporting product upgrades as a first class feature

Re: [Architecture] [SP] [Siddhi]Change Data Capture for WSO2SP

Re: [Architecture] APIM 3.0.0 - Supporting product upgrades as a first class feature

[Architecture] APIM 3.0.0 - Supporting product upgrades as a first class feature

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

11 matches

Site Navigation

Mail list logo

Footer information