Hi, *Regarding Isabelle's concerns,*
a) This feature will be available as a custom application. Therefore we decided to package this as a WAR. b) The QoS details will also be stored in the API c) Swagger file is also inside the meta information. *Regarding Srinath's concerns,* We are storing meta-information in JSON format. We only support Swagger and it will be stored under meta information. Regarding sequences and environment specific setup, shall we allow importing users to add them according to their preference? Appreciate your feedback on this. Thank you. Thilini. On Tue, May 5, 2015 at 8:36 AM, Srinath Perera <[email protected]> wrote: > Hi Thilini, > > What is the format of meta information? we need to discuss that also in > this thread. > > Do we support both Swagger and WADL? if yes Swagger should go in the > archive and we have to decide where. > > Regarding ESB sequences, one option is to export the API without sequences > and let users add sequences via UI or configurations. ( Same approach we > took with Services and Axis2 modules years ago.) > > --Srinath > > On Mon, May 4, 2015 at 3:36 PM, Isabelle Mauny <[email protected]> wrote: > >> All, >> >> Can you please confirm: >> a) That the packaging is a CApp (i.e. talks to API Manager deployer). >> b) Where is the QOS setup stored ( the managed part ) - For backup >> purposes, it would be great to attach QoS to the API. or do we assume that >> users will have to attach the QoS part manually (i.e.. after deployment we >> get an API in CREATE mode). >> c) Where is the Swagger file describing the API stored ? As part of >> meta-data ? >> >> I don't think sequences themselves should be there, just the link. >> Sequences are reusable across APIs and must not be deployed as part of the >> API itself. However, I should be able to package a set of sequences and >> deploy them to an API Manager (again, as CApp, as we do for the ESB). The >> sequences themselves can be managed/versioned/ separately. >> >> As for the tiers etc, those are dependent setup that must be in place >> before you import in the target environment - Part of the env preparation. >> We could create an import/export for that too (it's a simple check.out/ >> check.in from registry). Same applies to workflows, store definitions, >> etc. >> >> Isabelle. >> __________________________________________________ >> >> >> *Isabelle Mauny*VP, Product Management; WSO2, Inc.; http://wso2.com/ >> On Apr 22, 2015, at 4:38 PM, Colin Roy-Ehri <[email protected]> wrote: >> >> Hi! >> >> I'm really excited about this feature - it will be of great benefit to >> our customers. >> >> I have no improvements to suggest on your implementation plan. >> >> One point you might want to work into your tests is to ensure the swagger >> definitions remain consistent after an import/export. Of particular >> concern is the swagger YAML definitions available through the publisher. >> It shouldn't be too hard to code into a test. :) >> >> Thanks, >> Colin >> >> Thanks, >> Colin Roy-Ehri >> Software Engineer >> *WSO2, Inc. : wso2.com <http://wso2.com/>* >> *Mobile* : 812-219-6517 >> >> On Wed, Apr 22, 2015 at 7:15 AM, Thilini Cooray <[email protected]> >> wrote: >> >>> Hi all, >>> >>> We are in the process of introducing API Export and Import feature for >>> WSO2 API Manager. >>> >>> This feature can be used in scenarios such as moving APIs from staging >>> to production environment. >>> >>> *API Export* >>> >>> - This operation mainly sends an archive which consists of all the >>> required resources for a API to be recreated in another API Manager >>> instance. >>> - We have identified following folder structure to be included in >>> the archive >>> >>> <Screen Shot 2015-04-22 at 3.20.47 PM.png> >>> >>> >>> >>> >>> *API Import* >>> >>> - Import feature accepts an API archive with the above mentioned >>> structure and create a new API under current provider. >>> >>> *Feature Implementation* >>> >>> - Generating archive (in API export) and extracting archive (in API >>> import) can either be done in server or client side >>> - Currently we are planning to develop a RESTful API for export and >>> import functionality where archive generation for requested APIs and all >>> the related functionality are taken place in the server side. >>> - Decision for server side implementation was mainly made due to >>> high number of network calls and high possibility of network failures >>> that >>> can happen in client side. >>> - The RESTful service is halfway done. currently it can export and >>> import meta information only. >>> - *Export API* method calls >>> org.wso2.carbon.apimgt.api.APIProvider.getAPI(APIIdentifier) >>> and transforms received API object to a json file. >>> - *Import API* method receives json file via RESTful call and >>> converts the json to an API object. This object is then sent to >>> org.wso2.carbon.apimgt.api.APIProvider.addAPI(api) method and a >>> new API will get created. >>> - Several concerns can arise with this implementation approach >>> 1. API object can have environment specific details which are not >>> compatible with the importing environment >>> 2. There are some customisable attributes such as tiers (Ex : >>> tiers in exporting environment may not be available in importing side) >>> which may not be available on the importing environment >>> - Therefore we would like to know whether there is a better approach >>> for implementing this. >>> >>> Suggestions and ideas for implementing this export import API feature is >>> highly welcome. >>> >>> Thank you. >>> >>> >>> -- >>> Best Regards, >>> >>> *Thilini Cooray* >>> Software Engineer >>> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194> >>> E-mail : [email protected] >>> >>> WSO2 Inc. www.wso2.com >>> lean.enterprise.middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://people.apache.org/~hemapani/ > http://srinathsview.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Best Regards, *Thilini Cooray* Software Engineer Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194> E-mail : [email protected] WSO2 Inc. www.wso2.com lean.enterprise.middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
