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
