Dataverse + Service Bus + Custom API integration:

 Let me break that passage down in simple terms with context around Dataverse + Service Bus + Custom API integration:

---

🔹 What it means

1. “To execute operations on Dataverse, we rely on calling a custom API.”

   • Instead of making multiple direct CRUD calls (Create, Read, Update, Delete) from Azure Functions or Service Bus consumers into Dataverse, you create a Custom API in Dataverse.

   • This Custom API acts like a single entry point for your external system.

---

2. “Our function will perform only one call to the Dataverse endpoints, reducing the consumption of API calls entitlements.”

   • Every request to Dataverse consumes API calls quota (licensing entitlements).

   • If you send multiple calls for one business process (like create a case, add tasks, update customer, assign), you consume many entitlements.

   • By wrapping all that logic in a Custom API, you reduce it to just one call.

---

3. “Our business logic can be grouped on Dataverse side in a single plugin, exposing one simple action to the function.”

   • Behind the Custom API, you can attach a plugin that executes multiple Dataverse operations (transactional logic).

   • The external function (Azure Function, Logic App, etc.) just calls one simple action (MyCustomAPI.DoSomething), and Dataverse handles the internal complexity.

---

4. “Any exception in the code will force Service Bus to retry the delivery of the message.”

   • Messages are delivered from Azure Service Bus to your Function.

   • If the Function throws an exception (say, plugin failed or Dataverse rejected data), the Service Bus will retry automatically.

   • This ensures no message is lost.

---

5. “Only when your code completes without exceptions, the message will be consumed and removed from the queue.”

   • Service Bus guarantees at-least-once delivery.

   • A message is marked as successfully processed only if your function runs without throwing errors.

   • If your plugin or Custom API fails, the message stays in the queue and retries again until max retries are hit (then goes to the dead-letter queue).

---

🔹 Why is this approach good?

• ✅ Saves Dataverse API call capacity.

• ✅ Groups complex business logic in one place (Dataverse plugin).

• ✅ Makes external integrations simpler (call one API instead of many).

• ✅ Ensures reliable processing thanks to Service Bus retry logic.

Will there will be throttling issue if we use Azure function directly?

Yes — if you use an Azure Function to call Dataverse directly (without a custom API), you are more likely to hit throttling issues. Let me explain why:

---

🔹 What happens if Function calls Dataverse directly

• Suppose your Azure Function is triggered by Service Bus and each message requires multiple operations in Dataverse:

  • Create a Case

  • Update Contact

  • Add Notes

  • Assign Case

That’s 4 separate API calls to Dataverse per message.

If 1,000 messages arrive → 4,000 Dataverse API calls.
This consumes your API entitlement very fast and may hit rate limits.

---

🔹 Why throttling occurs

Dataverse has limits on:

• API call entitlements per licensed user/app.

• Concurrency limits (number of concurrent requests).

• Throughput per 5-minute interval.

When too many requests come at once, Dataverse responds with 429 (Too Many Requests), forcing your function to retry → more delays & complexity.

---

🔹 Custom API advantage

With a Custom API + plugin approach:

• Your Function calls just one Dataverse API (POST /api/data/v9.2/MyCustomAPI).

• Inside Dataverse, the plugin executes all operations in a single transaction.

• To Dataverse licensing & throttling counters, this is counted as 1 call instead of many.

So, even if 1,000 messages arrive → only 1,000 API calls (instead of 4,000).

---

✅ Direct Function → Dataverse: Higher chance of throttling if many operations per message.
✅ Function → Custom API → Plugin: Much lower chance of throttling, easier to manage, more efficient.