Hi, ATM this tool can only be used by users with admin role.
Thanks. On Wed, Aug 3, 2016 at 12:00 PM, Janaka Ranabahu <[email protected]> wrote: > Hi Thilini, > > On Wed, Aug 3, 2016 at 11:40 AM, Janaka Ranabahu <[email protected]> wrote: > >> Hi, >> >> On Wed, Aug 3, 2016 at 9:54 AM, Thilini Cooray <[email protected]> wrote: >> >>> Hi Janaka, >>> >>> >>> On Tue, Aug 2, 2016 at 5:43 PM, Janaka Ranabahu <[email protected]> wrote: >>> >>>> Hi Malintha, Kaveesha, >>>> >>>> On Fri, Jul 22, 2016 at 3:29 PM, Malintha Amarasinghe < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Jul 22, 2016 at 3:25 PM, Malintha Amarasinghe < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> +1 for this improvement as it will make the developer's life easy >>>>>> when exporting/importing multiple APIs. >>>>>> >>>>>> The option [2] is better in situations like there are many APIs to >>>>>> bulk export so that the it might be difficult for a user to specify each >>>>>> and every APIs to export: what he wants is simply export all the APIs >>>>>> available. The overhead of the API call is not significant IMHO; there >>>>>> will >>>>>> be only one (or very few) additional calls to getAllAPIs. >>>>>> >>>>>> But as we discussed offline, we can start from step [1], and then >>>>>> improve it by adding step [2]. >>>>>> >>>>> Step 1: CSV file with list of API name/version/provider --> Bulk >>>>> export >>>>> Step 2: call getAllApis() and get the list of APIs --> Generates the >>>>> CSV file (we can implement this as a different operation and then provide >>>>> the generated CSV file as an input to Step1) >>>>> >>>> Do we really have a use-case where a customer has to import/export all >>>> the APis in a environment. It is highly unlikely that this would happen. >>>> IMO, we should only support the file based approach. That would be >>>> sufficient for the bulk import/export purposes. >>>> >>> >>> What if a user decides to move from one environment to another (from Dev >>> to QA or on-premise to API Cloud etc.) and wants to move all his deployed >>> APIs to the new environment? >>> If he has a huge number of APIs, IMO it would not be easy to name them >>> one by one on a file. Rather it would be easy if we have an option to >>> export and import as a whole. >>> >> Quick clarification. In this scenario, we are only considering the APIs > published by that user right? Not all the APIs in the system is it? Or do > we have to be a admin user who has access to all the APIs? > > >> >>> I too agree that this is not a first priority use case for the tool that >>> we need to address, however IMO this is something better to have. >>> >> Agreed. Then we do not have to call getAllApis() and create a CSV out of >> that. Just sending a query parameter saying all APIs would be sufficient >> right? >> >> Thanks, >> Janaka >> >> >>> >>> WDYT? >>> >>> Thanks, >>> ThiliniC. >>> >>> >>> >>>> >>>> Thanks, >>>> Janaka >>>> >>>>> >>>>> >>>>> Regarding the file format I would prefer CSV as it would make it easy >>>>>> to edit if need using existing tools. WDYT? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> On Fri, Jul 22, 2016 at 10:58 AM, Kaveesha Perera <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I'm planing to improve APIM import/export tool to support bulk >>>>>>> import and bulk export of APIs. >>>>>>> >>>>>>> When considering the bulk export, there it came up to a discussion >>>>>>> point on how to get the API list to be export. Considering several >>>>>>> facts, >>>>>>> came up with two suggestions as follows. >>>>>>> >>>>>>> [1]. Asking user to submit a file with explicitly written list of >>>>>>> APIs. (API detail may include name, version and provider) >>>>>>> >>>>>>> [2]. Getting the prevailing list of APIs using getAllAPIs REST API, >>>>>>> save the usable content of resulting string in a separate file, then >>>>>>> allow >>>>>>> user to edit it such that he can remove the unwanted APIs from the >>>>>>> list, >>>>>>> use it as a input for the bulk export. >>>>>>> >>>>>>> Currently we prefer procedure [1], since the process [2] creates >>>>>>> additional overhead due to the REST API call. Still there can be are >>>>>>> pros >>>>>>> and cons in both the processors. If any opinions on above and any >>>>>>> options >>>>>>> please do reply. >>>>>>> >>>>>>> Regards. >>>>>>> -- >>>>>>> Kaveesha Perera >>>>>>> Intern - Software Engineering >>>>>>> >>>>>>> mobile: 0716130471 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Malintha Amarasinghe >>>>>> Software Engineer >>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>> http://wso2.com/ >>>>>> >>>>>> Mobile : +94 712383306 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Malintha Amarasinghe >>>>> Software Engineer >>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>> http://wso2.com/ >>>>> >>>>> Mobile : +94 712383306 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Janaka Ranabahu* >>>> Associate Technical Lead, WSO2 Inc. >>>> http://wso2.com >>>> >>>> >>>> *E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 >>>> <%2B94%20718370861>* >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> *Janaka Ranabahu* >> Associate Technical Lead, WSO2 Inc. >> http://wso2.com >> >> >> *E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 >> <%2B94%20718370861>* >> >> Lean . Enterprise . Middleware >> > > > > -- > *Janaka Ranabahu* > Associate Technical Lead, WSO2 Inc. > http://wso2.com > > > *E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 > <%2B94%20718370861>* > > Lean . Enterprise . Middleware > > _______________________________________________ > 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
