I need to use microsoft graph api, more in detail the calendar one, to retrieve some events of the users (up to 1000 entries).
I need to filter out the events that the user have declined.
That information is stored in the assignee resource, or conveniently in the 'responseStatus' property.
The issue that I'm having is that anytime I try to retrieve the assignee resource, the query takes 10x time to perform (from 1.2s without the assignees to 12-14s with).
(https://graph.microsoft.com/v1.0/me/events?select=id,subject,start,end,sensitivity,assignee&top=1000)
So i've tried to get the responseStatus instead and...guess what, the performance are always 10x worst (https://graph.microsoft.com/v1.0/me/events?select=id,subject,start,end,sensitivity,responseStatus&top=1000)
I've then decided to try to filter them directly (https://graph.microsoft.com/v1.0/me/events?select=id,subject,start,end,sensitivity,responseStatus&top=1000&filter=responseStatus/response ne 'declined') but I receive an error message stating that "The property 'responseStatus' does not support filtering."
And I'm having an hard time filtering the assignee resource.
So...is there a simple way to filter declined events without having such performance issues?
You can use the extended property pidlidresponsestatus https://learn.microsoft.com/en-us/office/client-developer/outlook/mapi/pidlidresponsestatus-canonical-property to filter those out eg
https://graph.microsoft.com/v1.0/me/events?$select=subject,body,bodyPreview,organizer,attendees,start,end,location,responsestatus&$filter=singleValueExtendedProperties/any(ep:ep/id eq 'Integer {00062002-0000-0000-C000-000000000046} Id 0x8218' and cast(ep/value, Edm.Int32) ne 4)
Related
I user delta query to get changes to users for a particular tenant. The algorithm looks like:
Fetch all users and save delta
Use delta to get only changes
Everything works fine however the initial call to fetch all users is very slow, as I need to follow nextLink and basically if a tenant has hugh number of users ( > 1 000 000) and max number of items per page is 999 it takes a lof of the for that synchronization.
I thought, I could parallelize it - use startswith(mail,'{a}') filter and call the api for every letter in the alphabet. The problem is that with this approach I cannot fet delta link (or I would get a delta for every call).
Is there maybe a better way to speed up user fetching ?
Delta on users does not support filtering objects today on any other property than the Id. You could request support for filtering by adding an idea in UserVoice.
As a workaround you could sync the users in parallels with a filter using the GET API (/users) and then issue a delta query with $deltatoken=latest to get a token from that point and not have to sync all the changes sequentially. This doesn't guarantee consistency though.
Lastly, sync can be made faster (using delta, without parallelization) by selecting only the properties you need.
I am using total count of devices as the "server attributes" at customer entity level that is in turn being used for Dashboard widgets like in "Doughnut charts". Hence to get the total count information, I have put a rule chain in place that handles "Device" Addition / Assignment event to increment the "totalDeviceCount" attribute at customer level. But when the device is getting deleted / UnAssigned , I am unable to get access to the Customer entity using "Enrichment" node as the relation is already removed at the trigger of this event. With this I have the challenge of maintaining the right count information for the widgets.
Has anyone come across similar requirement? How to handle this scenario?
Has anyone come across similar requirement? How to handle this scenario?
What you could do is to count your devices periodically, instead of tracking each individual addition/removal.
This you can achieve using the Aggregate Latest Node, where you can indicate a period (say, each minute), the entity or devices you want to count, and to which variable name you want to save it.
This node outputs a POST_TELEMETRY_REQUEST. If you are ok with that then just route that node to Save Timeseries. If you want an attribute, route that node to a Script Transformation Node and change the msgType to POST_ATTRIBUTE_REQUEST.
I need to find detail of more than 20 users in one query, so I am trying to use below query, But maximum 15 "or" is allowed in one query. So please let me know operator which I can use instead od using "multiple OR statement"
https://graph.microsoft.com/v1.0/users?$filter=startsWith(userPrincipalName, 'user1') or startsWith(userPrincipalName, 'user2').......
That's a per request threshold and I don't think it can be directly tackled with a drop-in replacement but here's some other ideas for you to consider:
1) If your application stores the user ids you can use the get directory objects by id endpoint which gets up to 1000 users back in one request https://learn.microsoft.com/en-us/graph/api/directoryobject-getbyids?view=graph-rest-1.0&tabs=http
2) Keep your current query but use MS Graph $batch requests to send multiple of these queries in one call to MS Graph. This will require you to construct the JSON batch payload and parse the response. https://learn.microsoft.com/en-us/graph/json-batching
Suppose I have the following JIRA filter.
project = XXX AND resolution = Unresolved AND assignee in (EMPTY) ORDER BY Type asc, priority desc
I use it to see all unassigned issues in a certain project and pull from for triage.
Every now-and-then, I need to know how many are in each Type, i.e., I actually want a count for each.
How could I modify this query to do that or write a new one that accomplishes the same thing?
Remember that JQL isn't SQL - it just operates on tickets and returns lists of them for other parts of JIRA to consume, and doesn't really have a mechanism for counting results.
That said, you can use the JIRA REST API's /search endpoint along with maxResults=0 to construct JQL queries for each Type you care about, and the endpoint will give you a total value for that ticket Type:
https://jira.url/rest/api/latest/search?jql=project%20=%20XXX%20AND%20resolution%20=%20Unresolved%20AND%20assignee%20in%20%28EMPTY%29%20AND%20Type%20=%20Task&maxResults=0
Results in this output for Type=Task:
{
"startAt":0,
"maxResults":0,
"total":123,
"issues":[]
}
We need to find all the courses for a user whose startDate is less than today's date and endDate is greater than today's date. We are using API
/d2l/api/lp/{ver}/enrollments/myenrollments/?orgUnitTypeId=3
In one particular case I have more than 18 thousand courses against one user. The service can not return 18 thousand records at one go, I can only get 100 records at a time, so I need to use bookmark fields to fetch data in set of 100 records. Bookmark is the courseId of the last 100th record that we fetched, to get next set of 100 records.
/d2l/api/lp/{ver}/enrollments/myenrollments/?orgUnitTypeId=3&bookmark=12528
I need to repeat the loop 180 times, which results in "Request time out" error.
I need to filter the record on the basis of startDate and endDate, no sorting criteria is mentioned which can sort the data on the basis of startDate or endDate. Can anyone help me to find out the way to sort these data, or tell any other API which can do such type of sorting?
Note: All the 18 thousand records has property "IsActive":true
Rather than getting to the list of org units by user, you can try getting to the user by the list of org units. You could try using /d2l/api/lp/{ver}/orgstructure/{orgUnitId}/descendants/?ouTypeId={courseOfferingType} to retrieve the entire list of course offering IDs descended from the highest common ancestor known for the user's enrollments. You can then loop through /d2l/api/lp/{ver}/courses/{orgUnitId} to fetch back the course offering info for each one of those org units to pre-filter and cut out all the course offerings you don't care about based on dates. Then, for the ones left, you can check for the user's enrollment in each one of those to figure out which of your smaller set the user matches with.
This will certainly result in more calls to the service, not less, so it only has two advantages I can see:
You should be able to get the entire starting set of course offerings you need off the hop rather than getting it back in pages (although it's entirely possible that this call will get turned into a paging call in the future and the "fetch all the org units at once" nature it currently has deprecated).
If you need to do this entire use-case for more than one user, you can fetch the org structure data once, cache it, and then only do queries for users on the subset of the data.
In the mean time, I think it's totally reasonable to request an enhancement on the enrollments calls to provide better filtering (active/nonactive, start-dates, end-dates, and etc): I suspect that such a request might see more traction than a request to give control to clients over paging (i.e. number of responses in each page frame).