API-Grenzwerte für den Serviceschutz

Um eine konsistente Verfügbarkeit und Leistung für alle zu gewährleisten, wenden wir einige Einschränkungen für die Verwendung von APIs anwenden. Diese Einschränkungen wurden entwickelt, um zu erkennen, wenn Client-Anwendungen außergewöhnliche Anforderungen an die Server-Ressourcen stellen.

Die Beschränkungen sollten normale Benutzer interaktiver Clients nicht betreffen. Nur Client-Anwendungen, die außergewöhnliche API-Anforderungen ausführen, sollten betroffen sein. Der Grenzwert bietet einen gewissen Schutz vor dem unwillkürlichen und unerwarteten Anstieg des Anforderungsvolumens, das die Verfügbarkeit und Leistungsfähigkeit der Microsoft Dataverse Plattform gefährdet.

Wenn eine Clientanwendung außerordentlich anspruchsvolle Anforderungen stellt, folgt die Dataverse dem allgemeinen Muster für Onlinedienste. Wir geben einen Fehler zurück, der darauf hinweist, dass zu viele Anfragen gestellt wurden.

• Mit der Web API erhalten wir einen Fehler 429 Too Many Requests.
• Mit dem Dataverse SDK für .NET erhalten Sie einen OrganizationServiceFault Fehler mit einem von drei spezifischen Fehlercodes. Weitere Informationen: Dienstschutz-API-Limitfehler zurückgegeben

Auswirkungen auf Kundenanwendungen

Es liegt in der Verantwortung der Client-Anwendungen, Fehler bei der Dienstschutz-API-Limitierung zu verwalten. Die genaue Art und Weise, wie man mit diesem Fehler umgeht, hängt von der Art des Antrags ab.

Interaktive Client-Anwendungen

Die Dienstschutz-Grenzwerte sind so hoch, dass es selten vorkommen sollte, dass eine Person, die eine interaktive Client-Anwendung verwendet, bei normaler Nutzung auf sie stößt. Es ist jedoch möglich, wenn die Client-Anwendung Massenoperationen zulässt. Client-Anwendungsentwickler sollten sich darüber im Klaren sein, wie API-Beschränkungen für den Dienstschutz durchgesetzt werden, und die Benutzeroberfläche so gestalten, dass das Potenzial für Benutzer, extrem anspruchsvolle Anfragen an den Server zu senden, reduziert wird. Sie sollten jedoch weiterhin damit rechnen, dass Dienstschutz-API-Grenzwertfehler auftreten können, und darauf vorbereitet sein, mit ihnen umzugehen.

Client-Anwendungsentwickler sollten den Fehler nicht einfach werfen, um dem Benutzer die Meldung anzuzeigen. Die Fehlermeldung ist nicht für Endbenutzer bestimmt. Siehe Wiederherstellungsoperationen für spezifische Strategien.

Anwendungen zur Datenintegration

Anwendungen, die zum Laden von Daten in Dataverse oder zum Durchführen von Massenaktualisierungen entwickelt wurden, müssen auch in der Lage sein, Service Protection API-Grenzwertfehler zu verwalten. Diese Anwendungen priorisieren den Durchsatz, damit sie ihre Arbeit in kürzester Zeit abschließen können. Diese Anwendungen müssen über eine Strategie zur Wiederholung von Operationen verfügen. Es gibt mehrere Strategien, die sie anwenden können, um den maximalen Durchsatz zu erzielen. Weitere Informationen: Wie man den Durchsatz maximiert.

Portal-Anwendungen

Portalanwendungen senden normalerweise Anforderungen von anonymen Benutzern über ein Dienstprinzipalkonto. Da die API-Grenzwerte für den Dienstschutz auf einer Pro-Benutzer-Basis basieren, können Portalanwendungen die API-Grenzwerte für den Dienstschutz auf der Grundlage des Verkehrsaufkommens im Portal erreichen. Wie bei interaktiven Client-Anwendungen wird nicht erwartet, dass die Dienstschutz-API Fehler für den Portal-Endbenutzer anzeigt. Es wird erwartet, dass die Benutzeroberfläche weitere Anfragen deaktivieren und eine Meldung anzeigen sollte, dass der Server ausgelastet ist. Die Meldung kann den Zeitpunkt enthalten, zu dem die Anwendung mit der Annahme neuer Anfragen beginnen kann.

