Redigir um plug-in com reconhecimento de Azure personalizado

 

Publicado: janeiro de 2017

Aplicável a: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Criar um plug-in que funciona com o Microsoft Azure é semelhante a criar qualquer outro plug-in do Microsoft Dynamics 365. Entretanto, além de invocar qualquer serviço da Web desejado, o plug-in deve incluir código para começar a postar o contexto de execução para o Barramento de Serviço do Microsoft Azure.

Neste tópico

Considerações sobre a criação de plug-in

Redigir o código de plug-in

Registro de plug-in

Manipular uma postagem do barramento de serviço com falha

Considerações sobre a criação de plug-in

Para um plug-in que executa em sincronia, a criação recomendada é para o plug-in enviar uma mensagem para o Microsoft Azure com a finalidade de recuperar informações de um aplicativo de escuta ou outro serviço externo. O uso de um contrato REST ou bidirecional no ponto de extremidade do Barramento de Serviço do Microsoft Azure permite que uma cadeia de caracteres de dados seja retornada para o plug-in.

Não é recomendável que um plug-in de sincronização use o Barramento de Serviço do Microsoft Azure para atualizar dados com um serviço externo. Podem ocorrer problemas quando o serviço externo se torna indisponível ou se há muitos dados para atualizar. Os plug-ins síncronos não precisam executar rapidamente e sustentar todos os usuários conectados de uma organização enquanto uma operação comprida é realizada. Além disso, se uma reversão da operação principal atual que invocou a ocorrência do plug-in, as alterações de dados realizadas pelo plug-in são desfeitas. Isso pode deixar o Microsoft Dynamics 365 e um serviço externo em um estado não sincronizado.

Observe que possível para plug-ins registrados síncronos postar o contexto de execução para o Barramento de Serviço do Microsoft Azure.

Redigir o código de plug-in

No plug-in de exemplo a seguir foi adicionado código para obter o provedor de serviços do Microsoft Azure e iniciar a postagem do contexto de execução para o barramento de serviço chamando o Execute. O código de rastreamento for adicionado para facilitar a depuração do plug-in porque o plug-in deve ser executado na área restrita.

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

No código de plug-in, você pode atualizar os dados gravados no contexto antes de iniciar a postagem. Por exemplo, você pode adicionar um par de chaves/valor para as variáveis compartilhadas no contexto.

Registro de plug-in

Há algumas limitações quando você registra um plug-in personalizado ciente do Microsoft Azure. O plug-in deve ser registrado para execução na área restrita. Dessa forma, o plug-in é limitado a chamar os métodos SDK do Microsoft Dynamics 365, os métodos de solução do Microsoft Azure ou acessar uma rede com o cliente Web. Nenhum outro acesso externa, como o acesso a um sistema de arquivos local, é permitido.

Para um plug-in registrado executar no modo assíncrono, isso significa também que o pedido de execução do plug-in comparado a outros plug-ins assíncronos não está garantido. Além disso, os plug-ins assíncronos sempre executam após a operação principal do Microsoft Dynamics 365.

Manipular uma postagem do barramento de serviço com falha

O comportamento esperado de uma postagem de barramento do serviço com falha depende se o plug-in foi registrado para execução síncrona ou assíncrona. Para plug-ins assíncronos, o trabalho do sistema que realmente posta o contexto de execução para o barramento de serviço tentará novamente a postagem. Para um plug-in registrado síncrono, uma exceção é retornada.Para obter mais informações:Gerenciar erros de tempo de execução

Importante

Apenas para os plug-ins registrados assíncronos, quando trabalho assíncrono que posta para o Barramento de Serviço do Microsoft Azure é tentado novamente depois de uma falha na postagem, toda lógica de plug-in é executada novamente. Dessa forma, não adicione qualquer outra lógica para o plug-in de conhecimento personalizado do Microsoft Azure além de apenas modificar o contexto e postar no barramento de serviço.

Para um plug-in registrado para executar de forma assíncrona, o RemoteExecutionContext contido no corpo da mensagem que é enviado pelo barramento de serviço inclui uma propriedade OperationId e uma propriedade OperationCreatedOn. Essas propriedades contêm os mesmos dados que os atributos AsyncOperationId e CreatedOn do registro do Trabalho do Sistema relacionado (AsyncOperation). Essas propriedades adicionais facilitam a sequência e a detecção de duplicidades se a postagem do Barramento de Serviço do Microsoft Azure precisar ser tentada novamente.

Confira Também

Extensões do Azure para Microsoft Dynamics 365
Trabalhar com dados do Dynamics 365 em sua solução Azure
Gravar um plug-in
Isolamento, estatísticas e confianças de plug-in
Pipeline de execução do evento
Registrar e implantar plug-ins

Microsoft Dynamics 365

© 2017 Microsoft. Todos os direitos reservados. Direitos autorais