Integração do Azure com o Microsoft Dynamics 365

 

Publicado: janeiro de 2017

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

É possível se conectar o Microsoft Dynamics 365 (online e local) com a plataforma do Microsoft Azure acoplando o pipeline de execução de evento do Dynamics 365 ao Barramento de Serviço do Microsoft Azure. Uma vez configurada, esta conexão permite que os dados que foram processados como parte da operação Dynamics 365 atual sejam postados no barramento de serviço.Barramento de Serviço do Microsoft Azure as soluções que são reconhecidas pelo“Dynamics 365” podem ouvir e ler os Microsoft Dynamics 365 dados do barramento de serviço.

A conexão entre o Microsoft Dynamics 365 e a plataforma Microsoft Azure fornece um canal seguro e confiável para comunicar Dynamics 365 dados de tempo de execução a aplicativos da linha de negócios baseados em nuvem externos.

Neste tópico

Principais elementos da conexão

Cenário do para Barramento de Serviço do Dynamics 365

Estabelece um contrato entre o Dynamics 365 e uma solução do Azure

Gerenciar erros de tempo de execução

Principais elementos da conexão

Os principais elementos que implementam a conexão entre o Microsoft Dynamics 365 e o Barramento de Serviço do Microsoft Azure estão descritos abaixo. Um diagrama na seção a seguir mostra os elementos em operação.

• Contexto de Dados
  O contexto de dados contém os dados corporativos que estão sendo processados como parte da operação Dynamics 365 atual. O processamento foi iniciado quando uma solicitação para executar uma determinada operação foi feita por um usuário, por um fluxo de trabalho ou por um aplicativo à plataforma do Dynamics 365. O contexto de dados é passado para os plug-ins ou atividades do fluxo de trabalho personalizadas que são registrados com o pipeline de evento para executar a solicitação e a combinação da entidade específicas que estão sendo processadas. O contexto de dados é do tipo IPluginExecutionContext quando ele está sendo passado juntamente com o pipeline de execução de evento e RemoteExecutionContext quando ele é postado no barramento de serviço.

  O contexto de dados contido dentro da mensagem que é postada no Barramento de Serviço do Microsoft Azure pode ser formatado em XML ou em JSON, além do formato binário .NET padrão. Isso permite uma interoperabilidade multiplataforma em que os clientes não .NET hospedados pelo Azure podem ler Dynamics 365 dados do barramento de serviço.Esse recurso foi apresentado na Atualização 1 do CRM Online 2016 e no CRM 2016 Service Pack 1 (local)..

  Para obter mais informações sobre as tecnologias descritas acima, consulte: Compreender o contexto de dados passado para um plug-in, Pipeline de execução do evento e Escrever um aplicativo ouvinte para uma solução do Microsoft Azure.

• Plug-ins
  Os plug-ins são um de dois métodos usados para começar a postar a mensagem com o contexto dos dados no Barramento de Serviço do Microsoft Azure; sendo o outro método uma atividade de fluxo de trabalho personalizada. Há dois tipos de plug-ins com suporte do recurso de conexão do Dynamics 365-Azure: prontos e personalizados. Nos dois casos, é recomendado registrar o plug-in para executar de maneira assíncrona e obter um melhor desempenho do sistema.

  Um plug-in pronto com reconhecimento do Azure é fornecido com o Dynamics 365 e pode ser registrado usando a Ferramenta de Registro de Plug-in no download do SDK. Este plug-in executa em total confiança com a plataforma Microsoft Dynamics 365. Você deve registrar uma 'etapa' de plug-in no pipeline de execução do evento, que identifica a mensagem e a combinação de entidade que aciona o plug-in para executar e realizar a notificação de postagem. Quando executado, o plug-in notifica o serviço assíncrono por meio de um serviço de notificação de ponto de extremidade de serviço (IServiceEndpointNotificationService) para postar o contexto dos dados da solicitação atual no Barramento de Serviço do Microsoft Azure.

  Também é possível escrever seu próprio plug-in personalizado com "conhecimento do Azure". O plug-in personalizado é executado no modo de confiança parcial na área restrita. Um plug-in personalizado pode iniciar a postagem de contexto de dados no barramento de serviço por meio do serviço de notificação de ponto de extremidade de serviço. Adicionar o código para invocar esse serviço torna o plug-in “reconhecido pelo Azure”. Para obter mais informações sobre plug-ins em geral, consulte Gravar um plug-in. Para obter mais informações sobre plug-ins de conhecimento do Azure, consulte Redigir um plug-in com reconhecimento de Azure personalizado.

