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 <[email protected]> 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 > better than enhancing the current App and CLI? Its obviously going to be a > lot more work than approach 1, plus at the end of the day we will throw > away one of those tools because we don't need two tools doing the same > thing. > > On Tue, Jul 31, 2018 at 10:10 PM Samitha Chathuranga <[email protected]> > wrote: > >> >> Hi all, >>> >>> This is regarding the initial design on possible approaches to proceed >>> with upgrading APIM 2.6.0(to be released) to 3.0.0. The migration process >>> has been already decided to implement through an export/import approach as >>> a database migration approach won't be realistic as for older versions. So >>> the simple generic approach is that each artifact specially APIs and >>> Applications would be exported from 2.6.0 environment and then will be >>> imported in to 3.0.0 environment. >>> >>> Below I have listed the possible two approaches for both these two steps >>> (importing & exporting) followed by their pros and cons. >>> >>> Exporting : >>> >>> Approach 1 : Change currently existing Api Import/export web app and CLI >>> tool in 2.6 >>> >>> >>> >>> - >>> >>> Can use API Import/export Web app and CLI tool and modify >>> - >>> >>> (REST APIs for export api/applications is currently provided via >>> this WEB app. CLI tool uses this web app) >>> - >>> >>> Required changes: >>> - >>> >>> For app export: Consumer key, Consumer Secret, Token exporting >>> should be supported in CLI tool >>> - >>> >>> Will have to change admin REST api implementation for above task >>> and for exporting other artifacts mentioned at the end. >>> - >>> >>> Modify CLI tool to support exporting in bulk. >>> >>> >>> >>> - >>> >>> Pros >>> - >>> >>> Will not have to develop/maintain a Web app and CLI tool from the >>> scratch >>> - >>> >>> Cons >>> - >>> >>> API export flow will change as modifications will be required >>> - >>> >>> Have to manage and consider also about normal export feature when >>> doing changes for migration-exporting. >>> - >>> >>> Migration story cannot be done in single step. Exporting and >>> importing will be 2 step process. >>> >>> >>> >>> Approach 2 : Develop a separate tool without using API Import/export Web >>> app or CLI tool. >>> >>> >>> - >>> >>> Create a WEB App introducing new REST APIs required and develop >>> separate CLI tool. >>> >>> >>> >>> - >>> >>> Pros >>> - >>> >>> Migration story can be done in single step. (Exporting and >>> importing can be done in single command.) >>> - >>> >>> API/Application import-export tool won’t have any effect or >>> change. >>> - >>> >>> Don’t have to manage 2 separate use cases in single tool. >>> - >>> >>> Cons >>> - >>> >>> Will have to develop/maintain a Web app and/or CLI tool from the >>> scratch >>> >>> >>> >>> Importing : >>> >>> >>> - >>> >>> Has to create separate REST APIs for importing 2.6-exported >>> APIs/Applications/other artifacts as 3.0.0 expecting archives in 3.0 >>> specific format. >>> >>> >>> Approach 1 >>> >>> - >>> >>> Change/improve API Import/export CLI tool in 3.0 to support >>> importing 2.6-exported API/application archives. >>> >>> Approach 2 >>> >>> - >>> >>> Develop separate CLI tool from the scratch which will be used for >>> exporting from 2.6 also >>> >>> >>> >>> Other artifacts required to be exported/imported (other than >>> APIs/Applications) >>> >>> >>> - >>> >>> Throttling Policies >>> - >>> >>> Custom API Lifecycles >>> - >>> >>> Workflows >>> - >>> >>> User Role Permissions >>> - >>> >>> Custom sequences (at least for reference -> has to decide regarding >>> this) >>> >>> >>> >>> My perception is that proceeding with Approach 2 under both exporting >>> and importing would be better considering the pros and cons of each. >>> >>> Highly appreciate your thoughts on this. >>> >>> Regards, >>> >>> Samitha >>> >>> >>> -- >>> *Samitha Chathuranga* >>> *Senior Software Engineer*, *WSO2 Inc.* >>> lean.enterprise.middleware >>> Mobile: +94715123761 >>> >>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>> >> >> >> > > -- > Nuwan Dias > > Director - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > -- *Samitha Chathuranga* *Senior Software Engineer*, *WSO2 Inc.* lean.enterprise.middleware Mobile: +94715123761 [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
