We need a way to get users based on page index and page size so that we will not load all the users every time.
I have gone through with the Azure Graph Client documentation here http://blogs.msdn.com/b/aadgraphteam/archive/2014/12/12/announcing-azure-ad-graph-api-client-library-2-0.aspx
There is a way to iterate forward/backward but, i didn't found a way to get the users based on page index(i.e: i want to get users from 10-20 in the list if i pass parameters page index=2 and page size=10).
If we go with forward/backward paging, then i have to iterate through each page to find the next set of records, which I don’t want to do that.
Any help would be appreciated.
In order to accomplish the kind of pagination you're looking for, Azure AD Graph API need to support both $top and $skip OData operators. However kooking at Supported Queries, Filters, and Paging Options in Azure AD Graph API, while $top is supported but $skip isn't thus I don't believe it is possible to accomplish pagination they way you want to.
It does support $top and $skiptoken which can be used for navigating back & forth but will not serve the scenario you're looking to implement.
Sorry, currently this is not possible via the Graph Client. What you are looking for is similar to a query of a database, where you can selectively control the return set. Azure Graph does not have this capability. When you make a query, the result is returned one page at a time. You pass your token each time you are requesting the next page in the return set. There exist no way that actually tracks page 1, 2, 3... and so forth of the return set, thus, no way to say bypass pages 1 and 2 to go directly to page 3. The only capability available is next page and previous page. There is no page index maintained that can be queried. You get the your results one page at a time.
As said by MMTT here: https://social.msdn.microsoft.com/Forums/en-US/199bbf92-642a-4bcc-add4-f8023a7684e2/paging-in-azure-ad-graph-client?forum=WindowsAzureAD
Related
I would like understand the difference between odata and fetchxml, this has to do with pagination in MS Dynamics, I am very new to the stack and would like to understand why there are two object models that essentially perform the same tasks?
the problem statement is as follows, we want our product to properly page answers it gets from Dynamics, currently we can only get 5000 answers per page, so if we are supposed to get say 6000 answers per page, how would we go about it:
I understand the limitations of odata, it can only retrieve record size = 5000. To overcome this or see the next set of results, I would have to use the value of the #odata.nextLink property with a new GET request to return the next page of data.
Similarly for fetchxml, there is the option to use paging cookie. Is my initial analysis correct?
But I still do not understand why there are 2 object models?
fetchxml is native Dynamics CRM querying language available from oldest versions.
Odata REST based web api was introduced in CRM 2016 update 1 onwards (v8.0).
There was a SOAP based 2011 endpoint before, its deprecated now.
You will find blogs/documentation over the internet based on different versions in different point of time. Read more
I'm trying to find a possibility to skip X first elements returned by query.
Link to API: https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/wiql/query%20by%20id?view=azure-devops-rest-6.0.
Just as with Jira you use maxResults with startAt to create paging.
In AzureDevops Services I see option $top but I do not see option $skip (nor it works).
I can limit my result, but can't page through it.
Is there a way to do it?
As of this time, however, the REST API you are using doesn't supported paging.
If a REST API supports paging, there will be skip or continuationtoken parameters in the optional parameters of the document. As shown below:
Generally, Paging is supported only by the REST API that gets the lists.
While the endpoint does not provide paging itself, I believe you can use WIQL for paging.
Sort by ID
Add a constant $top
if page > 1, add a where ID < last processed ID
Currently in Performance tile in Insight we have performance detail for the application request.
If we have an API like:
GET /order/{orderId}
so, for this kind of request, it showing as different request and matrix is also different for different orderId.
But for the owner point of view, this is a same request and needs to have shown under one request for all call for this method.
For the above mentioned API, if we have the request coming as:-
/order/1
/order/2
/order/3
Then in Azure portal, under performance tile for Application insight, it consider this as different operations and hence show stats individually for each unique request.
But as per the developer, this is a single API and needs to monitor as single operation.
How to achieve this in Azure portal?
In the Performance tab, you have the ability to add filters for your results but in your scenario I would:
Click on View in Logs (Analytics)
Select Requests
Add an appropriate contains statement: | where operation_Name contains "GET /order"
At this point the Overall line contains the total Duration Average and Count shown in the Performance tab, as well as percentile information for all orders.
Does anybody knows, what metric is shown in Azure Maps usage diagrams?
This is what diagram looks like, and number of request in the charts significantly differs from my traffic amounts. It seems like 10-15 requests in the graph per each visitor on the site.
I suppose that charts showing amount of map-tiles loaded, where each tile load is considered as a request.
Update
The question is about using JavaScript maps control
Map loads in map control is tracked as Map tile API requests where each API request renders one tile. On Azure portal on the Azure maps usage page you can click on "Apply splitting" button and group the usage by "API name" to confirm your assumption.
It's hard to give an accurate answer without more context but usage (along with availability) itself is the metric in the graph. You can also apply filters on the graph based on API Names, API categories, Response codes etc. and it'll show you the count of requests for that specific api(s). I'm guessing you might be using the Get Map Tile API in which case each tile load is a separate request and will be counted as such on the dashboard.
If that doesn't answer you question please add more context as to what api(s) are you using and i can try and answer more accurately.
is there a way to grab instagram users based on a specific hashtag ?
I run contests based on re posting photos with specified hashtag then randomly pick a winner, i need a tool that can grab the usernames of those who reposted that photo and used that hashtag.
You can query instagram using the API. There are official clients for both python and ruby.
You didn't specify what language/platform you are using, so I'll give you the generic approach.
Query instagram using the Tag Recent Media endpoint.
In the response, you will receive a user object that has the user's username, id, profile url, and so on. This should be enough to do what you are describing.
As far as tools, there aren't great options to probably do things exactly how you want. If you just want a simple contest, you could use statigram, but it's not free.
If you roll your own solution, I highly recommend you also do the following:
Implement a rate limiting mechanism such as a task queue so you don't exceed your API calls (5000 per hour for most calls). Also useful for failures/network hicups, etc.
Have users authenticate so you can use OAuth to extend your API calls to 5000/per user/hour to get around #1.
Try the subscribe API if there won't be many items. You can subscribe to a specific tag as well, and you will get a change notification. At that point though you need to retrieve the actual media item(s), and this can cost a lot of API calls depending on how frequent and what volume these changes occur.
If your users don't have much photos/relatively small/known in advance, you can actually query the user's recent media instead and filter in your own code by hash tag.