• Atividades de fluxo de trabalho personalizado
  Assim como os plug-ins, as atividades de fluxo de trabalho personalizadas podem ser gravadas para iniciar a postagem do contexto de dados da mensagem de solicitação atual no Barramento de Serviço do Microsoft Azure usando o serviço de notificação de ponto de extremidade de serviço (IServiceEndpointNotificationService).Para obter mais informações:Exemplo: Atividade de fluxo de trabalho personalizada de conhecimento do Azure.

• Serviço Assíncrono
  Uma vez notificado pelo serviço de notificação do ponto de extremidade de serviço, o serviço assíncrono lida com a postagem de contexto de dados da mensagem de solicitação que está sendo atualmente processada pelo pipeline de execução do evento no Barramento de Serviço do Microsoft Azure Cada postagem é executada por um trabalho do sistema do serviço assíncrono. Um usuário pode visualizar o status de cada trabalho do sistema usando a exibição Trabalhos do Sistema do aplicativo Web Microsoft Dynamics 365.

  Para obter mais informações sobre o serviço assíncrono, consulte Serviço assíncrono no Microsoft Dynamics 365.

• Barramento de Serviço do Microsoft Azure
  O barramento de serviço retransmite o contexto dos dados da mensagem de solicitação entre o Microsoft Dynamics 365 e os aplicativos de ouvinte de solução do Barramento de Serviço do Microsoft Azure. O barramento de serviço também fornece segurança de dados de modo que só aplicativos autorizados podem acessar os dados do Dynamics 365 postados. A autorização do Microsoft Dynamics 365 para postar o contexto dos dados no barramento de serviço e para os aplicativos de ouvinte lê-lo é gerenciada tanto pelo Microsoft Azure Active Directory Access Control Service (ACS) quanto pelas Assinaturas de Acesso Compartilhado (SAS) do Microsoft Azure.

  Observação

  Sobre a autorização de SAS: Esse recurso foi apresentado na Atualização 1 do CRM Online 2016 e no CRM 2016 Service Pack 1 (local). a SAS é uma forma mais moderna de autorização e apresenta melhor desempenho quando comparado a ACS.

  Para obter mais informações sobre o barramento de serviço, consulte Barramento de Serviço.Para obter mais informações sobre a autorização de barramento de serviço, consulte Autenticação e Autorização de Barramento de Serviço.

• Solução do Microsoft Azure
  Para que a conexão Dynamics 365-Azure funcione, é preciso ter pelo menos uma solução em uma Barramento de Serviço do Microsoft Azure conta de solução, em que a solução contenha um ou mais pontos de extremidade de serviço. Para um contrato de ponto de extremidade de retransmissão, um aplicativo de ouvinte que tenha "reconhecimento do Dynamics 365" deve estar ouvindo ativamente no ponto de extremidade da solicitação do Dynamics 365 no barramento de serviço. Para um contrato de ponto de extremidade da fila, um ouvinte não precisa estar ouvindo ativamente. Um ouvinte tem "conhecimento do Dynamics 365" vinculando-o para o assembly do Microsoft.Xrm.Sdk de forma que o tipo RemoteExecutionContext seja definido.Para obter mais informações:Escrever um aplicativo ouvinte para uma solução do Microsoft Azure

  Microsoft Dynamics 365 oferece suporte ao envio de dados de evento para uma solução Hubs de Eventos do Azure.Esse recurso foi apresentado na Atualização 1 do CRM Online 2016 e no CRM 2016 Service Pack 1 (local)..Para obter mais informações sobre hubs de evento, consulte Trabalhar com dados de eventos do Dynamics 365 em sua solução de Hub de Evento do Azure.

Cenário do para Barramento de Serviço do Dynamics 365

Agora vamos identificar um cenário que implementa os componentes de conexão mencionados anteriormente. Como pré-requisito, o ACS foi configurado para reconhecer o Microsoft Dynamics 365 como o emissor suportado e a solução Barramento de Serviço do Microsoft Azure configurada com regras para permitir que o Microsoft Dynamics 365 poste no ponto de extremidade no qual é ouvido.

O diagrama a seguir mostra os elementos físicos que compõem o cenário.

A sequência de eventos como identificada neste diagrama é a seguinte:

1. Um aplicativo de ouvinte é registrado em um ponto de extremidade de solução do Barramento de Serviço do Microsoft Azure e começa a ouvir ativamente o contexto de execução remota do Microsoft Dynamics 365 no barramento de serviço.

