Мы создали два однотенантных приложения Azure с одинаковым набором разрешений (Mail.Send и Mail.ReadWrite) в одном клиенте. Согласно документации Graph API, мы должны иметь возможность отправлять электронные письма размером до 150 МБ на каждое письмо через комбинацию 1 приложения и 1 почтового ящика.
Ссылка — https://learn.microsoft.com/en-us/graph/throttling-limits#outlook-service-limits
Поскольку в документации упоминается эта комбинация, в идеале, если у нас есть два разных приложения Azure, мы сможем отправить два отдельных электронных письма размером 150 МБ каждое (всего 300 МБ) в течение 5 минут из одного и того же почтового ящика.
Но, к сожалению, это не работает. Мы получаем ошибку регулирования от Graph API при попытке составить второе электронное письмо.
{
"error": {
"code": "ApplicationThrottled",
"message": "Application is over its IncomingBytes limit."
}
}
Если в документации упоминается такая комбинация, то почему API не позволяет загружать более 150 МБ (2 отдельных электронных письма) в один и тот же почтовый ящик в течение 5 минут с использованием двух разных приложений Azure?
token1
из App1
.mailbox1
и загрузите файл размером 140 МБ, используя сеанс загрузки.token2
из App2
.mailbox1
и загрузите файл размером 140 МБ, используя сеанс загрузки. На этом этапе происходит сбой с вышеуказанной ошибкой.Я уже создал одну заявку, этот вопрос позволит мне узнать, сталкивался ли кто-нибудь еще с такой же проблемой, и я смогу публиковать здесь обновления о моей заявке MS.
Вам также необходимо учитывать раздувание MIME, хотя размер вложения может быть меньше 150, когда вы попытаетесь отправить его, оно раздуется на 137% en.wikipedia.org/wiki/Base64#MIME поэтому 140 МБ, как правило, все равно будет слишком большим .
@GlenScales Я воспроизвел проблему через Postman, загрузив PDF-файл размером 120 МБ в 2 отдельных письма в один и тот же почтовый ящик через 2 разных приложения. Это успешно в приложении1, но терпит неудачу в приложении2.
В документации это неясно (она неоднозначна), но я понимаю, что когда вы используете субъекты службы (например, поток учетных данных клиента), это использует олицетворение. Таким образом, хотя вы используете разные принципы приложения/службы, бюджет регулирования по-прежнему взимается с олицетворенного пользователя. Вы, вероятно, обнаружите, что использование токена делегата и токена приложения для почтового ящика будет работать (в пределах 5-минутного окна), поскольку они, как правило, представляют собой отдельные бюджеты регулирования. Я считаю, что это сделано таким образом, чтобы ограничить влияние службы на каждый почтовый ящик.
@GlenScales То, что вы говорите, имеет смысл, однако в моем случае мне приходится придерживаться разрешений приложений. Я все еще ожидал, что смогу добиться этого с помощью двух разных приложений Azure.
После создания заявки в службу поддержки Microsoft и последующего общения с ними в течение последнего 1 месяца пришел к выводу, что это запрещено по замыслу.
Вот обновленная документация, чтобы избежать дальнейшей путаницы. Теперь поведение API и документация совпадают друг с другом:
Подайте заявку в службу поддержки MicroSoft. Возможно, связанные детали не совсем точны, только MS может знать наверняка.