HI Chamin, Will the user be notified about the summary of success/failure of the entire Import process? For example, importing API aritfact is successful, Importing tiers failed due to unsupported tier found, etc?
Thanks and Regards, Harshana -- Harshana Eranga Martin Committer - Eclipse ECF: http://www.eclipse.org/ecf/ Blog: http://harshana05.blogspot.com Profile: https://www.google.com/profiles/harshana05 On 20 May 2015 at 12:46, Chamin Dias <[email protected]> wrote: > Hi all, > > A slight modification has been proposed and agreed at the review, > regarding the tier check of API Import process. According to that, we > decided to import the new API by including only the supported tiers. If > there are any unsupported tiers, those will be ignored and removed from the > imported API. > > Thanks. > > On Thu, May 14, 2015 at 11:56 AM, Nuwan Dias <[email protected]> wrote: > >> In case of a failure, it should return an HTTP 500 mentioning the reason >> for failure accurately. >> >> Thanks, >> NuwanD. >> >> On Thu, May 14, 2015 at 10:58 AM, Chamin Dias <[email protected]> wrote: >> >>> Hi all, >>> >>> When importing an API, we are going to check the tier availability as >>> well. The new API is imported, only if the all tiers of the API in the >>> archive is available in the deployment environment. This check is performed >>> before importing the API. If this check fails, the importing process is >>> cancelled because there is an incompatibility in API tiers. >>> >>> Thanks. >>> >>> On Thu, May 7, 2015 at 3:50 AM, Nuwan Dias <[email protected]> wrote: >>> >>>> @Harshana, >>>> >>>> These sequences are different from what you'd see on an ESB project. >>>> These sequences should be imported to (and exported from) the registry. Not >>>> from the filesystem. When deploying them as synapse sequences, we need to >>>> modify its names, etc (there's some logic behind deploying them). So we >>>> cannot be reusing the existing sequence deployer as it is. We will either >>>> have to extend it (if possible) or write from scratch. >>>> >>>> @Isabelle, >>>> >>>> The current packaging includes all data related to an API (docs, >>>> swagger and everything). >>>> >>>> In a meeting with Sanjiva, etc we decided to go for this approach >>>> rather than going for a CApp. I don't remember the exact details of it now >>>> but we had several objectives. Some are, >>>> >>>> 1. To be able to do this separately from a product release as a >>>> separate tool (due to high demand of this feature and tight release >>>> schedules). Developing a separate jax-rs enables you to deploy it on a >>>> server and get the functionality working without having to modify or depend >>>> on the products capability. The jax-rs consumes the existing java APIs for >>>> fetching/adding API info, hence we have a single code base for adding APIs >>>> both through UI and through import/export. >>>> >>>> 2. The need of a RESTful interface for importing/exporting an API >>>> artifact. >>>> >>>> I do agree that it would have been perfect to have a CApp while meeting >>>> the objectives above. But that would mean that this capability gets pushed >>>> further down the line since it would depend on additional features to be >>>> added to the product. >>>> >>>> Thanks, >>>> NuwanD. >>>> >>>> On Thu, May 7, 2015 at 7:06 AM, Colin Roy-Ehri <[email protected]> wrote: >>>> >>>>> Hi Sanjeewa, >>>>> >>>>> I know there are some changes in swagger import and edit management >>>>> coming in the new APIM version. Will we be able to guarantee that the >>>>> swagger definition will be totally reproducible from the exported API >>>>> definition? If so, then we should not include swagger in the API export. >>>>> If the customer has some comments or details in the swagger YAML or JSON, >>>>> which are not reflected in the API definition, then we may need to export >>>>> and import the swagger along with the API definition, even if they will >>>>> only be used for reference by the customer. >>>>> >>>>> +1 for using a C-App. >>>>> >>>>> Thanks, >>>>> Colin Roy-Ehri >>>>> Software Engineer >>>>> *WSO2, Inc. : wso2.com <http://wso2.com/>* >>>>> *Mobile* : 812-219-6517 >>>>> >>>>> On Wed, May 6, 2015 at 2:39 PM, Isabelle Mauny <[email protected]> >>>>> wrote: >>>>> >>>>>> I am sorry, I don't understand your logic and I am +1 with Harshana >>>>>> (HI there !) >>>>>> >>>>>> This is not about importing and exporting APIs, it's about enabling >>>>>> the automated deployment of API artifacts across multiple environments. >>>>>> That's the target goal- Import and export is a side-effect of that-Let's >>>>>> focus on that first - How the file will be generated underneath is an >>>>>> implementation detail.- >>>>>> >>>>>> We need to create a packaged delivery application, which contains the >>>>>> API defintion, it's meta-data, attached description (WADL, WSDl, etc.) , >>>>>> attached docs (files, URLs.) - If we don't do that, we don't fulfill the >>>>>> requirement of passing a FULL API definition across environments. >>>>>> >>>>>> The CApp *is* the archive- And we need to desing the structure of >>>>>> that CApp. If we do something else, people will have to repackage their >>>>>> APIs when we move to a CApp. I think the priority is to design the >>>>>> contents/structure of that archive. >>>>>> >>>>>> Thanks, >>>>>> Isabelle. >>>>>> >>>>>> ------------------------------------------------------------------------------------- >>>>>> *Isabelle Mauny* >>>>>> VP, Product Management - WSO2, Inc. - http://wso2.com/ >>>>>> >>>>>> >>>>>> >>>>>> On Wed, May 6, 2015 at 10:58 AM, Sanjeewa Malalgoda < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, May 6, 2015 at 11:30 AM, Harshana Eranga Martin < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Thilini, >>>>>>>> >>>>>>>> I think this is a very useful feature for the platform. API >>>>>>>> Management users are going to benefit from this a lot as we have been >>>>>>>> facing the issue for long time with multiple environments. >>>>>>>> >>>>>>>> I have few concerns about the implementation though. Please see the >>>>>>>> comments inline. >>>>>>>> >>>>>>>> Thanks and Regards, >>>>>>>> Harshana >>>>>>>> -- >>>>>>>> Harshana Eranga Martin >>>>>>>> Senior Software Engineer >>>>>>>> Asian Mobile Banking >>>>>>>> Web: https://www.commbank.com.au/ <http://wso2.com> >>>>>>>> >>>>>>>> ECF Committer: http://www.eclipse.org/ecf/ >>>>>>>> Blog: http://harshana05.blogspot.com >>>>>>>> Profile: https://www.google.com/profiles/harshana05 >>>>>>>> >>>>>>>> On 6 May 2015 at 11:43, Thilini Cooray <[email protected]> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> *Regarding Isabelle's concerns,* >>>>>>>>> >>>>>>>>> a) This feature will be available as a custom application. >>>>>>>>> Therefore we decided to package this as a WAR. >>>>>>>>> >>>>>>>> >>>>>>>> I think it is not right to export APIs as a WAR file. WAR is >>>>>>>> already a well known file extension allocated for Web-Apps. It is >>>>>>>> going to >>>>>>>> complicate the life of users of both Web-Apps and API Management >>>>>>>> feature. >>>>>>>> >>>>>>> >>>>>>> Actually its not the archive format for APIs. >>>>>>> What they meant was they develop this rest API (for archive APIs) as >>>>>>> jax-rs application and bundled it as WAR file in away that we can >>>>>>> deploy in >>>>>>> API Manager server. >>>>>>> Then you will call to that JAX-RS service and request archived APIs >>>>>>> and it will return as .zip file. >>>>>>> You will get that data as multipart form data or any other format. >>>>>>> >>>>>>> >>>>>>>> I also believe as Isabelle suggested exporting the API as an >>>>>>>> artifact in the C-App would be the best mechanism. This will allow you >>>>>>>> to >>>>>>>> implement a new C-App artifact deployer for API manager and >>>>>>>> introduction of >>>>>>>> new Artifact type with an artifact structure. This Artifact deployer >>>>>>>> will >>>>>>>> understand the artifact metadata structure and knows how to interpret >>>>>>>> the >>>>>>>> metadata as well as generation of the metadata and the artifact when >>>>>>>> someone requests to export from the Publisher App. This would be a >>>>>>>> clean >>>>>>>> way to implement the export and import feature. >>>>>>>> >>>>>>> Yes C-App would be good approach. But adding API is bit complicate >>>>>>> process that and adding sequence, proxy service etc. So i think we can >>>>>>> start with API archive and then later bundle it to C-App, WDYT? >>>>>>> >>>>>>>> >>>>>>>> Having the API as an separate entity in the C-App would help the >>>>>>>> concern of deployment of Sequences as well since Sequences are already >>>>>>>> an >>>>>>>> artifact type supported in the Platform. Hence you can export and >>>>>>>> import >>>>>>>> the API and Sequence independent of each other using C-App. API will >>>>>>>> contain the reference to the Sequence in the API artifact and once the >>>>>>>> C-App deployed, it will deploy the API artifact as well as referenced >>>>>>>> Sequence. It will allow you to reuse the same sequence across multiple >>>>>>>> APIs >>>>>>>> while the Sequence itself can be governed independently of the APIs. >>>>>>>> >>>>>>>> Thanks and Regards, >>>>>>>> Harshana >>>>>>>> >>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>> Actually we do not need to export swagger content when we export >>>>>>> API. >>>>>>> Swagger is just a definition that we use to import API definition. >>>>>>> And in future we may use different API description languages. >>>>>>> Once we imported it to our platform we need to maintain all data in >>>>>>> our platform. >>>>>>> So IMO we dont need to include swagger json to archive, Instead of >>>>>>> that we should be able to generate swagger based on our API metadata. >>>>>>> And our plan is to make it customizable in future. So if you need to >>>>>>> generate swagger, raml or any other API description base on our metadata >>>>>>> you need to implement interface provided by us. >>>>>>> Lets not bind to single API description language and make this >>>>>>> generic as much as. >>>>>>> >>>>>>> >>>>>>>>> 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. >>>>>>>>>> >>>>>>>>> IMO we don't need to export swagger content. We should be able to >>>>>>> generate swagger or any other API description based on API meta data in >>>>>>> archived API. >>>>>>> Since we do not directly use WADL to import APIs we may need to >>>>>>> maintain WADL as resource of API data. >>>>>>> >>>>>>> Thanks, >>>>>>> sanjeewa. >>>>>>> >>>>>>>> >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Sanjeewa Malalgoda* >>>>>>> WSO2 Inc. >>>>>>> Mobile : +94713068779 >>>>>>> >>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Technical Lead - WSO2, Inc. http://wso2.com >>>> email : [email protected] >>>> Phone : +94 777 775 729 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Chamin Dias >>> *Software Engineer* >>> Mobile : +94 (0) 716 097455 <%2B94%20%280%29%20773%20451194> >>> [email protected] >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Nuwan Dias >> >> Technical Lead - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Chamin Dias > *Software Engineer* > Mobile : +94 (0) 716 097455 <%2B94%20%280%29%20773%20451194> > [email protected] > > _______________________________________________ > 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