Auswirkungen auf Plug-ins und benutzerdefinierte Workflow-Aktivitäten

Plug-ins und benutzerdefinierte Workflow-Aktivitäten wenden Geschäftslogik an, die durch eingehende Anfragen ausgelöst wird. Serviceschutz-Limits werden nicht auf Plug-ins und benutzerdefinierte Workflow-Aktivitäten angewendet. Plug-ins und benutzerdefinierte Workflow-Aktivitäten werden hochgeladen und innerhalb des isolierten Sandbox-Dienstes ausgeführt. Dataverse-Vorgänge, die für den Sandboxdienst aufgerufen werden, verwenden die öffentlichen API-Endpunkte nicht.

Wenn Ihre Anwendung Operationen ausführt, die benutzerdefinierte Logik auslösen, wird die Anzahl der von Plug-ins oder benutzerdefinierten Workflow-Aktivitäten gesendeten Anfragen nicht zu den API-Beschränkungen für den Dienstschutz gezählt. Die zusätzliche Berechnungszeit, die diese Operationen beisteuern, wird jedoch zu der ursprünglichen Anfrage hinzugefügt, die sie ausgelöst hat. Diese Berechnungszeit ist Teil der API-Grenzwerte für den Dienstschutz. Weitere Informationen: Wie Dienstschutz-API-Grenzwerte erzwungen werden

Operationen wiederholen

Wenn ein Dienstschutz-API-Limit-Fehler auftritt, gibt er einen Wert an, der die Dauer angibt, bevor neue Anfragen des Benutzers bearbeitet werden können.

• Wenn ein 429-Fehler von der Web-API zurückgegeben wird, enthält die Antwort ein Retry-After mit der Anzahl der Sekunden.
• Mit dem SDK for .NT, wird ein Wert Zeitspanne in der OrganizationServiceFault zurückgegeben.ErrorDetails Sammeln Sie mit dem Schlüssel Retry-After.

Die Dauer der Wiederholung nach dem Löschen

Die Dauer der Retry-After hängt von der Art der Vorgänge ab, die in den vorangegangenen 5 Minuten gesendet wurden. Je anspruchsvoller die Anfragen sind, desto länger dauert die Wiederherstellung des Servers.

Heute können Sie aufgrund der Art und Weise, wie die Limits ausgewertet werden, davon ausgehen, dass die Anzahl der Anfragen und Ausführungszeitlimits für einen Zeitraum von 5 Minuten überschritten werden, bevor die API-Limits für den Dienstschutz in Kraft treten. Das Überschreiten der Anzahl gleichzeitiger Anfragen führt jedoch sofort zu einem Fehler. Wenn die Anwendung weiterhin solche anspruchsvollen Anfragen sendet, wird die Dauer verlängert, um die Auswirkungen auf die gemeinsamen Ressourcen zu minimieren. Dies führt dazu, dass der individuelle Wiederholungszeitraum nach der Dauer länger ist, was bedeutet, dass Ihre Anwendung längere Zeiträume der Inaktivität sieht, während sie wartet. Dieses Verhalten kann sich in Zukunft ändern.

Wenn möglich, empfehlen wir, zu versuchen, eine konsistente Rate zu erreichen, indem Sie mit einer geringeren Anzahl von Anfragen beginnen und diese allmählich erhöhen, bis Sie beginnen, die Grenzen der API für den Dienstschutz zu erreichen. Lassen Sie sich danach vom Server mitteilen, wie viele Anfragen er innerhalb von 5 Minuten bearbeiten kann. Wenn Sie die maximale Anzahl von Anfragen innerhalb dieses 5-Minuten-Zeitraums begrenzen und die Anzahl der Anfragen allmählich erhöhen, wird die Wiederholungsdauer nach dem Versuch gering gehalten, wodurch der Gesamtdurchsatz optimiert und Server-Ressourcen-Spitzen minimiert werden.

Interaktive Anwendung erneut versuchen

