Skriv en brugerdefineret Azure-følsom plug-in

 

Udgivet: januar 2017

Gælder for: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Skrivning af en plug-in, som fungerer med Microsoft Azure, svarer til at skrive andre Microsoft Dynamics 365-plug-ins. Men ud over aktivering af evt. ønskede webtjenestemetoder, skal plug-in-programmet indeholde kode, der kan initiere sendingen af kørselskonteksten til Microsoft Azure-servicebus.

Dette emne indeholder

Overvejelser vedr. plug-in-design

Skriv plug-in-koden

Registrering af plug-in

Håndter en mislykket sending til servicebus

Overvejelser vedr. plug-in-design

For en plug-in, der afvikles synkront, er det anbefalede design, at den pågældende plug-in sender en meddelelse til Microsoft Azure for at hente oplysninger fra et sporerprogram eller anden ekstern tjeneste. Brug af en tovejs- eller REST-kontrakt på Microsoft Azure-servicebus-slutpunktet giver mulighed for, at en datastreng kan returneres til plug-in-programmet.

Det anbefales ikke, at lade en synkron plug-in bruge Microsoft Azure-servicebus til at opdatere data i en ekstern tjeneste. Problemer kan opstå, hvis den eksterne tjeneste bliver utilgængelig, eller hvis der er en masse data, som skal opdateres. Synkrone plug-ins skal køre hurtigt og ikke opholde alle brugere, der er logget på i en organisation, mens en langvarig handling udføres. Hvis der desuden sker en tilbageførsel af den aktuelle kernehandling, der startede plug-in-programmet, annulleres dataændringer, der er foretaget af denne plug-in. Dette kan efterlade Microsoft Dynamics 365 og en ekstern tjeneste i en ikke-synkroniseret tilstand.

Bemærk, at det er muligt for synkront registrerede plug-ins at sende kørselskonteksten til Microsoft Azure-servicebus.

Skriv plug-in-koden

Følgende eksempel på en plug-in-kode er blevet tilføjet for at hente Microsoft Azure-tjenesteudbyderen og initiere sending af kørselskonteksten til servicebussen ved at kalde Execute. Sporing af kode er blevet tilføjet for at lette fejlfinding af plug-in-programmet, fordi plug-in-programmet skal køre i sandkassen.

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;
            }
        }
    }
}

I din plug-in-kode kan du opdatere de data, der kan skrives i konteksten, før sendingen initieres. For eksempel kan du tilføje et nøgle-/værdipar til de delte variabler i konteksten.

Registrering af plug-in

Er der nogle få begrænsninger, når du registrerer en Microsoft Azure-følsom brugerdefineret plug-in. Denne plug-in skal registreres for at kunne køres i sandkassen. Derfor kan denne plug-in kun kalde Microsoft Dynamics 365-SDK-metoder, Microsoft Azure-løsningsmetoder eller få adgang til et netværk, der bruger en webklient. Ingen anden ekstern adgang, såsom adgang til et lokalt filsystem, er tilladt.

For en plug-in, der er registreret til kørsel i asynkron tilstand, betyder det også, at kørselsrækkefølgen af plug-ins sammenlignet med andre asynkrone plug-ins ikke er garanteret. Desuden køres asynkrone plug-ins altid efter Microsoft Dynamics 365-kernehandlingen.

Håndter en mislykket sending til servicebus

Den forventede funktionsmåde fra en mislykket sending til servicebus er afhængig af, om plug-in-programmet var registreret til synkron eller asynkron kørsel. For asynkrone plug-ins forsøger det systemjob, der rent faktisk sender kørselskonteksten til servicebussen, at sende igen. For en synkront registreret plug-in returneres en undtagelse.Flere oplysninger:Administration af runtime-fejl

Vigtigt

Når det drejer sig om asynkront registrerede plug-ins, køres hele plug-in logikken igen, når det asynkrone job, der sendes til Microsoft Azure-servicebus, er forsøgt kørt igen efter en mislykket sending. Derfor skal du ikke tilføje anden logik til den brugerdefinerede Microsoft Azure-følsomme plug-in end blot at ændre konteksten og sende til servicebussen.

For en plug-in, der er registreret til at køre asynkront, inkluderer den RemoteExecutionContext, der er indeholdt i brødteksten i den meddelelse, der sendes via servicebussen, en OperationId-egenskab og en OperationCreatedOn-egenskab. Disse egenskaber kan indeholde de samme data som attributterne AsyncOperationId og CreatedOn for den relaterede systemjobpost (AsyncOperation). Disse yderligere egenskaber gør det lette at sætte opgaver i rækkefølge og registrere dubletter, hvis sendingen til Microsoft Azure-servicebus skal forsøges igen.

Se også

Azure-udvidelser til Microsoft Dynamics 365
Arbejde med Dynamics 365-data i din Azure-løsning
Skriv en plug-in
Plug-in-isolation, -tillidsforhold og -statistik
Pipeline for hændelseskørsel
Registrere og installere plug-ins

Microsoft Dynamics 365

© 2017 Microsoft. Alle rettigheder forbeholdes. Ophavsret