Ereignisausführungspipeline

 

Veröffentlicht: Januar 2017

Gilt für: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Das Microsoft Dynamics 365-Ereignisverarbeitungs-Subsystem führt Plug-Ins basierend auf einem Nachrichtenpipeline-Ausführungsmodell aus. Eine Benutzeraktion in der Microsoft Dynamics 365-Webanwendung oder eine SDK-Methode, die durch ein Plug-In oder andere Anwendung aufgerufen wird, führt dazu, dass eine Nachricht an den Webdienst der Organsation gesendet wird. Die Meldung enthält Geschäftsentitätsinformationen und Kernvorgangsinformationen. Die Nachricht wird durch die Ereignisausführungspipeline übermittelt, in der sie von dem Plattformkernvorgang and den registrierten Plug-Ins gelesen oder geändert werden kann.

Hinweis

Obwohl es mehrere Webdienste gibt, die von der Microsoft Dynamics 365-Plattform gehostet werden, können nur Ereignisse, die von den Organisations- und OData-Endpunkten ausgelöst werden, verursachen, dass Plug-Ins ausgeführt werden.

In diesem Thema

Architektur und verwandte Komponenten

Pipelinephasen

Nachrichtenverarbeitung

Plug-In-Registrierung

Einschluss in Datenbanktransaktionen

Architektur und verwandte Komponenten

Die folgende Abbildung zeigt die Gesamtarchitektur der Microsoft Dynamics 365-Plattform in Bezug auf synchrone und asynchrone Ereignisverarbeitung.

Diagramm zur synchronen und asynchronen Ereignisverarbeitung

Die Ereignisausführungspipeline verarbeitet Ereignisse entweder synchron oder asynchron. Der Plattformkernvorgang und Plug-Ins, die für synchrone Ausführung registriert sind, werden sofort ausgeführt. Synchrone Plug-Ins, die für das Ereignis registriert sind, werden in einer klar definierten Reihenfolge ausgeführt. Plug-Ins, die für asynchrone Ausführung registriert sind, werden vom asynchronen Warteschlangenagenten in die Warteschlange eingereiht und zu einem späteren Zeitpunkt vom Async-Dienst ausgeführt.

Wichtig

Unabhängig davon, ob ein Plug-In synchron oder asynchron ausgeführt wird, gibt es ein zweiminütiges Zeitlimit, das für die Ausführung einer (Nachrichten-) Anforderung gilt. wenn die Ausführung Ihrer Plug-In-Logik das Zeitlimit überschreitet, wird eine System.TimeoutException ausgelöst. Wenn ein Plug-In mehr Verarbeitungszeit als zwei Minuten benötigt, sollten Sie die Verwendung eines Workflows oder anderen Hintergrundprozesses in Betracht ziehen, um die beabsichtigte Aufgabe auszuführen. Dieses Zeitlimit von zwei Minuten betrifft nur die zur Ausführung mit teilweiser Vertrauenswürdigkeit registrierten Plug-Ins (auch Sandbox genannt).Weitere Informationen:Plug-In-Isolation, Vertrauensstellungen und Statistiken

Pipelinephasen

Die Ereignispipeline ist in mehrere Phasen unterteilt, von denen 4 verfügbar sind, um vom Benutzer entwickelte oder Drittanbieter-Plug-Ins zu registrieren. Mehrere Plug-Ins, die in den einzelnen Phasen registriert sind, können innerhalb dieser Phase während der Plug-In-Überprüfung weiter geordnet (gereiht) werden.

Ereignis	Name der Phase	Phasenzahl	Beschreibung
Vor-Ereignis	Vorabüberprüfung	10	Phase in der Pipeline für Plug-Ins, die vor dem Hauptsystemvorgang auszuführen sind. Die Plug-Ins, die in dieser Phase registriert sind, können außerhalb der Datenbanktransaktion ausgeführt werden. Sicherheit Hinweis Die Vor-Überprüfungsphase tritt vor der Ausführung der Sicherheitsüberprüfungen auf, die ausgeführt werden, um zu überprüfen, ob der anfufende oder angemeldete Benutzer über die entsprechenden Berechtigungen verfügt, um den beabsichtigten Vorgang auszuführen.
Pre-Event	Vorgelagerter Vorgang	20	Phase in der Pipeline für Plug-Ins, die vor dem Hauptsystemvorgang auszuführen sind. Die Plug-Ins, die in dieser Phase registriert sind, werden innerhalb der Datenbanktransaktion ausgeführt.
Plattform-Kernvorgang	MainOperation	30	Transaktionsinterner Hauptvorgang des Systems, z. B. Erstellen, Aktualisieren, Löschen, usw. Keine benutzerdefinierten Plug-Ins können in dieser Phase registriert werden.Nur zur internen Verwendung.
Post-Event	Nachgelagerter Vorgang	40	Phase in der Pipeline für Plug-Ins, die nach dem Hauptsystemvorgang auszuführen sind. Die Plug-Ins, die in dieser Phase registriert sind, werden innerhalb der Datenbanktransaktion ausgeführt.