Handelt es sich bei dem Client um eine interaktive Anwendung, sollten Sie eine Meldung anzeigen, dass der Server ausgelastet ist, während Sie die Anfrage des Benutzers erneut versuchen. Möglicherweise möchten Sie dem Benutzer die Möglichkeit geben, den Vorgang abzubrechen. Erlauben Sie Benutzern nicht, weitere Anfragen einzureichen, bis die von Ihnen gesendete vorherige Anfrage abgeschlossen ist.

Nicht-interaktive Anwendung erneut versuchen

Wenn es sich bei dem Client nicht um eine interaktive Anwendung handelt, ist es üblich, einfach abzuwarten, bis die Dauer abgelaufen ist, bevor die Anfrage erneut gesendet wird. Dies geschieht in der Regel durch Anhalten der Ausführung der aktuellen Aufgabe mit Task.Delay oder entsprechenden Methoden.

So versuchen Sie es erneut

Im Folgenden wird beschrieben, wie Sie .NET-Anwendungen mit dem Dataverse SDK für .NET oder der Web-API erneut versuchen:

SDK für .NET

Wenn Sie SDK für .NET verwenden, empfehlen wir Ihnen die Verwendung des Microsoft.Xrm.Tooling.Connector.CrmServiceClient oder der ServiceClient-Klassen. Diese Klassen implementieren die IOrganizationService-Methoden und kann alle zurückgegebenen Dienstschutz-API-Limitfehler verwalten.

Seit Xrm.Tooling.Konnektor Version 9.0.2.16 wird die Anfrage nach dem Zeitraum Wiederholung nach der Dauer automatisch angehalten und erneut gesendet.

Wenn Ihre Anwendung derzeit die niedrigstufige Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy verwendet. oder Microsoft.Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient Klassen. Sie sollten in der Lage sein, diese durch die CrmServiceClient- oder ServiceClient-Klasse zu ersetzen. Die OrganizationServiceProxy wird außer Betrieb genommen.

Weitere Informationen:

• Windows-Client-Anwendungen mit den XRM-Werkzeugen erstellen.
• Office365-Authentifizierungstyp und OrganizationServiceProxy-Klasse für die Verbindung zu Dataverse veraltet

Web-API

Wenn Sie die Web API mit einer Client-Bibliothek verwenden, kann es sein, dass sie das für 429 Fehler erwartete Wiederholungsverhalten unterstützt. Wenden Sie sich an den Herausgeber der Kundenbibliothek.

