WCF, JSON, Dynamics CRM - Uma mistura interessante.

Olá Pessoas,

Atualmente quando analiso desenvolvimentos para o MS CRM vejo uma tendência muito grande dos desenvolvedores acreditarem que XML e ASP.NET Web Services são os únicos recursos para um acesso remoto aos Serviços do CRM, quando estamos customizando um Formulário ou um botão ISV via Java Script.

Contudo se analisarmos o cenário mais friamente chegaremos a conclusão de que nem XML, muito menos Web Services serão a melhor solução quando estamos pensando em ganhos de desempenho (por conta do empacotamento e envio destes formatos que causam um overhead considerável no tráfego da rede), muito menos simplicidade na arquitetura, porque certamente você precisará pensar uma camada só para tratar o retorno de chamadas que são realizadas através de Java Script, a fim de manipular os dados no formato XML, que convenhamos, dá uma baita dor de cabeça quando temos cenários mais complexos de envio e recebimento de informações.

Algumas das alternativas para sanar problemas como os citados acima são o WCF e o formato JSON que, juntos, aliam ganho de performance e maior simplicidade no design na aplicação.

Abaixo segue um exemplo da utilização destes dois recursos:

Importante: Estou considerando neste exemplo que você já possui os conhecimentos de como criar um projeto WCF, publicá-lo para acesso através de HTTP e referenciar o SDK do Microsoft Dynamics CRM ao seu projeto.

1. Definição do contrato do Serviço

[ServiceContract]
public interface IClienteService {

[OperationContract]
account Obter(Guid accountId);

}

2. Implementação do contrato

public class ClienteService : IClienteService {

public account Obter(Guid accountId) {

// return CrmService.Retrieve("account", accountId, new AllColumns());
}

}

3. Arquivo de configuração do Serviço

4. Configuração da chamada Java Script

var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");

// Informando o caminho do serviço e o métod que será executado
var url = http://localhost:1700/ClienteService.svc/Obter;

// Configuração no formato JSON
var accountId = '{"accountId":"' + '{6f5cfcf2-ba2d-481c-bd85-5c03ba8a652d}' + '"}';

xmlHttp.open("POST", url, false);
xmlHttp.setRequestHeader("Content-type", "application/json; charset=utf-8");
xmlHttp.setRequestHeader("Content-Length", data.length);
xmlHttp.send(accountId);

// Método que disparado após a execução da pesquisa
xmlHttp.onreadystatechange = function() {
if (xmlHttp.readyState == 4) {

var account = eval('(' + xmlHttp.responseText + ')').d;

alert(account.accountid.Value);
alert(account.name);
}
}

No exemplo acima estamos fazendo uma consulta a base do MS CRM utilizando como "Proxy" um serviço WCF que expõe um tipo complexo do MS CRM, sem a necessidade de se criar uma camada adicional para tratar o retorno do MS CRM para um tipo qualquer, como XML, por exemplo.

Já no lado Client, fica claro que a configuração da pesquisa ficou muito mais simplificada. Além disto, devido a utilização do formato JSON podemos trabalhar com o objeto "account" da mesma forma se estivessemos manipulando este objeto no C#.

Um outro aspecto importante é quanto ao desempenho desta chamada, pois não se fez necessário o empacotamento no protocolo SOAP, livrando-nos assim de uma quantidade excessiva de tags XML. Neste caso as únicas informações submetidas são o valor -- {"accountId":"{6f5cfcf2-ba2d-481c-bd85-5c03ba8a652d}"}--, que está no formato requirido pelo padrão JSON, e os valores de Content-Type e Content-Length adicionados ao Header da requisição.

Como vimos com WCF e JSON podemos criar uma mistura no mínimo interessante como alternativa aos famigerados Web Services e XML no acesso as informações, via JavaScript, dentro da plataforma Dynamics CRM.

[]'s

Ricardo Cunha

Dependecy Injection no MS CRM

Olá Pessoas,

Desde muito tempo sou amante dos Design Patterns e, por conta disto, sempre que tenho contato com uma aplicação de software tento de alguma maneira identificá-los para aperfeiçoar cada vez mais meus conhecimentos quanto a suas aplicações.

Quando desenvolvemos para o Microsoft Dynamics CRM temos acesso há um Pattern chamado Dependecy Injection que é extremamente útil e complexo, mas que, na maioria dos casos, os desenvolvedores nem sabem que estão utilizando tal conceito. Claro que na prática isto não importa muito, mas para nosso crescimento e aperfeiçoamento como desenvolvedores ter o conhecimento de tal mecanismo, ao menos na minha ótica, pode ser fundamental.

O Pattern Dependecy Injection, como o próprio nome sugere, permite que você injete uma dependência dinâmica a sua aplicação, a fim de prover uma certa "inversão de controle", pois esta "dependência externa" pode alterar completamente o comportamento do seu sistema.

No Microsoft Dynamics CRM nós vemos a implementação deste pattern através do mecanismo de Plug-ins.

Quando implementamos a interface IPlugin estamos criando a dependência externa citada na definição do pattern.

Veja o Exemplo Abaixo:

namespace MyPlugins {

public class PluginImplementation : IPlugin {

public void Execute(IPluginExecutionContext context) {
// implementação do seu método;
}
}
}

Após implementar a classe acima e registrá-la no MS CRM o PluginRegistration Tool encarrega-se de criar os registros nas tabelas PluginAssemblyBase, para armazenar o nome do assembly gerado "MyPlugins.dll", e na tabela PluginTypeBase, para armazenar o caminho completo até a classe que implementa a interface IPlugin, no nosso caso MyPlugins.PluginImplementation.

Após a pesquisa dos dados do assembly que você registrou no banco de dados será executado no kernel do MS CRM um trecho de código conforme apresentado nas linhas abaixo:

// O código abaixo executado pelo kernel do MS CRM.

// Criando a instância do plugin registrado pela ferramenta.
IPlugin plugin = (IPlugin) Assembly.Load("MyPlugin.dll").CreateInstance("MyPlugin.PluginImplementation");

// Disparando o método Execute da classe PluginImplementation, criado por você.
plugin.Execute("Instância da interface IPluginExecutionContext");

Com isto temos a "inversão de controle", conforme citado anteriormente, pois neste momento a execução do método "Execute()", que ocorre no kernel do MS CRM, passa a estar totalmente sob seu controle e assim vemos a utilização do pattern Dependency Inection. Simples não é?

Um outra arquitetura que explora muito este pattern e o próprio ASP.NET, aonde temos a possibilidade de fazer inúmeras configurações no web.config e machine.config, como HttpModules, HttpHandler, MembershipProvider, etc.


Se analisarmos bem estamos cercados pelos Design Patterns, só precisamos estar atentos para identificar suas vantagens e a partir daí utilizá-los da melhor forma possível em nossas aplicações.


[]'s


Ricardo Cunha

D.Net Framework

Salve Pessoas!


Há algumas semanas atrás conheci o Guilherme Bacellar, brother que trabalha com .Net e está em parceria conosco em um projeto de integração com CRM.

Conversando com ele descobri que também é adepto do CSLA e atualmente está liderando um projeto no Code Plex chamado D.NET.

Vale a pena dar uma olhada.

Abraços!