2. Um usuário executa alguma operação no Microsoft Dynamics 365 que aciona a execução do plug-in OOB registrado ou um plug-in de conhecimento do Azure personalizado. O plug-in inicia uma postagem por meio de um trabalho do sistema de serviço assíncrono do contexto de dados da solicitação atual no barramento de serviço.

3. As declarações postadas pelo Microsoft Dynamics 365 são autenticadas. O barramento de serviço confia no contexto de execução remoto para o ouvinte. O ouvinte processa as informações de contexto e executa algumas tarefas relacionada aos negócios com essas informações. O barramento de serviço notifica o serviço assíncrono de uma postagem com sucesso e define o trabalho do sistema relacionado a um status de concluído.

Estabelece um contrato entre o Dynamics 365 e uma solução do Azure

Para cada ponto de extremidade da solução, você configura um contrato que define a manipulação dessas "mensagens" de contexto de execução remota no barramento de serviço e a segurança que deve ser usada nesse ponto de extremidade. As mensagens do barramento de serviço são recebidas em um ponto de extremidade usando um dos contratos suportados listados aqui.

• Fila
  Um contrato em fila fornece uma fila de mensagens na nuvem. Com um contrato de fila, um ouvinte não precisa estar ouvindo ativamente as mensagens no ponto de extremidade. Para filas, há uma leitura destrutiva e uma leitura não destrutiva. Uma leitura destrutiva lê a mensagem disponível da fila e a mensagem é removida. Uma leitura não destrutiva não remove uma mensagem da fila.

  O tipo de fila com suporte do Microsoft Dynamics 365 é chamado de fila persistente. As filas persistentes têm uma duração de disponibilidade de mensagem longa, mas finita, que pode ser especificada no código.

• Unidirecional
  Um contrato unidirecional requer um ouvinte ativo. Se não houver um ouvinte ativo em um ponto de extremidade, a postagem no barramento de serviço falha. O Microsoft Dynamics 365 tentará a postagem em períodos de tempo exponencialmente maiores até que o trabalho do sistema assíncrono que esteja postando a solicitação seja finalmente abortado e seu status definido como “Falhou”.

• Bidirecional
  Um contrato bidirecional é semelhante a um contrato unidirecional, exceto pelo valor da cadeia de caracteres que pode ser retornado do ouvinte para o plug-in ou para a atividade do fluxo de trabalho personalizada que iniciou a postagem.

• REST
  Um contrato REST é semelhante a um contrato bidirecional em um ponto de extremidade REST.

• Tópico
  Semelhante a uma fila, exceto que um ou mais ouvintes podem se inscrever para receber mensagens do tópico.

• Hub de Evento
  Esse tipo de contrato aplica-se às soluções do Hub de Evento do Microsoft Azure.

Importante

Para usar esses contratos, você deve gravar os aplicativos de ouvinte usando o Microsoft AzureSDK versão 1.7 ou posterior.

Identificar o tipo de segurança que um contrato usa faz parte da configuração do contrato. Um contrato pode usar a segurança de transporte, que usa Transport Layer Security (TLS) ou Secure Sockets Layer (SSL) (https).

A autenticação baseada em declarações é usada para acesso seguro ao barramento de serviço. A declaração usada para autenticar o barramento de serviço é gerada no Microsoft Dynamics 365 e assinada pelo certificado AppFabricIssuer especificado no banco de dados de configuração do Microsoft Dynamics 365.

Gerenciar erros de tempo de execução

Se um erro ocorreu após uma postagem ser tentada no barramento de serviço, verifique o status do trabalho do sistema relacionado no aplicativo Web =Microsoft Dynamics 365 para obter mais informações sobre o erro. Se o barramento de serviço está inoperante ou um ouvinte/ponto de extremidade não estiver disponível, a mensagem atualmente sendo processada no Microsoft Dynamics 365 não será postada no barramento. O serviço assíncrono continuará a tentar publicar a mensagem em um padrão exponencial onde tentará postar com frequência no início e depois em intervalos cada vez maiores. Para um erro do Microsoft Dynamics 365 interno, as postagens da mensagem não são tentadas. Para um erro de rede ou de barramento de serviço externo, o trabalho do sistema relacionado estará em um estado de "Espera".

Confira Também

Extensões do Azure para Microsoft Dynamics 365
Configurar a integração do Azure com o Microsoft Dynamics 365
Crie plug-ins para ampliar os processos empresariais
Serviço assíncrono no Microsoft Dynamics 365
Entidade AsyncOperation (trabalho do sistema)

Microsoft Dynamics 365

© 2017 Microsoft. Todos os direitos reservados. Direitos autorais