Wenn Sie Ihre eigene Bibliothek geschrieben haben, können Sie ähnliche Verhaltensweisen wie in diesem Beispielcode für eine Hilfsklasse WebAPIService-Klassenbibliothek (C#) einbauen.

/// <summary>
/// Specifies the Retry policies
/// </summary>
/// <param name="config">Configuration data for the service</param>
/// <returns></returns>
static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy(Config config)
{
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(httpResponseMessage => httpResponseMessage.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
      .WaitAndRetryAsync(
         retryCount: config.MaxRetries,
         sleepDurationProvider: (count, response, context) =>
         {
            int seconds;
            HttpResponseHeaders headers = response.Result.Headers;

            if (headers.Contains("Retry-After"))
            {
               seconds = int.Parse(headers.GetValues("Retry-After").FirstOrDefault());
            }
            else
            {
               seconds = (int)Math.Pow(2, count);
            }
            return TimeSpan.FromSeconds(seconds);
         },
         onRetryAsync: (_, _, _, _) => { return Task.CompletedTask; }
      );
}

Dieses Beispiel verwendet Polly, eine .NET-Bibliothek für Ausfallsicherheit und Behandlung transienter Fehler, die es Entwicklern ermöglicht, Richtlinien wie Retry, Circuit Breaker, Timeout, Bulkhead Isolation und Fallback in einer flüssigen und thread-sicheren Weise auszudrücken.

HTTP-Antwort-Header

Wenn Sie HTTP-Anforderungen mit der Web-API verwenden, können Sie die verbleibenden Grenzwerte mit den folgenden HTTP Header verfolgen:

Kopfzeile	Wertbeschreibung
x-ms-ratelimit-burst-remaining-xrm-requests	Die verbleibende Anzahl von Anforderungen für diese Verbindung
x-ms-ratelimit-time-remaining-xrm-requests	Die kombinierte verbleibende Dauer für alle Verbindungen, die dasselbe Benutzerkonto verwenden

Sie sollten sich nicht auf diese Werte verlassen, um zu kontrollieren, wie viele Anfragen Sie senden. Sie sind für Debugging-Zwecke vorgesehen. Wenn Sie das Affinitäts-Cookie entfernen, werden diese Werte neu gesetzt, wenn Sie eine Verbindung zu einem anderen Server herstellen.

Wie werden die Grenzen der Service Protection API durchgesetzt?

Zwei der API-Grenzwerte für den Dienstschutz werden innerhalb eines Schiebefensters von 5 Minuten (300 Sekunden) ausgewertet. Wenn einer der Grenzwerte innerhalb der letzten 300 Sekunden überschritten wird, wird bei nachfolgenden Anforderungen zum Schutz des Dienstes ein Dienst-API-Grenzwertfehler zurückgegeben, bis die Wiederholungsdauer abgelaufen ist.

Die API-Limits für den Dienstschutz werden pro Benutzer ausgewertet. Jeder authentifizierte Benutzer ist unabhängig begrenzt. Nur die Benutzerkonten, die außergewöhnliche Anforderungen stellen, werden eingeschränkt. Andere Benutzer sind davon nicht betroffen.

Die API-Beschränkungen für den Dienstschutz werden auf der Grundlage von drei Aspekten durchgesetzt:

• Die Anzahl der von einem Benutzer gesendeten Anfragen.
• Die kombinierte Ausführungszeit, die erforderlich ist, um von einem Benutzer gesendete Anfragen zu verarbeiten.
• Die Anzahl der von einem Benutzer gesendeten gleichzeitigen Anfragen.

Wenn die einzige Beschränkung in der Anzahl der von einem Benutzer gesendeten Anfragen bestünde, wäre es möglich, diese zu umgehen. Der anderen Aspekte wurden hinzugefügt, um diesen Versuchen entgegenzuwirken. Beispiel:

• Sie könnten weniger Anfragen senden, indem Sie sie in Batch-Operationen bündeln.
  • Die kombinierte Ausführungszeitbegrenzung wirkt dem entgegen.
• Anstatt Anforderungen einzeln nacheinander zu senden, können Sie eine große Anzahl gleichzeitiger Anforderungen senden, bevor die API-Grenzwerte für den Dienstschutz durchgesetzt werden.
  • Die Begrenzung gleichzeitiger Anfragen wirkt dem entgegen.

Jeder in Ihrer Umgebung verfügbare Webserver setzt diese Beschränkungen unabhängig voneinander durch. Die meisten Umgebungen werden mehr als einen Webserver haben. Testumgebungen wird nur ein einziger Webserver zugewiesen. Die tatsächliche Anzahl der Webserver, die Ihrer Umgebung zur Verfügung stehen, hängt von mehreren Faktoren ab, die Teil des von uns angebotenen verwalteten Dienstes sind. Einer der Faktoren ist, wie viele Benutzerlizenzen Sie erworben haben.

In der folgenden Tabelle werden die erzwungenen API-Grenzwerte für den Standarddienstschutz pro Webserver erzwungen:

Kennzahl	Beschreibung	Limit pro Webserver
Anzahl von Anforderungen	Die kumulative Anzahl der vom Benutzer gestellten Anfragen.	6000 innerhalb des 5-Minuten-Schiebefensters
Ausführungszeit	Die kombinierte Ausführungszeit aller vom Benutzer gestellten Anfragen.	20 Minuten (1200 Sekunden) innerhalb des 5-Minuten-Schiebefensters
Anzahl gleichzeitiger Anfragen	Die Anzahl der gleichzeitigen Anfragen des Benutzers	52 oder höher

Wichtig

Diese Grenzwerte können sich ändern und zwischen verschiedenen Umgebungen variieren. Diese Zahlen stellen Standardwerte dar und sollen Ihnen eine Vorstellung davon vermitteln, welche Werte Sie erwarten können.

Zurückgegebene Dienstschutz-API-Begrenzungsfehler

Dieser Abschnitt beschreibt die drei Arten von API-Grenzwertfehlern für den Dienstschutz, die zurückgegeben werden können, sowie die Faktoren, die diese Fehler verursachen, und mögliche Abhilfestrategien.

• Die Seite Fehlercode ist der numerische Fehlerwert, der vom SDK for .NET OrganizationServiceFaultErrorDetails zurückgegeben wird.
• Die Seite Hex-Code ist der hexadezimale Fehlerwert, der von der Web API zurückgegeben wird.

Anzahl von Anforderungen

Dieses Limit zählt die Gesamtzahl der Anfragen während des vorangegangenen Zeitraums von 300 Sekunden.

Fehlercode	Hex-Code	Nachricht
-2147015902	0x80072322	Number of requests exceeded the limit of 6000 over time window of 300 seconds.

Es wird nicht erwartet, dass ein typischer Benutzer einer interaktiven Anwendung in der Lage sein wird, 1.200 Anfragen pro Minute zu senden, um dieses Limit zu überschreiten, es sei denn, die Anwendung ermöglicht es Benutzern, Massenoperationen durchzuführen.

Wenn eine Listenansicht z.B. die Auswahl von 250 Datensätzen auf einmal ermöglicht und einem Benutzer erlaubt, eine Operation an all diesen Datensätzen durchzuführen, müsste der Benutzer diese Operation 24 Mal in einer Zeitspanne von 300 Sekunden durchführen. Der Benutzer müsste den Vorgang auf jeder Liste innerhalb von 12,5 Sekunden abschließen.

Wenn Ihre Anwendung diese Möglichkeit bietet, sollten Sie einige der folgenden Strategien in Betracht ziehen:

• Verringern der Gesamtzahl der Datensätze, die in einer Liste ausgewählt werden können. Wenn die Anzahl der in einer Liste angezeigten Elemente auf 50 reduziert wird, müsste der Benutzer diesen Vorgang innerhalb von 300 Sekunden 120 Mal durchführen. Der Benutzer müsste den Vorgang auf jeder Liste innerhalb von 2,5 Sekunden abschließen.
• Kombinieren Sie die ausgewählten Vorgänge zu einem Stapel. Ein Batch kann bis zu 1000 Operationen enthalten und vermeidet die Begrenzung der Anzahl von Anfragen. Sie müssen jedoch auf die Ausführungsfrist vorbereitet sein.

Ausführungszeit

Diese Grenze verfolgt die kombinierte Ausführungszeit der eingehenden Anfragen während der vorangegangenen 300-Sekunden-Periode.

Fehlercode	Hex-Code	Nachricht
-2147015903	0x80072321	Combined execution time of incoming requests exceeded limit of 1,200,000 milliseconds over time window of 300 seconds. Decrease number of concurrent requests or reduce the duration of requests and try again later.

Einige Operationen erfordern mehr Ressourcen als andere. Batch-Operationen, das Importieren von Lösungen und hochkomplexe Abfragen können sehr anspruchsvoll sein. Diese Vorgänge können bei gleichzeitigen Anfragen auch gleichzeitig durchgeführt werden. Daher ist es möglich, innerhalb des 5-Minuten-Fensters Operationen anzufordern, die zusammen mehr als 20 Minuten Rechenzeit erfordern.

Diese Beschränkung kann auftreten, wenn Strategien mit Batch-Operationen und gleichzeitigen Anfragen verwendet werden, um die Begrenzung der Anzahl der Anfragen zu vermeiden.

Gleichzeitige Anfragen

Diese Grenze verfolgt die Anzahl gleichzeitig ausgeführter Anforderungen.

Fehlercode	Hex-Code	Nachricht
-2147015898	0x80072326	Number of concurrent requests exceeded the limit of 52.

Client-Anwendungen sind nicht darauf beschränkt, individuelle Anfragen sequenziell zu senden. Der Client kann parallele Programmiermuster oder verschiedene Methoden anwenden, um mehrere Anträge gleichzeitig zu senden. Der Server kann erkennen, wenn er auf mehrere Anfragen desselben Benutzers gleichzeitig antwortet. Wenn diese Anzahl gleichzeitiger Anfragen überschritten wird, wird dieser Fehler ausgelöst. Die Grenze kann in einigen Fällen höher als 52 sein.

Das gleichzeitige Senden von Anfragen kann ein wichtiger Teil einer Strategie zur Maximierung des Durchsatzes sein, aber es ist wichtig, dies unter Kontrolle zu halten. Bei Verwendung von Parallele Programmierung in .NET hängt der Standardgrad der Parallelität von der Anzahl der CPU-Kerne auf dem Server ab, auf dem der Code ausgeführt wird. Sie sollten den Grenzwert nicht überschreiten. Die Eigenschaft ParallelOptions.MaxDegreeOfParallelism kann eingestellt werden, um eine maximale Anzahl gleichzeitiger Aufgaben zu definieren.

Weitere Informationen: Parallele Anfragen senden

Wie Sie den Durchsatz maximieren

Wenn Sie eine Anwendung haben, die den Durchsatz priorisieren muss, um die meisten Daten in kürzester Zeit zu bewegen, gibt es einige Strategien, die Sie anwenden können.

Lassen Sie sich vom Server mitteilen, wie viel er verkraften kann

Versuchen Sie nicht zu berechnen, wie viele Anfragen gleichzeitig zu senden sind. Jede Umgebung kann unterschiedlich sein. Erhöhen Sie allmählich die Rate, mit der Sie Anfragen senden, bis Sie beginnen, die Limits zu erreichen, und hängen Sie dann vom Wert für das API-Limit Retry-After des Dienstschutzes ab, um Ihnen mitzuteilen, wann Sie weitere Anfragen senden müssen. Dieser Wert hält Ihren Gesamtdurchsatz auf dem höchstmöglichen Niveau.

Verwenden von Multi-Threads

Die höhere Begrenzung der Anzahl gleichzeitiger Threads ist etwas, mit dem Ihre Anwendung eine deutliche Leistungsverbesserung erzielen kann. Dies trifft zu, wenn Ihre einzelnen Operationen relativ schnell ablaufen. Je nach Art der Daten, die Sie verarbeiten, müssen Sie möglicherweise die Anzahl der Threads anpassen, um einen optimalen Durchsatz zu erzielen. Weitere Informationen: Parallele Anfragen senden

Große Batches vermeiden

Batchverarbeitung bezieht sich auf das Senden mehrerer Vorgänge in einer einzigen Anforderung.

In den meisten Szenarien werden einzelne Anfragen am schnellsten und mit einem hohen Grad an Parallelität gesendet. Wenn Sie der Meinung sind, dass die Batch-Größe die Leistung verbessern könnte, ist es am besten, mit einer kleinen Batch-Größe von 10 zu beginnen und die Gleichzeitigkeit zu erhöhen, bis Sie beginnen, Fehler bei der Dienstschutz-API-Limitierung zu erhalten, die Sie erneut versuchen werden.

Mit dem SDK für .NET bedeutet dies die Verwendung von ExecuteMultipleRequest, was in der Regel das Senden von bis zu 1.000 Vorgängen in einer Anforderung ermöglicht. Der Hauptvorteil besteht darin, dass dadurch die Gesamtmenge der XML-Payload, die über die Leitung gesendet werden muss, reduziert wird. Dies bietet einen gewissen Leistungsvorteil, wenn Netzwerklatenz ein Problem ist. Für Serviceschutzgrenzwerte wird die Gesamtausführungszeit pro Anforderung erhöht. Größere Batches erhöhen die Wahrscheinlichkeit, dass Sie auf Ausführungszeit-Grenzwerte stoßen, anstatt auf Grenzwerte für die Anforderungsanzahl.

In der Vergangenheit wurden ExecuteMultiple-Vorgänge aufgrund der möglichen Auswirkungen auf die Leistung auf nur 2 gleichzeitig beschränkt. Dies ist nicht mehr der Fall, da API-Grenzwerte für die Ausführungszeit des Serviceschutzes diesen Grenzwert überflüssig gemacht haben.

Bei Verwendung der Web API bedeutet der kleinere JSON-Payload, die für einzelne Anfragen über das Kabel gesendet wird, dass die Netzwerklatenz kein Problem darstellt. Weitere Informationen: Ausführen von Batch-Operationen mit der Web-API

Hinweis

Batch-Operationen sind keine gültige Strategie zur Umgehung der Berechtigungsgrenzen. Dienstschutz-API-Limits und Berechtigungslimits werden separat ausgewertet. Berechtigungsbeschränkungen basieren auf CRUD-Operationen und fallen unabhängig davon an, ob sie in einer Stapelverarbeitung enthalten sind oder nicht. Weitere Informationen: Berechtigungsgrenzen

Strategien zur Verwaltung der Grenzen der Service Protection API

In diesem Abschnitt wird beschrieben, wie Sie Ihre Clients und Systeme so gestalten können, dass Dienstschutz-API-Limit-Fehler vermieden werden. Vielleicht möchten Sie auch überlegen, wie Sie Ihre Lizenzen verwalten, um die Auswirkungen zu verringern.

Aktualisieren Sie Ihre Client-Anwendung

Service Protection API-Grenzwerte werden seit 2018 auf Dataverse angewendet, es wurden jedoch viele Clientanwendungen geschrieben, bevor diese Grenzwerte vorhanden waren. Diese Clients haben diese Fehler nicht erwartet und können die Fehler nicht richtig handhaben. Sie sollten diese Anwendungen aktualisieren und die Muster auf die oben beschriebenen Wiederholungsvorgänge anwenden.

Auf dem Weg zur Echtzeit-Integration

Denken Sie daran, dass der Hauptpunkt der API-Beschränkungen für den Schutz von Diensten darin besteht, die Auswirkungen sehr anspruchsvoller Anfragen zu mildern, die über einen kurzen Zeitraum auftreten. Wenn Ihre aktuellen Geschäftsprozesse von großen periodischen nächtlichen, wöchentlichen oder monatlichen Aufträgen abhängen, die versuchen, große Datenmengen in kurzer Zeit zu verarbeiten, überlegen Sie, wie Sie eine Echtzeit-Datenintegrationsstrategie ermöglichen könnten. Wenn Sie auf Prozesse verzichten können, die sehr anspruchsvolle Operationen erfordern, können Sie die Auswirkungen reduzieren, die die Grenzen des Dienstschutzes haben werden.

Häufig gestellte Fragen

Dieser Abschnitt enthält häufig gestellte Fragen. Wenn Sie Fragen haben, die nicht beantwortet werden, stellen Sie diese bitte über die Schaltfläche Feedback unten auf dieser Seite ein, um Feedback zu dieser Seite einzureichen.

Ich verwende eine ETL-Anwendung, die ich lizenziert habe. Wie erreiche ich einen optimalen Durchsatz?

Arbeiten Sie mit dem Anbieter der ETL-Anwendung zusammen, um zu erfahren, welche Einstellungen anzuwenden sind. Stellen Sie sicher, dass Sie eine Version des Produkts verwenden, die das Verhalten "Retry-After" unterstützt.

Gelten diese Beschränkungen für die Dataverse Suche?

Nein. Die native Dataverse Suche ist eine andere API (api/search und nicht api/data) und hat andere Regeln. Bei Verwendung der Dataverse Such-API gibt es ein Drosselungslimit von einer Anfrage pro Sekunde für jeden Benutzer.

Weitere Informationen: Dataverse-Grenzwerte für den Suchdienstschutz

Wie gelten diese Grenzwerte für die Anzahl der Anfragen, auf die ein Benutzer pro Tag Anspruch hat?

Diese Grenzen beziehen sich nicht auf Anspruchsgrenzen. Weitere Informationen: Berechtigungsgrenzen

Werden Grenzwerte für Anwendungsbenutzer anders angewendet?

Nein. Die Grenzwerte werden auf alle Benutzer auf die gleiche Weise angewendet.

Siehe auch

Verwalten Power Platform / Lizenzierung und Lizenzverwaltung / Anforderungsgrenzen und -zuordnungen
Übersicht über Dataverse API-Grenzwerte
Dataverse-Web-API verwenden
Dataverse SDK für .NET verwenden

Hinweis

Können Sie uns Ihre Präferenzen für die Dokumentationssprache mitteilen? Nehmen Sie an einer kurzen Umfrage teil. (Beachten Sie, dass diese Umfrage auf Englisch ist.)

Die Umfrage dauert etwa sieben Minuten. Es werden keine personenbezogenen Daten erhoben. (Datenschutzbestimmungen).