Schreiben eines benutzerdefinierten Azure-Plug-Ins

Veröffentlicht: Januar 2017

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

Das Schreiben eines Plug-Ins, das mit Microsoft Azure funktioniert, ähnelt dem Schreiben eines Microsoft Dynamics 365-Plug-Ins. Allerdings zusätzlich zum Aufrufen aller gewünschten Webdienstmethoden muss das Plug-In Code enthalten, um das Veröffentlichen des Ausführungskontexts in Microsoft Azure Service Bus einzuleiten.

In diesem Thema

Plug-In-Entwurfsüberlegungen

Schreiben des Plug-In-Codes

Plug-In-Registrierung

Verarbeiten einer fehgeschlagenen Servicebusnachricht

Plug-In-Entwurfsüberlegungen

Für ein Plug-In, das synchron ausgeführt wird, sollte der Entwurf so aussehen, dass das Plug-In eine Nachricht an Microsoft Azure sendet, um Informationen von einer Listener-Anwendung oder einem anderen externen Dienst abzurufen. Verwendung eines bidirektionalen oder REST-Vertrags auf dem Microsoft Azure Service Bus-Endpunkt ermöglicht die Rückgabe einer Datenzeichenfolge an das Plug-In.

Es wird nicht empfohlen, dass ein synchrones Plug-In Microsoft Azure Service Bus verwenden, um Daten mit einem externen Dienst zu aktualisieren. Probleme können auftreten, wenn der externe Dienst nicht verfügbar ist oder wenn viele Daten aktualisiert werden müssen. Synchrone Plug-Ins sollten schnell ausgeführt werden und nicht alle angemeldeten Benutzer einer Organisation aufhalten, während ein langatmiger Vorgang ausgeführt wird. Wenn zudem ein Rollback des aktuellen Kernvorgangs, der das Plug-In aufgerufen hat, auftritt, werden alle vorgenommenen Datenänderungen rückgängig gemacht. Dies könnte dazu führen, dass Microsoft Dynamics 365 und ein externer Dienst in einem unsynchronisierten Status bleiben.

Beachten Sie, dass es möglich für synchrone registrierte Plug-Ins ist, Ausführungskontext auf Microsoft Azure Service Bus zu veröffentlichen.

Schreiben des Plug-In-Codes

Im folgenden Beispiel wurde Plug-In-Code hinzugefügt, um den Microsoft Azure-Dienstanbieter abzurufen und die Veröffentlichung des Ausführungskontexts auf dem Servicebus durch Aufrufen von Execute zu initiieren. Ablaufverfolgungscode wurde hinzugefügt, um das Debuggen von Plug-Ins zu erleichtern, da das Plug-In im Sandkasten ausgeführt werden muss.

using System;
using System.Diagnostics;
using System.Threading;
using System.Runtime.Serialization;

using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;

using Microsoft.Xrm.Sdk;

namespace Microsoft.Crm.Sdk.Samples
{
    /// <summary>
    /// A custom plug-in that can post the execution context of the current message to the Windows
    /// Azure Service Bus. The plug-in also demonstrates tracing which assist with
    /// debugging for plug-ins that are registered in the sandbox.
    /// </summary>
    /// <remarks>This sample requires that a service endpoint be created first, and its ID passed
    /// to the plug-in constructor through the unsecure configuration parameter when the plug-in
    /// step is registered.</remarks>
    public sealed class SandboxPlugin : IPlugin
    {
        private Guid serviceEndpointId; 

        /// <summary>
        /// Constructor.
        /// </summary>
        public SandboxPlugin(string config)
        {
            if (String.IsNullOrEmpty(config) || !Guid.TryParse(config, out serviceEndpointId))
            {
                throw new InvalidPluginExecutionException("Service endpoint ID should be passed as config.");
            }
        }

        public void Execute(IServiceProvider serviceProvider)
        {
            // Retrieve the execution context.
            IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

            // Extract the tracing service.
            ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
            if (tracingService == null)
                throw new InvalidPluginExecutionException("Failed to retrieve the tracing service.");

            IServiceEndpointNotificationService cloudService = (IServiceEndpointNotificationService)serviceProvider.GetService(typeof(IServiceEndpointNotificationService));
            if (cloudService == null)
                throw new InvalidPluginExecutionException("Failed to retrieve the service bus service.");

            try
            {
                tracingService.Trace("Posting the execution context.");
                string response = cloudService.Execute(new EntityReference("serviceendpoint", serviceEndpointId), context);
                if (!String.IsNullOrEmpty(response))
                {
                    tracingService.Trace("Response = {0}", response);
                }
                tracingService.Trace("Done.");
            }
            catch (Exception e)
            {
                tracingService.Trace("Exception: {0}", e.ToString());
                throw;
            }
        }
    }
}

In Ihrem Plug-In-Code können Sie die schreibbaren Daten im Kontext aktualisieren, bevor Sie die Veröffentlichung initiieren. Sie können beispielsweise ein Schlüssel-/Wertpaar im Kontext den freigegebenen Variablen hinzufügen.

Plug-In-Registrierung

Es gibt mehrere Beschränkungen, wenn Sie ein benutzerdefiniertes Microsoft Azure-bewusstes Plug-In registrieren. Das Plug-In muss für die Ausführung im Sandkasten registriert werden. Darum kann das Plug-In nur Microsoft Dynamics 365 SDK-Methoden, Microsoft Azure-Lösungsmethoden aufrufen oder auf ein Netzwerk mithilfe eines Webclient zugreifen. Kein anderer externer Zugriff, wie der Zugriff auf ein lokales Dateisystem, ist zulässig.

Für ein Plug-In, das für die Ausführung im asynchronen Modus registriert ist, bedeutet das auch, dass die Reihenfolge der Plug-In-Ausführung verglichen mit anderen asynchronen Plug-Ins nicht garantiert ist. Darüber hinaus werden asynchrone Plug-Ins immer nach dem Microsoft Dynamics 365-Kernvorgang ausgeführt.

Verarbeiten einer fehgeschlagenen Servicebusnachricht

Das erwartete Verhalten einer fehlgeschlagenen Servicebusnachricht ist davon abhängig, ob das Plug-In für asynchrone oder synchrone Ausführung registriert wurde. Für asynchrone Plug-Ins wiederholt der Systemauftrag, der den Ausführungskontext tatsächlich an den Servicebus sendet, den Sendevorgang. Für ein synchrones registriertes Plug-In wird eine Ausnahme zurückgegeben.Weitere Informationen:Verwaltung der Laufzeitfehler

Für ein Plug-In, das für die asynchrone Ausführung registriert ist, umfasst RemoteExecutionContext, das im Textteil der Nachricht enthalten ist, die über den Servicebus gesendet wird, die Eigenschaften OperationId und OperationCreatedOn ein. Diese Eigenschaften enthalten dieselben Daten wie die Attribute AsyncOperationId und CreatedOn des verknüpften Systemauftrag-Datensatzes (AsyncOperation). Diese zusätzlichen Eigenschaften nutzen die Sequenzierung und die Duplikaterkennung, wenn das Microsoft Azure Service Bus-Senden wiederholt werden muss.

Siehe auch

Azure-Erweiterungen für Microsoft Dynamics 365
Arbeiten mit Dynamics 365 Daten in Ihrer Azure-Lösung
Schreiben eines Plug-Ins
Plug-In-Isolation, Vertrauensstellungen und Statistiken
Ereignisausführungspipeline
Registrieren und Bereitstellen von Plug-Ins

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright