@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
