On 13 October 2016 at 17:51, Rajith Roshan wrote:
> Hi,
>
> The current implementation keeps the data in a separate database. For now
> life cycle component has its own data source. I think its better to read
> the data source name from a configuration so the tables related to life
> cycle opera
FYI let me give some details regarding how we are testing the APIM DAO
layer for C5.
1. The DAO layer is an interface that the rest of our code interacts with
in order to store and retrieve data. We mock the DOA layer and can control
its behaviour to unit test how the rest of our code behaves when
ts and have the cost
>>> i mentioned above.
>>>
>>> Thank you,
>>> Dharshana.
>>>
>>> On Fri, May 19, 2017 at 11:53 AM, Malaka Gangananda
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Actually JavaDB d
+1, looks good
On 29 June 2017 at 12:27, Malintha Amarasinghe wrote:
>
>
> On Thu, Jun 29, 2017 at 12:20 PM, Harsha Kumara wrote:
>
>>
>>
>> On Thu, Jun 29, 2017 at 11:43 AM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> Bhathiya and I had a discussion about this a
There is a JIRA[1] for this that I moved to github
[1] https://wso2.org/jira/browse/APIMANAGER-5802
On 30 August 2017 at 11:07, Rukshan Premathunga wrote:
> Hi all,
>
> In c4 we had separate log file to audit API and application related stuff.
> Is this already done in AM 3?
>
> Thanks and Reg
Hi All,
It seems that currently we do not have a clear definition in regarding what
users can do with shared applications. This has been highlighted in[1] and
the plan is to address this as part of the APIM 2.2.0 release.
There are two types of users, the *App owner* who creates the App and
the *
a Application
On 7 February 2018 at 11:18, Nuwan Dias wrote:
>
>
> On Wed, Feb 7, 2018 at 11:14 AM, Uvindra Dias Jayasinha
> wrote:
>
>> Hi All,
>>
>> It seems that currently we do not have a clear definition in regarding
>> what users can do with shared
generate token with resource
> owner grant by non app owner may cause issues.
>
> Thanks,
> sanjeewa.
>
> On Wed, Feb 7, 2018 at 11:57 AM, Uvindra Dias Jayasinha
> wrote:
>
>> +1 Agreed with Nuwan about how subscriptions should be handled
>>
>>
>> Reg
February 2018 at 15:51, Harsha Kumara wrote:
> @Sanjeewa, Uvindra can we actually prevent it? Basically we can hide it
> from UI. But since he know the consumer key and secret, he can simply
> revoke and regenerate the token.
>
> On Thu, Feb 8, 2018 at 2:57 PM, Uvindra Dias Jay
prevent it? Basically we can hide it
>> from UI. But since he know the consumer key and secret, he can simply
>> revoke and regenerate the token.
>>
>> On Thu, Feb 8, 2018 at 2:57 PM, Uvindra Dias Jayasinha
>> wrote:
>>
>>> Yes we can safely prevent sha
Hi Youcef,
Thanks for you feedback about the product.
Regarding getting rid of relational databases, we really haven't explored
this possibility ourselves.
Technically APIM 3.0.0 uses a set of DAO interfaces to access its
persistent layer. These DAO interfaces such as ApiDAO.java,
ApplicationDAO
Can I suggest that we rename the label types we have come up with at the
moment?
We right now have *Gateway* and *Store* label types. These names are
tightly coupled to the high level product components that they are designed
to work with and do not communicate their proper intent and purpose. The
I'm in favour of having userinfo separate from the default oauth2 service
since its a different concern altogether. Im not sure the reason behind why
the IS team originally included userinfo as part of their oauth service.
So +1 for option 2
On 28 March 2018 at 12:46, Pubudu Gunatilaka wrote:
+Sagara, Johann
On 29 March 2018 at 10:57, Uvindra Dias Jayasinha wrote:
> I'm in favour of having userinfo separate from the default oauth2 service
> since its a different concern altogether. Im not sure the reason behind why
> the IS team originally included userinfo as part
browser?
>>>>>>>
>>>>>> * in signup case, if you take a token to talk to signup api, is it
>>>>>> also store in the browser?
>>>>>>
>>>>>
>>>>> In this case, Yes. Since there is no user involve
attack. Isn't it?
>> Of cause, if we can have captcha validation we can mitigate this.
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterpr
Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Aug 1, 2018 at 11:19 AM, Uvindra Dias Jayasinha
> wrote:
>
>> +1, we need to have default throttling policies for all our REST APIs
>>
>> On 1 August 2018 at 11:
+1 for the approach suggested by NuwanD, this gives us a best of both
worlds scenario separating user code from generated code.
I believe we can even handle Roshan's requirement for non technical users
in this way. Uploading Ballerina functions that will be associated with a
given resource can be
In the past the APIM product has relied on an external component such as a
migration client for upgrading from a given product version to a higher
version.The end user was required to configure the latest product that they
are upgrading to against their current data(databases, synapse files,
regist
ill be needed for 3.0.0 itself
On 20 August 2018 at 15:58, Uvindra Dias Jayasinha wrote:
> In the past the APIM product has relied on an external component such as a
> migration client for upgrading from a given product version to a higher
> version.The end user was required to configure the
Enterprise . Middleware
>
> On Mon, Aug 20, 2018 at 4:03 PM, Uvindra Dias Jayasinha
> wrote:
>
>> Small calcification regarding this statement,
>>
>> For the 3.0.0 release we just need to implement steps *1* and *2* above.
>>> Step *3* can be done for all
ludes all the migration logic for each
entity to make this more manageable.
Thanks,
NuwanD.
>
> On Mon, Aug 20, 2018 at 5:09 PM Uvindra Dias Jayasinha
> wrote:
>
>>
>>
>> On 20 August 2018 at 16:58, Ishara Cooray wrote:
>>
>>> For me, PRODUCT_VERSION c
nt as stated
earlier. If we can do this for APIM first we can propose that all other
components as well
> On Wed, Aug 22, 2018 at 1:17 PM Uvindra Dias Jayasinha
> wrote:
>
>> See my responses inline
>>
>> On 22 August 2018 at 11:54, Nuwan Dias wrote:
>>
>>>
I cant find any documentation for this feature, has this been documented?
Without documentation the visibility of this feature is lost
On 14 December 2017 at 13:49, Viduranga Gunarathne
wrote:
> Hi,
>
> As of now this feature is being improved to support custom authorization
> headers in a "pe
Correction, found the docs https://docs.wso2.com/display/AM250/Securing+APIs.
Thanks for pointing it out Viduranga
On 19 September 2018 at 11:36, Uvindra Dias Jayasinha
wrote:
> I cant find any documentation for this feature, has this been documented?
>
>
> Without documentation th
Tested below with secure vault with custom key store
1. API publication and invocation tenant and super tenant
2. Stats tenant and super tenant(Store and Publisher)
3. Log Analyzer tenant and super tenant
No issues found
[+] Stable - go ahead and release.
On 22 July 2016 at 12:20, Roshan Wijes
Tested below with secure vault with custom key store
1. API creation and publication with different user roles and invocation
tenant/super tenant
2. Stats tenant/super tenant(Store and Publisher)
3. Log Analyzer tenant/super tenant
4. API creation and publication with different user roles for tena
+1 to allowing subscriptions to API products only, I dont see an advantage
in supporting both subscriptions to APIs and API products(it only
complicates things). This will also eliminate confusion for subscribers.
Yes there will be a migration effort in doing this but its worth it IMO for
the clean
Hi Imesh,
Yes the term API Product has already been coined by the industry. It makes
sense to use this term because we allow different API products to have
different policies associated with them. So its not just a grouping of
APIs, you can have the same set of APIs grouped together with different
+1 to what Jo suggested, I have written some classes to already do this but
haven't committed the code. @Malintha and Praminda, you can reuse these if
you wish.
On 29 August 2016 at 12:00, Joseph Fonseka wrote:
> How about having the OAuth flow transparent to the test case developer ?
> which wi
ou
> have any other references?
> Still, I don't think the product term is well suited for grouping APIs.
>
> [1] http://docs.apigee.com/developer-services/content/what-api-product
>
>
> On Tue, Aug 30, 2016 at 11:52 AM, Uvindra Dias Jayasinha > wrote:
>
>> Hi Ime
In the Cloud it could be API Creators, Publisher or Subscribers, basically
anyone who can call the REST API
On 15 September 2016 at 12:21, Nuwan Dias wrote:
>
>
> On Thu, Sep 15, 2016 at 12:14 PM, Uvindra Dias Jayasinha > wrote:
>
>> While using APIM's REST API Dynam
t; On Thu, Sep 15, 2016 at 12:26 PM, Uvindra Dias Jayasinha > wrote:
>
>> In the Cloud it could be API Creators, Publisher or Subscribers,
>> basically anyone who can call the REST API
>>
>
> So its the Store/Publisher webapps right? In that case it just creates 1
>
*Brief*
The API Product feature being developed for API Manager allows AP
Publishers to bundle a set of APIs and expose them as a product which will
have its own set of policies that will apply all APIs that are bundled
within the product. API Consumers will have the option of subscribing to
the
NuwanD thought it was better to have a separate permission for the
product to give a more fine grained permission model to users.
On 5 October 2016 at 15:15, Uvindra Dias Jayasinha wrote:
> *Brief*
>
> The API Product feature being developed for API Manager allows AP
> Publishers to bun
*Context*
We have started to look into API Manager's DB design for C5 and want to
evaluate what was done in the past and see if there is room for improvement.
This is specifically to talk about the below audit columns,
CREATED_BY*VARCHAR*
CREATED_TIME*TIMESTAMP*
UPDATED_BY*VARCHAR*
UP
Thanks for the feedback, some interesting points were brought up
@Abimaran, the problem with maintaining a rigid structure like old/new
column is that if a user changes the value of 5 columns at a given time
that would mean 5 different inserts to the table, when in actual fact it
was a single tran
Thanks for the feedback
On 12 October 2016 at 09:33, Abimaran Kugathasan wrote:
>
>
> On Tue, Oct 11, 2016 at 10:34 PM, Lakmali Baminiwatta
> wrote:
>
>>
>>
>> On 11 October 2016 at 14:40, Uvindra Dias Jayasinha
>> wrote:
>>
>>> Thanks for
On 12 October 2016 at 10:54, Lahiru Cooray wrote:
>
>
> On Tue, Oct 11, 2016 at 1:44 PM, Sanjeewa Malalgoda
> wrote:
>
>> I think we can manage audit table while still having CREATED_BY,
>> CREATED_TIME,UPDATED_BY, UPDATED_TIME in same tables. So with that
>> approach we may never need to do ta
Was wondering about $subject
Traditionally we have stored our product configs, be it carbon.xml,
api-manager.xml, identity.xml, etc. at file level. Some configs, such as
"port offset" are inherently bound to the server startup so it makes sense
for them to be at file level, since they come into af
e, IMO a node restart for a config change is not relevant, also no
> need of a periodic config checks.
>
> Btw, can you give me some example configuration you were thinking of?
>
> Thanks,
> Sajith
>
> On Wed, Oct 12, 2016 at 11:53 AM, Uvindra Dias Jayasinha > wrote:
&g
nodes using some mechanism. And with no clustering on C5, this
>>>>>>> is a
>>>>>>> challenge.
>>>>>>>
>>>>>>> If the objective of this is to make the Cloud (tenant) experience
>>>>>>> bett
October 2016 at 10:55, Uvindra Dias Jayasinha
wrote:
> Let me summarize this thread so far.
>
> The functionality provided by a DB makes it easy to implement reading,
> updating and sharing configs, but there have been some legitimate concerns
> that have been raised in this thread
el as long as the UX does not suffer.
We should strive to improve usability more than ever before.
On 14 October 2016 at 12:34, Sagara Gunathunga wrote:
>
>
> On Fri, Oct 14, 2016 at 10:55 AM, Uvindra Dias Jayasinha > wrote:
>
>> Let me summarize this thread so far.
>>
I would like to know your thoughts on $subject.
Previously we have a single custom exception class in APIM called
'APIManagementException' and this was used when throwing exceptions
specific to the APIM product. Pros and Cons of doing it this way are,
*Pros* - Only one APIM specific exception nee
s!
>
> On Thu, Oct 20, 2016 at 2:27 PM, Uvindra Dias Jayasinha
> wrote:
>
>> I would like to know your thoughts on $subject.
>>
>> Previously we have a single custom exception class in APIM called
>> 'APIManagementException' and this was used when throwin
...@wso2.com
> Mob: +94715186770
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/ha
> rsha-thirimanna/10/ab8/122
> <http://wso2.com/signature>
>
> On Thu, Oct 20, 2016 at 2:51 PM, Uvindra Dias Jayasinha
xceptions have no meaning by themselves. So if you are
using the DAO component you have to handle the DAO exception, you cant opt
out of doing that(if you do the whole point is lost).
> Thanks,
> Malintha
>
> On Thu, Oct 20, 2016 at 2:51 PM, Uvindra Dias Jayasinha
> wrote:
>
>>
n and return responses
>> accordingly.
>>
>> [1] http://howtodoinjava.com/best-practices/java-exception-h
>> andling-best-practices/
>>
>> On Thu, Oct 20, 2016 at 2:27 PM, Uvindra Dias Jayasinha > > wrote:
>>
>>> I would like to know your though
On 21 October 2016 at 10:09, Chamila Adhikarinayake
wrote:
>
>
> On Thu, Oct 20, 2016 at 2:51 PM, Uvindra Dias Jayasinha
> wrote:
>
>> Hi Malintha,
>>
>> What do we gain by defining an exception hierarchy? As long as we can
>> differentiate between exc
gt;>>
>>>>
>>>>
>>>> On Thu, Oct 20, 2016 at 3:31 PM, Harsha Kumara
>>>> wrote:
>>>>
>>>>> Definitely we need to have well defined set of exceptions instead
>>>>> using APIManagementExce
o file-system errors won't matter.
>
> Thanks.
>
> On Sat, Oct 22, 2016 at 11:21 AM, Abimaran Kugathasan
> wrote:
>
>>
>>
>> On Fri, Oct 21, 2016 at 12:10 PM, Bhathiya Jayasekara
>> wrote:
>>
>>>
>>> On Wed, Oct 12, 2016 at 1
all products
can benefit.
Akila suggested using something like Google Juice[2] for this purpose. Im
+1 for using this. Would like to here your thoughts on this.
[1] https://www.youtube.com/watch?v=IKD2-MAkXyQ
[2] https://github.com/google/guice
On 31 October 2016 at 13:06, Uvindra Dias Jayasinha
t;> [1] https://www.youtube.com/watch?v=IKD2-MAkXyQ
>> [2] https://github.com/google/guice
>>
>>
>> On 31 October 2016 at 13:06, Uvindra Dias Jayasinha
>> wrote:
>>
>>>
>>>
>>>> *The solution*
>>>>> Pass
>
> Spring too supports dependency injection (since its first release in early
> 2000s), anyone knows the differences between Spring and Guice?
>
>
> I checked up on this, mainly Spring was the alternative to the bloated
JavaEE. So its a fully featured framework with lots of stuff including the
abi
wrote:
>
>> I like Guice as well, but since we already have OSGi, (if we do have
>> OSGi) shouldn't we leverage that ?
>>
>> On Tue, Nov 1, 2016 at 5:37 AM, Uvindra Dias Jayasinha
>> wrote:
>>
>>>
>>>
>>>> Spring too supp
recommend steer away from DI while building
> our platforms.
>
> [1] http://www.tonymarston.net/php-mysql/dependency-injection-is-evil.html
> [2] http://www.yegor256.com/2014/10/03/di-containers-are-evil.html
>
> Cheers,
> Ruwan
>
> On Thu, Nov 3, 2016 at 12:01 PM, Uvindra Dia
Hi All,
Currently APIs have a few resources such as Swagger File, Optional WSDL
file, Related Documents file and an Optional Thumbnail image that needs to
be stored as blobs in the DB.
Initially we thought of having separate tables to store these resources,
but what if we have a single generic re
the UI so we need to store those specifically
On 3 November 2016 at 16:01, Uvindra Dias Jayasinha
wrote:
> Hi All,
>
> Currently APIs have a few resources such as Swagger File, Optional WSDL
> file, Related Documents file and an Optional Thumbnail image that needs to
> be stored as
tead of varchar, an Int will be
>used for storing and comparisons.
>- We will have a defined location to store and retrieve available
>resource types.
>
> Thanks,
> Akalanka.
>
> Thanks,
> Akalanka.
>
> On Thu, Nov 3, 2016 at 4:01 PM, Uvindra Dias Jayasinha
&
r OOP principles correctly.
>
>
> Cheers,
> Ruwan
>
> On Thu, Nov 3, 2016 at 1:39 PM, Uvindra Dias Jayasinha
> wrote:
>
>> HI Ruwan,
>>
>> The source you mentioned above supports what I'm proposing, the main
>> reason to use DI is to make tes
On 8 November 2016 at 11:10, Lahiru Cooray wrote:
>
>
> On Thu, Nov 3, 2016 at 4:01 PM, Uvindra Dias Jayasinha
> wrote:
>
>> Hi All,
>>
>> Currently APIs have a few resources such as Swagger File, Optional WSDL
>> file, Related Documents file and an Optio
On 9 November 2016 at 12:36, Lahiru Cooray wrote:
>
>
> On Tue, Nov 8, 2016 at 1:23 PM, Uvindra Dias Jayasinha
> wrote:
>
>>
>>
>> On 8 November 2016 at 11:10, Lahiru Cooray wrote:
>>
>>>
>>>
>>> On Thu, Nov 3, 2
As part of the C5 effort we need to evaluate how we are to persist API
Endpoint and API Environment information. Here is a brief introduction of
what each of these are.
*API Endpoint*
The actual backend endpoint that a API created in APIM fronts. In C4 these
were defined as Production and Sandbox
ironments.
> On Tue, Nov 15, 2016 at 3:46 PM, Uvindra Dias Jayasinha
> wrote:
>
>> As part of the C5 effort we need to evaluate how we are to persist API
>> Endpoint and API Environment information. Here is a brief introduction of
>> what each of these are.
>>
&
The ENDPOINT_TYPE refers to things such as HTTP Endpoint or WSDL Endpoint,
etc. which we supported in C4. But I dont knowhow this applies to C5.
On 15 November 2016 at 16:37, Abimaran Kugathasan wrote:
> HI Uvindra
>
> On Tue, Nov 15, 2016 at 4:27 PM, Uvindra Dias Jayasinha
know how this will be
represented in the new Integration Server.
>
> On Tue, Nov 15, 2016 at 4:27 PM, Uvindra Dias Jayasinha
> wrote:
>
>>
>>
>> On 15 November 2016 at 16:20, Abimaran Kugathasan
>> wrote:
>>
>>> Hi Uvindra,
>>>
>>>
Pagination is required whenever we return a collection of items to the
requester and we use widely as part in the REST API.
Initially we thought of supporting pagination at DB level. This ensures
that only a limited dataset is read at a given time based on the offset and
limit values provided by t
> On Tue, Nov 15, 2016 at 1:10 PM, Uvindra Dias Jayasinha
> wrote:
>
>> Pagination is required whenever we return a collection of items to the
>> requester and we use widely as part in the REST API.
>>
>> Initially we thought of supporting pagination at DB level. T
points you have mention and still stick with a
> DBMS.
>
Searching and sorting will be done at DB level via SQL. It is only the
pagination of the returned result set that will be done at Java level.
>
> On Wed, Nov 16, 2016 at 10:34 AM, Uvindra Dias Jayasinha > wrote:
>
>>
>
Hi Jo,
On 16 November 2016 at 14:47, Joseph Fonseka wrote:
> Hi Uvindra
>
> On Wed, Nov 16, 2016 at 1:48 PM, Uvindra Dias Jayasinha
> wrote:
>>
>>
>> Searching and sorting will be done at DB level via SQL. It is only the
>> pagination of the returned result
+NuwanD, Sanjeewa
On 16 November 2016 at 15:23, Uvindra Dias Jayasinha
wrote:
> Hi Jo,
>
> On 16 November 2016 at 14:47, Joseph Fonseka wrote:
>
>> Hi Uvindra
>>
>> On Wed, Nov 16, 2016 at 1:48 PM, Uvindra Dias Jayasinha > > wrote:
>>>
>>>
ving the flexibility to plug a new vendor easily when needed.
>
> On Wed, Nov 16, 2016 at 3:23 PM, Uvindra Dias Jayasinha
> wrote:
>
>> Hi Jo,
>>
>> On 16 November 2016 at 14:47, Joseph Fonseka wrote:
>>
>>> Hi Uvindra
>>>
>>> On W
specific implementation. We can decide once we integrate with the user core.
Thanks all for the feedback
On 17 November 2016 at 10:05, Uvindra Dias Jayasinha
wrote:
> We are not doing this to avoid vendor specific queries.
>
> The real reason why we want to go down this path, we have no
Are we actually going to be supporting multiple minor version
implementations?
Seems like the rationale for doing this was so that we dont need to have
multiple implementations to support minor versions. Since a minor version
change is totally backward compatible with the major version it seems th
I think there is agreement that we can go with just the major version as
part of the URI, but I'm still wondering if we need to ask users to send
the minor version in a header.
Users can mistakenly send a wrong minor version and if we blindly take
decisions based on that header it could lead to er
er if required, we could maintain a extension field in AM_API_RESOURCES
> table.
>
> I'm not telling that the proposed structure is wrong. This is just a
> suggestion to further normalize and minimize data repetition and to make
> the structure more clearer.
>
> On Wed, N
, We need to give the attachment name for
> download.
>
> On Fri, Nov 18, 2016 at 12:22 PM, Uvindra Dias Jayasinha > wrote:
>
>> Hi Lahiru,
>>
>> Yes what you have suggested is a lot more normalised, but I still prefer
>> to refer to it as a DATA_TYPE as oppo
We already have a UUID column for few tables such as AM_API and
AM_APPLICATION which is used to uniquely identify a record. The reason why
we have a UUID column is because it is the unique identifier that we expose
to the end user. Having a UUID for this purpose means that end users cannot
guess th
o save the mime type sent when uploading the resource or are
> we going to use a predefined set based on data type ?
>
> Thanks
> Jo
>
>
> [1] https://www.sitepoint.com/web-foundations/mime-types-complete-list/
>
> On Fri, Nov 18, 2016 at 3:52 PM, Uvindra Dias Jayasinha
see a real use case of
> going for a hybrid approach. Either we could use UUID as a PK or an auto
> increment ID.
>
> In this case +1 for an auto increment ID as the PK.
> Reasons: easy to debug manually/ easy to sort by id/ save space
>
> On Fri, Nov 18, 2016 at 9:34 PM, Uvi
;> an integer based identifier."
>>>>>
>>>>> What is the purpose of having a non guessable Id here? Anywhere the
>>>>> user who has permissions to invoke api's can get the uuid list or simply
>>>>> can view in the Store/Publisher
s well.
>
> Thanks,
> Akalanaka.
>
> On Sun, Nov 20, 2016 at 6:20 PM, Uvindra Dias Jayasinha
> wrote:
>
>> Just thought of pointing out that there is an option of optimizing UUIDs
>> stored in the DB to make them easier to sequence and reduce storage
>> size[1].
Hi Rukshan,
There have been requests in the past to include all available CGI
variables[1] to give more flexibility when it comes to stats. We are
already capturing some of these above. I dont know for sure how useful or
relevant it might be to capture them all though.
[1] http://www.cgi101.com/b
Hi Ishara,
Another possibility for supporting multiple auth types with what you have
proposed is to have a collection Authenticator interfaces(using a Map
possibly) at the RestAPISecurityInterceptor level. Depending on some
condition you could selectively choose what implementation to use at
runti
I think there might be a valid case for allowing a provider to
export/import all the APIs that belong to that provider only in bulk. Its
much more user friendly as Rushmin has mentioned
On 17 January 2017 at 17:15, Rushmin Fernando wrote:
> Hi Isuru,
>
> Please see my comments inline.
>
>
>
> On
criteria, provider, api name, wildcards, etc. WDYT?
>
> On Tue, Jan 17, 2017 at 6:12 PM, Uvindra Dias Jayasinha
> wrote:
>
>> I think there might be a valid case for allowing a provider to
>> export/import all the APIs that belong to that provider only in bulk. Its
>> m
+1, permission check for searches is a must
On 26 January 2017 at 13:50, Roshan Wijesena wrote:
> Hi,
>
> We may need to add permission check query also into this search, which
> means In C5 we have a permission model for APIs,Applications,Docs, etc..
> IMO, when someone is doing a query that qu
ad a very specific set of APIs. That requirement was
>>> considered when writing the CLI based import export tool.
>>>
>>> Thanks!
>>>
>>> On Wed, Jan 18, 2017 at 1:09 PM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
&
+1 to Option 1, an APIs ratings are not something that everyone will be
interested in. Those who want that data can make the additional API call to
retrieve it.
On 6 March 2017 at 13:40, Chamalee De Silva wrote:
> Hi Dilan,
>
> I agree with your point in terms of performance point of view.
> But
Hi All,
Currently APIM only publishes stats in its publisher view. We are looking
into $subject. This will be primarily targeted at developers who subscribe
to API's so that they can get insight into API usage from the store. An API
subscription is associated with a given application that is using
inghe
>
> Vice President Developer Evangelism
>
> WSO2 Inc.
> http://wso2.com
>
>
>
> On Fri, Mar 7, 2014 at 3:18 PM, Uvindra Dias Jayasinha
> wrote:
>
>> Hi All,
>>
>> Currently APIM only publishes stats in its publisher view. We are looking
>>
Is it worth doing this at the moment since APIM will be moving to ES? Might
be better to take this into consideration when implementing stats after the
migration
On Thu, Apr 10, 2014 at 9:50 AM, Chanaka Jayasena wrote:
> I have seen this UI when talking with Asiri f2f. This change take away the
This is just a suggestion,
currently we are directly writing raw SQL SELECT statements to query the AM
Stats DB to retrieve stats. Since SQL syntax varies from DB to DB we run
into SQL syntax errors depending on the DB that is deployed with APIM. We
recently had such an issue with MSSQL Server sin
+1
Makes sense to reuse existing APIM functionality to deploy the API archive.
On 19 November 2014 15:59, Nuwan Dias wrote:
>
>
> On Wed, Nov 19, 2014 at 2:38 PM, Ajith Vitharana wrote:
>
>>
>>
>> On Wed, Nov 19, 2014 at 2:29 PM, Lakshman Udayakantha > > wrote:
>>
>>> Hi all,
>>>
>>> We are d
Hi Youcef,
We dont provide custom development solutions of our code through this
channel. This is a significant customization of our code. If you are a
paying customer who has subscribed for support I suggest that you log a
support ticket and have a discussion with the support team in order to
cla
e time when
we actually do a document upload. So that way the fingerprint will always
be the latest. No need to add another column since the meta and content
data are actually related.
Appreciate your response.
Thank you
*Dushani Wellappili*
Software Engineer - WSO2
Email : dusha...@wso2.com
Mobi
Tested Workflows for,
- API State change
- User Signup
- Application Creation
- Application Registration
- API Subscription
- API Product Subscription
No blockers found. +1
On Thu, 24 Oct 2019 at 17:35, Ishara Cooray wrote:
> Hi All,
>
> Tested the following.
> - API Creation, Publishing, Sub
Tested Workflows for,
- API State change
- User Signup
- Application Creation
- Application Registration
- API Subscription
- API Product Subscription
No blockers found. +1 for release
On Fri, 25 Oct 2019 at 17:42, Dushani Wellappili wrote:
> Tested the following,
>
> - Basic flow in API Crea
@Ashera Silva
, noticed that this thread is private. We need to discuss this on @Architecture
List so that we can get wider feedback from the
community.
Might be a good idea to link to this[1] as well. There was a lot of
interest shown by the community regarding this so we can get feedback from
1 - 100 of 119 matches
Mail list logo
