We are using microsoft graph api v1.0 in our .Net core application from planner tasks crud operations.
Steps we are performing are:
Create group
Create planner plan
Create multiple tasks under above group and plan.
Sometimes everything works fine but some times some task fails.
We loop our tasks list and do post call through graph api sdk for c#.
We get 400 or 500 randomly while creating plan under group on multiple retries, it creates sucessfully.
Some times on planner task post call we get 400 or 500 response.
Any idea how we can do these batch calls without missing tasks
These might be the reasons why 400 errors might be happening as mentioned in the docs
For more information:https://learn.microsoft.com/en-us/graph/api/resources/planner-overview?view=graph-rest-1.0#common-planner-error-conditions
These are the ways to create a planner and to avoid the 400 errors: https://learn.microsoft.com/en-us/graph/api/planner-post-plans?view=graph-rest-1.0&tabs=csharp#response
Hope this helps.
Related
I am testing with the To-Do task API (Create todoTask - Microsoft Graph v1.0 | Microsoft Docs) in Microsoft Graph Explorer.
I am able to create and see the list and task in MS Teams Planner using below requests for my own:
POST /me/todo/lists
POST /me/todo/lists/{todoTaskListId}/tasks
If I am trying to create list or task for someone else using below, I am getting response as created - 201 that is all good till now.
But if look into that MS Teams account into which I created list/task, no list or task is present in the planner. What is the issue behind this?
NOTE: I am passing id down not userPrincipalName.
POST /users/{id|userPrincipalName}/todo/lists
POST /users/{id|userPrincipalName}/todo/lists/{todoTaskListId}/tasks
Point 1:
The todo API is a api to access the office 365 todo list, it has nothing to do with the MS Planner tasks. The MS Planner user tasks can be found /me/planner/tasks and /user/{id}/planner/tasks. The two are not related any way (other than being a "task" in nature). i.e. a ToDo task is not any planner plan and a planner task can't be a ToDo task.
Point 2:
Like the planner API, the ToDo tasks API only supports the delgated permision and only for the "current" user. So only /users/{your userid}/todo/lists works...
Until MS add application permission support for the ToDo API will you be able to access another users ToDo list API. The same is true for the Planner API.
If you need such feature you may like to add a request over at the MS todo user voice page.
I'm implementing an API to create custom AzDo projects (my API calls the AzDo API).
About the creation:
Create project
Create two custom groups
Setup the permissions for the custom groups (area, iteration, build, ...)
Now my problem is that everything is working fine for one project. When creating more then one project I'm getting timeouts from AzDo, the strange thing is that I do not create all projects in the same time. I have a queue => My service always grabs one item from the queue => Means the service is creating the projects in row, not all at the same time. But it seems like that I´m getting the timeouts after I created 4 or 5 projects in a row.
If I´m waiting for some minutes between the creation, there seems to be no problems.
Note: I´m really getting the timeouts randomly, sometimes it could be a POST, another time it could be a PUT.
Does anybody have the same problem - or better, does anyone know to solve that issue?
Getting random timeouts when creating Azure DevOps project with API
Sorry for any inconvenience.
This behavior is by designed and is not a issue. There is no way to fix it at present.
In order to improve the response of Azure devops service and reduce the occupation of server by invalid requests, MS gives restrictions on REST API requests:
Only have one REST API task active at a given point in an account.
Set Api Response had a 20 second timeout.
You could check this thread and similar document for some more details.
Currently, there is no better way to modify the default timeout period, you could try to reduce the number of projects you create at once.
I am trying to pull Azure-Devops entities data (teams, projects, repositories, members etc...) and process that data locally,
I cannot find any documentation regarding rate-limiting and pagination,
does anyone has any experience with that?
There is some documentation for pagination on the members api:
https://learn.microsoft.com/en-us/rest/api/azure/devops/memberentitlementmanagement/members/get?view=azure-devops-rest-6.0
But that is the only one, i couldn't find any documentation for any of the git entities,
e.g: repositories.
https://learn.microsoft.com/en-us/rest/api/azure/devops/git/repositories/list?view=azure-devops-rest-6.0
If someone could point me to the right documentation,
Or shed some light on these subjects it would be great.
Thanks.
I cannot find any documentation regarding rate-limiting and pagination, does anyone has any experience with that?
There is a document about Service limits and rate limits, which introduced service limits and rate limits that all projects and organizations are subject to.
For the Rate limiting:
Azure DevOps Services, like many Software-as-a-Service solutions, uses
multi-tenancy to reduce costs and to enhance scalability and
performance. This leaves users vulnerable to performance issues and
even outages when other users of their shared resources have spikes in
their consumption. To combat these problems, Azure DevOps Services
limits the resources individuals can consume and the number of
requests they can make to certain commands. When these limits are
exceeded, subsequent requests may be either delayed or blocked.
You could refer Rate limits documentation for details
For the pagination, generally, REST API will have paginated response and ADO REST API normally have limits of 100 / 200 (depending which API) per page in each response. The way to retrieve next page information is to refer the response header x-ms-continuationtoken and use this for next request parameter as continuationToken.
But Microsoft does not document this very well - this should have been mentioned in every API call that supports continuation tokens:
Builds - List：
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds?definitions={definitions}&continuationToken={continuationToken}&maxBuildsPerDefinition={maxBuildsPerDefinition}&deletedFilter={deletedFilter}&queryOrder={queryOrder}&branchName={branchName}&buildIds={buildIds}&repositoryId={repositoryId}&repositoryType={repositoryType}&api-version=5.1
If I use above REST API with $top=50, as expected I get 50 back and a header called "x-ms-continuationtoken", then we could loop output the result with continuationtoken:
You could check this similar thread for some more details.
I think for most of the apis you have query parameter as $top/$skip.You can use these parameter to do pagination. Lets say the default run gives 200 documents in the response. For the next run skip those 200 by providing $skip=200 in the query parameter of the request to get the next 200 items. You can keep on iterating until count attribute of the response becomes 0.
For those apis were you don't have these parameter you can use continuation-token as mentioned by Leo Liu-MSFT.
It looks like you can pass $top and continuationToken to list Azure Git Refs.
The documentation is here:
https://learn.microsoft.com/en-us/rest/api/azure/devops/git/refs/list?view=azure-devops-rest-6.0
I'm currently running a web application that uses Microsoft Graph's API and we encountered the following message today which severely impacted our application, for a whole day:
"error": {
"code": "ErrorTooManyObjectsOpened",
"message": "Too many concurrent connections opened., The process failed to get the correct properties.",
"innerError": {
"request-id": "removed",
"date": "2017-12-13T17:01:14"
}
}
please note that the request-id was removed
Let me summarize what our web application does.
Basically, we have 2 email folders that we are actively subscribed to, Junk and Folder A.
If anything hits Folder A, we strip the body of the email message and then move the message to Folder B. The subscription on our Junk folder also strips the body and sends them over to Folder B.
Sometimes the webhook subscription service skips messages that may come at the same time, therefore we have 2 cron jobs in our server that run a script and check Junk/Folder A for any messages every 5 minutes, therefore my assumption is that the cron job runs about 288*2 times per day. Not counting our subscription to the folders, we usually get around 200-300 email messages per day.
Unfortunately Microsoft's Graph error codes page does not provide us with any explanation about this code. I would really appreciate if anyone can explain what this means and how to avoid it from happening.
This is occurring because your application is exceeding the throttling thresholds.
There are several different throttling metrics that can affect Microsoft Graph requests. For a high-level overview, see the Microsoft Graph throttling guidance. Since in this case you're hitting Exchange Online via Graph, you can find more specific information from What throttling values do I need to take into consideration? in the Exchange documentation.
Architecturally, you are making a lot of unnecessary calls into the API. Rather than having both a subscription and a scheduled job, you should use just the webhook subscription and the /delta endpoint.
Each call to the /delta endpoint gives you a token that can be used to fetch any changes to a given resource since the token was originally issued. So regardless of if 1 email came in or 1,000, you only get the new emails.
Once you're using the /delta to find your changes, you then use a webhook only as a "trigger". When you receive the webhook, you can ignore the contents and instead issue a request to /delta. This ensures that you capture every incoming email even if you didn't necessarily receive separate webhook notifications.
There is a bug. After making 500 message move requests, a "cannot copy/move error" occurs. Subsequently, a "429: Too many concurrent connections opened" error occurs. Most applications miss the first error because you continually get the 429 error afterwards.
If you let the application "rest" for 30 minutes, the throttle resets itself and you can continue on. I do not think there is a time limit for hitting the 500 moves. My application did 500 moves after 6.5 hours and then we started getting the error.
And, if you keep trying your move call before the 30 min rest period, it never resets. Also, in the response, the retry-after is null... so, that doesn't help you.
If you find a work around, please let me know. We are trying a few things like setting the category, then manually moving the messages. I am also investigating making a rule the moves them for us or some other job. I cannot find a way to execute a rule from the Graph API.
See this link for more information. Also, the more people who report having this issue, hopefully the sooner it can be resolved. Outlook API Throttling documentation #144
GET-request to "https://graph.microsoft.com/beta/tasks" return this json-string:
{"#odata.context":"https://graph.microsoft.com/beta/$metadata#tasks","value":[]}
But I have some tasks in my MS-account.
And GET-request to "/beta/ME/tasks" don't worked and return StatusCode - Not Found.
Why? How send the right request and get my tasks in json-string?
Updated:
At first I did not apply the scope Tasks.ReadWrite, but after that everything remains the same as it was.
Do I understand correctly: Microsoft Graph tasks is not Outlook Tasks, Microsoft Graph tasks is Planner's tasks?
Yes, Microsoft Graph tasks are Planner tasks. Outlook tasks are currently not accessible via Microsoft Graph, though we're considering adding them as well.