Dynamics 365 – Acionar Plugin via JScript

Olá pessoal,

Uma ótima pergunta (ou conjunto de perguntas! rs) foi feita por Tiago Ferraz Alves, que seriam:

Fazer uso do objeto XMLHttpRequest (Ajax) para acionar Plugin é uma prática suportada? Quais são os ganhos e perdas? Você já utilizou anteriormente?

Achei interessante criar um post para que possa ajudar outras pessoas a tomar a decisão de utilizar ou não esta técnica.

Primeiramente, um pouco de base e dimensão do que estamos falando…

Vale apena lembrar que por mais que o Ajax seja capaz de se comunicar com o lado servidor (server-side), sua execução é feita no lado cliente (client-side) de um aplicação, pois é baseado em JScript e envio de pacotes de transmissão.

No entanto, plugins são baseados no server-side, deste modo, apenas serviços/aplicações dentro de um servidor web poderiam “trabalhar” com os plugins.

Como conclusão do que eu disse acima: não é possível “chamar” diretamente um plugin através do lado cliente. Mas indiretamente é absolutamente possível!

Por que indiretamente é possível?

Por mais que não seja possível fazer uma chamada explicita ao plugin, podemos fazer que ele seja executado usando uma chamada client-side. Para fazer isso, existem algumas formas diferentes de se fazer. Vamos a duas abordagens mais utilizadas:

Criar registro em uma entidade customizada para acionar um plugin genérico

Apesar de ainda ser um técnica que pode ser utilizada. Ela era muito mais poderosa quando ainda não tínhamos as Custom Actions (ações de um processo).

A ideia consiste em criar uma nova entidade que funcionará como um orquestrador para o plugin, ou seja, cada vez que um registro for criado neste entidade, um plugin será executado, assim, podemos capturar a ação requisitada (através do contexto e também de atributos da entidade) e realizar a lógica adequada para cada tipo de ação.

Este post não tem o objetivo de explicar tecnicamente como executar esta técnica, porém, este é ótimo artigo para que deseja.

Acionar uma Custom Action  que irá acionar um plugin

 

 

Esta técnica apenas tornou-se possível apenas a partir da versão 2013 do CRM. Faz uso de uma Ação.  Apenas lembrando o objetivo principal de uma ação, que seria, criar ações que um entidade não possui nativamente, possibilitando novos tipos de gatilhos aos processo de negócio.

Além de utilizar um recurso nativo do CRM, tem também a vantagem de necessitar menos codificação do que a técnica anterior. Temos menos etapas de desenvolvimento.

Novamente, o objetivo aqui não é demonstrar como fazer, mas ai vai um artigo com um pouco mais de sofisticação, mas faz uso das Actions!

Bom vamos as respostas das perguntas do Tiago…

– Em resposta a primeira pergunta (se é algo suportado): Sim, completamente suportado.

– Ganhos e perdas, é algo realmente relativo e depende do contexto de utilização, mas vamos lá:

• Prós:
  • Ambas técnicas podem ser muito eficientes em casos onde precisamos acionar um plugin através de algum controle do lado cliente, como um botão do ribbon, recurso web (web resource) e etc. Pois, usando apenas plugins para esse tipo de situação, implicaria em criar um atributo qualquer que seja alterado via JScript, fazendo o formulário ser salvo e enfim executando a regra de negócio que o plugin possui. Porém, mesmo assim, teríamos que desenvolver ainda mais para fazer algo com o retorno da regra de negócio;
  • Utilizando a proposta da primeira técnica (entidade customizada orquestradora), podemos centralizar ao máximo onde as regras de negócio serão executadas;
  • Utilizando a técnica de acionar uma action, temos como grande vantagem a possibilidade de retornar um output do plugin para a action. Tudo de forma nativa! Isso é muito mais poderoso do que apenas chamar um plugin!
• Contras:
  • Quando utilizamos chamadas cliente para acionar algo no servidor (em nosso caso plugins). Iremos criar uma chamada extra de desenvolvimento, ou seja, na verdade nossa regra de negócio está no plugin, mas estamos acionando o plugin pelo cliente. Assim, estamos resolvendo um problema, mas inserindo outro. Pois, sempre existirá a possibilidade de ter que dar manutenção nos dois lados do desenvolvimento;
  • Na primeira técnica (entidade customizada), temos o problema de centralizar demais. Pois, considere uma equipe de desenvolvimento trabalhando em um mesmo plugin sempre! Isso não irá ser fácil…
  • É importante não extrapolar o uso desta técnicas, pois para executar qualquer regra de negócio seja necessário primeiro criar um registro em uma entidade ou invocar uma action. Pense em quando processamento adicional será necessário, além de transformar o plugin em uma espécie de Web Service, se a ideia é essa, crie um Web Services! rs
  • Lembre-se também de cenários onde o CRM será consumido por outra aplicação, provavelmente a chamada para a execução de sua regra de negócio deverá ser impactada;

– Última pergunta (se já utilizei): Não, eu não utilizei, pois ao considerar os contras em relação aos pós a resposta foi o uso de outra abordagem. Porém, já criei serviços customizados para serem chamados através de um botão no ribbon por exemplo. Neste caso, não existia uma regra de negócio que precisasse ficar em um plugin.

Bom, espero ter ajudado a esclarecer algumas dúvidas!

[]’s,

Tiago