Nachrichtenverarbeitung

Immer wenn ein Anwendungscode oder ein Workflow eineMicrosoft Dynamics 365-Webdienstmethode aufruft, tritt im System eine Statusänderung ein, die ein Ereignis auslöst. Die Informationen, die an eine Webdienstmethode übergeben werden, werden intern in eine OrganizationRequest-Nachricht verpackt und durch die Pipeline verarbeitet. Die Informationen in der OrganizationRequest-Meldung werden an das erste Plug-In übergeben, das für dieses Ereignis registriert ist, wo sie gelesen oder geändert werden kann, bevor sie an das nächste registrierte Plug-In für dieses Ereignis übergeben wird, usw. Plug-Ins erhalten die Nachrichteninformationen in Form von Kontext, der an inre Execute-Methode übergeben wird. Die Nachricht wird auch an den Plattformkernvorgang übergeben.

Plug-In-Registrierung

Plug-Ins können registriert werden, um vor oder nach dem Plattform-Kernvorgang ausgeführt zu werden. Für Pre-Event registrierte Plug-Ins erhalten die OrganizationRequest-Nachricht zuerst nd können den Nachrichteninhalt ändern, bevor die Nachricht an den Kernvorgang übergeben wird. Nachdem der Plattform-Kernvorgang abgeschlossen wurde, ist die Meldung als OrganizationResponse bekannt. Die Antwort wird an die registrierten Post-Event-Plug-Ins übergeben. Post-Event-Plug-Ins haben die Möglichkeit, die Meldung zu ändern, bevor eine Kopie der Antwort an alle registrierten asynchronen Plug-Ins übergeben wird. Zuletzt wird die Antwort an die Anwendung oder den Workflow zurückgegeben, die den ursprünglichen Webdinest-Methodenaufruf aufgerufen hat.

Da ein einzelner Microsoft Dynamics 365-Server mehrere Organisationen hosten kann, ist die Ausführungspipeline organisationsspezifisch. Es gibt eine virtuelle Pipeline für jede Organisation. Plug-Ins, die für die Pipeline registriert sind, können nur Geschäftsdaten für eine einzelne Organisation bearbeiten. Ein Plug-In, das entwickelt wude, um mit mehreren Organisationen zu funktionieren, muss in der Ausführungspipeline jeder einzelnen Organisationen registriert sein.

Einschluss in Datenbanktransaktionen

Plug-Ins können innerhalb oder außerhalb der Datenbanktransaktion der Microsoft Dynamics 365-Plattform ausgeführt werden. Ob ein Plug-In zu der Transaktion gehört, ist davon abhängig, wie die Nachrichtenanforderung durch die Pipeline verarbeitet wird. Sie können überprüfen, ob das Plug-In innerhalb der Transaktion ausgeführt wird, indem Sie die IsInTransaction-Eigenschaft lesen, die von IPluginExecutionContext geerbt wird, die an das Plug-In übergeben wird. Wenn ein Plug-In in der Datenbanktransaktion ausgeführt wird und zulässt, das eine Ausnahme an die Plattform zurückgegeben wird, wird für die gesamte Transaktion ein Rollback ausgeführt. Für die Phasen 20 und 40 ist sichergestellt, dass sie Teil der Datenbanktransaktion sind, während Phase 10 ein Teil der Transaktion sein kann.

Jedes registrierte Plug-In, das während der Datenbanktransaktion ausgeführt wird und eine Ausnahme an die Plattform zurückgibt, führt zum Abbruch des Kernvorgangs. Dies führt zu einem Rollback des Kernvorgangs. Außerderm werden für Pre-Event und Post-Event registrierte Plug-Ins, die noch nicht ausgeführt wurden, und Workflows, die durch dasselbe Ereignis ausgelöst wurden, für das das Plug-In registriert wurde, nicht ausgeführt.

Siehe auch

Einführung in das Ereignisframework
Plug-In-Isolation, Vertrauensstellungen und Statistiken
Registrieren und Bereitstellen von Plug-Ins
Asynchroner Service in Microsoft Dynamics 365

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright