Plattformgrenzwerte

Die Plattform bietet nicht unendlich viele Ressourcen, und die Anzahl der API-Aufrufe, die ausgeführt werden können, ist begrenzt.

Ein Lösungsarchitekt muss sicherstellen, dass die Lösung die von der Plattform vorgegebenen Grenzwerte nicht überschreitet, indem er angemessen entwirft und sicherstellt, dass benutzerdefinierter Code Verstößen gegen Grenzwerte bearbeiten kann.

API-Anforderungen

Anforderungen in Microsoft Power Platform bestehen aus verschiedenen Aktionen, die ein Benutzer für verschiedene Produkte ausführt. In der folgenden Liste wird beschrieben, was eine API-Anforderung auf allgemeiner Ebene darstellt:

• Power Apps – Alle API-Anforderungen an Konnektoren und Microsoft Dataverse
• Power Automate – Alle API-Anforderungen an Konnektoren, HTTP-Aktionen und integrierte Aktionen, von der Initialisierung von Variablen bis zu einer einfachen Aktion „Erstellen“ Sowohl erfolgreiche als auch fehlgeschlagene Aktionen zählen zu diesen Grenzen. Darüber hinaus gelten auch Wiederholungsversuche und andere Anforderungen aus der Paginierung als Aktionsimplementierungen. Grundsätzlich ist jeder Schritt in einem Power Automate-Cloud-Flow eine API-Anforderung.
• Dataverse – Alle Vorgänge zum Erstellen, Lesen, Aktualisieren und Löschen (CRUD), Zuweisen und Freigeben, einschließlich benutzergesteuerter und interner Systemanforderungen, die zum Abschließen von CRUD-Transaktionen erforderlich sind, sowie spezielle Vorgänge wie Freigeben oder Zuweisen Diese Anforderungen können von jedem Client oder jeder Anwendung stammen und einen beliebigen Endpunkt verwenden. Diese Anforderungen umfassen, ohne darauf beschränkt zu sein, Plug-Ins, klassische Workflows und benutzerdefinierte Steuerelemente, mit denen die zuvor genannten Vorgänge ausgeführt werden.

Berechtigungslimits

Berechtigungslimits geben die Anzahl der API-Anforderungen an, zu denen Benutzer täglich berechtigt sind. Das zugewiesene Limit hängt von der Art der Lizenz ab, die jedem Benutzer zugewiesen wird. API-Berechtigungslimits basieren auf einem Zeitraum von 24 Stunden, wie in der folgenden Tabelle gezeigt.

Dataverse bietet die Möglichkeit, Identitäten zu haben, für deren Interaktion mit dem Dienst keine Benutzerlizenz erforderlich ist. Die vier Arten von Benutzern sind:

• Anwendungsbenutzer
• Nicht interaktive Benutzer
• Benutzer mit Administratorrechten
• SYSTEM-Benutzer

Jeder Mandant verfügt über eine Basisanforderungskapazität für jeden Mandanten, die nur von diesen Benutzern und nicht von Benutzern mit Standardlizenzen verwendet werden kann. Diese Basisanforderungskapazität basiert wie folgt auf der Art des Abonnements:

• Wenn ein Mandant mindestens ein Dynamics 365-Unternehmensabonnement hat, erhält er alle 24 Stunden 100.000 Anfragen.
• Wenn ein Mandant mindestens ein Dynamics 365 Professional-Abonnement hat, erhält er alle 24 Stunden 50.000 Anfragen.
• Wenn ein Mandant mindestens ein Microsoft Power Apps‑ oder Power Automate-Abonnement hat, erhält er alle 24 Stunden 25.000 Anfragen.

Das Power Apps‑ und Power Automate-Kapazitäts-Add-On ermöglicht Kunden, die Grenzwerte für einen bestimmten Benutzer zu erhöhen. Jedes Kapazitäts-Add-On erhöht die Anforderungslimits alle 24 Stunden um weitere 10.000.

Dienstlimits

Abgesehen vom täglichen API-Anforderungslimit stehen Dienstschutzbeschränkungen zur Verfügung, die für jeden Dienst spezifisch sind. Wie bei den täglichen Limits tragen Dienstlimits zur Aufrechterhaltung der Dienstqualität bei, indem sie den Dienst vor böswilligem oder störendem Verhalten schützen, das sonst den Dienst aller Kunden unterbrechen würde.

API-Limits für den Dienstschutz stellen sicher, dass Benutzer, die Anwendungen ausführen, sich aufgrund von Ressourcenbeschränkungen nicht gegenseitig stören können. Die Limits wirken sich nicht auf normale Benutzer der Plattform aus. Nur Anwendungen, die zahlreiche API-Anforderungen ausführen, sind möglicherweise betroffen. Die Limits bieten ein gewisses Maß an Schutz vor zufälligen und unerwarteten Schwankungen des Anforderungsvolumens, die die Verfügbarkeit und die Leistungsmerkmale des Anforderungsvolumens der Dataverse-Plattform gefährden.

Microsoft begrenzt die Anzahl gleichzeitiger Verbindungen für jedes Benutzerkonto, die Anzahl der API-Anforderungen für jede Verbindung und die Laufzeit, die für jede Verbindung verwendet werden kann. Diese Einschränkungen werden innerhalb eines fünfminütigen Schiebefensters bewertet. Wenn einer dieser Grenzwerte überschritten wird, wird von der Plattform eine Ausnahme ausgelöst.

Richtlinien und Muster für Wiederholungen

Benutzerdefinierte Logik, die die APIs verwendet, sollte Wiederholungsversuche verarbeiten. Wenn ein Fehler im Hinblick auf das API-Limit für den Dienstschutz auftritt, wird ein Wert mit der Dauer bereitgestellt, bevor neue Anforderungen des Benutzers bearbeitet werden können.

Die Web-API gibt einen 429-Fehler zurück, wenn das Limit erreicht ist. Die Antwort enthält die Option Retry-After mit der Anzahl der Sekunden. Mit dem Organisationsdienst wird ein TimeSpan-Wert in der Sammlung „OrganizationServiceFault.ErrorDetails“ mit dem Schlüssel Retry-After zurückgegeben.

Weitere Informationen finden Sie unter Dienstschutzgrenzen.

API-Aufrufe minimieren

Das Lösungsdesign darf nicht von der verfügbaren unendlichen Kapazität abhängen. Für normale Benutzer interaktiver Apps wurden die Grenzwerte so hoch festgelegt, dass Benutzer nicht betroffen sein sollten.

Anwendungen, die konzipiert wurden, um Daten in Dataverse zu laden oder Massenaktualisierungen auszuführen, müssen auch API-Limitfehler für den Dienstschutz verwalten können. Diese Anwendungen priorisieren den Durchsatz, damit sie ihre Arbeit in kürzester Zeit erledigen können. Sie müssen eine Strategie besitzen, um zu versuchen, Vorgänge erneut auszuführen.

Portalanwendungen senden normalerweise Anforderungen von anonymen Benutzern über ein Dienstprinzipalkonto. Da die API-Limits für den Dienstschutz auf Benutzerbasis basieren, können Portalanwendungen die API-Limits für den Dienstschutz basierend auf dem Verkehrsaufkommen des Portals erreichen.

Integrationen sollten optimiert werden, um die Anzahl der API-Aufrufe zu minimieren.

Der Lösungsarchitekt muss überlegen, wie Hochverfügbarkeit in das Design der Lösung einbezogen werden kann.