Решавање проблема када Мјуле АПИ ОАутх аутентикација приступа МС Грапх-у АПИ-ју
Овај чланак би требало да помогне МулеСофт програмерима да реше један од најчешћих проблема током прављења Муле АПИ-ја са ОАутх везом за слање е-порука. Погодили сте, тачно! - ово су проблеми са ограничењима регулације специфичних за МС Грапх сервис са порукама о грешци које се враћају Мјулеу као што су „превише захтева“ и „максимално ограничење истовремених захтева“.
Connecting MuleSoft API with O365 requires using MS Graph API. Graph is a RESTful web API that enables MuleSoft to access Microsoft Cloud service resources. After registration of Mule App and getting authentication tokens for a user or service, requests to the Microsoft Graph API are made.
This is a nut-shell explanation of this type of the Integration. However, with every solution comes the problem, and this article will give you some excellent ideas how to overcome issues down the road.
One of the most reliable and best ways to resolve the issues is to Publish email to queue. Start with creating the simple HTTP Listener:
Then, start with creating the queue where all the emails gets queued up:
Input message should be in JSON payload, which takes from email ID and content of the email. If the email requires any attachment to be sent, then we have to ensure that attachment in the JSON payload which only access binary contents. So, whenever email is sent, we have to ensure that attachment content is converted into binary and sent to Graph API.
Then, create the scheduler that will run every 1.5 seconds, for each email sending to the MS Graph API, so we can avoid all this throttling and limitation issues:
Other possible issues and how to resolve them
Beyond MS Graph throttling and limitations issues, there are also another two common issues:
1) "Token Lifetime Issue", that is actually bug in the Connector and quick fix to resolve this issue will be to replace older version of the connector with the latest version of Outlook 365 connector.
2) "Emails not being sent out from the Outlook", due to the clustering. If you have worker 0 and worker 1, worker 0 becomes main node and worker 1 becomes secondary node. Thus, any request that comes in, it will be balanced in worker 0 and worker 1. But, whichever request comes in the worker 1 it will end in the queue only and "Scheduler" will not run because worker 1 is in secondary node and those emails will never get picked up. To resolve the issue, configure APP with the 2 worker setup, and configure "Scheduler" to run only from the main node, because it will run from there.
Load Testing
Load testing should be done on 1 worker with 0.2 vCores, which is more than enough for 200 requests / second. You can use any open source tool for testing such as Jmeter.