CRM – Estágios dos Eventos Pre e Post (Pre-Validation, Pre-Operation e Post-Operation)

Pessoal,

Há muito tempo atrás eu fiz este post Pre-Event e Post-Event, ao relê-lo hoje percebo que faltou um maior detalhamento.Vou tentar fazer isso desta vez…

Plugins desde a versão 2011 do CRM possuem quatro diferentes estágios nos eventos Pre e Post:

• Pre-Validation
• Pre-Operation
• MainOperation (uso exclusivo das funções core do CRM)
• Post-Operation

Temos o artigo oficial para detalhar cada estágio. Porém vou fazer minhas anotações.

Construi uma tabela para facilitar o entendimento de cada estágio:

Os detalhes de cada estágio podem ser visualizados abaixo:

Pre-Validation

Acredito que seja o estágio que exista menos material e informações à respeito, porém possui algumas vantagens interessantes.

• É executado antes das validações internas do CRM e está fora da transação com o banco de dados;
• Não temos o registro já “commitado” no banco de dados;
• Não possui os atributos do sistema no contexto: createdon, createdby, modifiedon, modifiedby, etc;
• O perfil do usuário não é validado, assim todos os usuários conseguirão executar o plugin neste estágio (IMPORTANTE: quando digo que o perfil de acesso não é validado, quero dizer não é validado para controlar os objetos que existem no “InputParameters”, nós podemos atualizar estas informações. Já quando estamos utilizando o SDK para realizar operações como por exemplo as operações CRUD, o perfil de acesso será validado, se o usuário não tiver acesso receberemos uma exceção);
• Para facilitar a compreensão do Pre-Validation, podemos atrelar seu significado quando necessitamos alterar alguma função nativa (de forma suportada), recuperamos o contexto e alterar suas propriedades. Como é o caso da Qualificação de um Cliente Potencial, atualmente automaticamente, ao qualificar um cliente potencial o CRM cria um contato, uma conta e uma oportunidade. Em alguns processos de vendas não é necessário um ou mais destes processos nativos, podemos desativá-los utilizando um plugin, como no exemplo abaixo:

if (context.InputParameters.Contains("LeadId") && context.InputParameters["LeadId"] is EntityReference)
{
EntityReference leadReference = (EntityReference)context.InputParameters["LeadId"];
Guid leadId = leadReference.Id;

context.InputParameters["CreateContact"] = false;
context.InputParameters["CreateAccount"] = true;
context.InputParameters["CreateOpportunity"] = true;
}

Pre-Operation

• É executado antes as validações internas do CRM, mas está dentro da transação com o banco de dados;
• Não temos o registro já “commitado” no banco de dados;
• Não possui os atributos do sistema no contexto: createdon, createdby, modifiedon, modifiedby, etc;
• O perfil do usuário é validado para qualquer operação que desejamos realizar;
• Podemos gerenciar todo o contexto que é passado (InputParameters) sem que seja necessário uma nova transação com o banco de dados. Por exemplo, desejamos adicionar a inicial “Sr ou Sra” ao nome de um contato, podemos verificar o atributo “Sexo” e adicionarmos no “firstname” do contato. Não precisamos dar um “Update” no registro atual, e sim adicionar a informação. Vejam:

string inicial = string.Empty;

// Masculino
if ((bool)contato["ATRIBUTO_SEXO"])
{
    inicial = "Sr. ";
}
// Feminino
else
{
    inicial = "Sra. ";
}

// Concatena a inicial ao nome
contato["firstname"] = inicial + contato["firstname"]; // Não é preciso mais nada, como um service.Update(contato), pois, o CRM ainda irá commitar o registro na base, podemos manipular apenas o contexto

Post-Operation

Além de ser o selecionado por padrão, acredito que é o estágio mais utilizado pelos desenvolvedores CRM, pois temos a vantagem do registro já estar na base de dados:

• É executado depois das validações internas do CRM e está dentro da transação com o banco de dados;
• Temos o registro “commitado” no banco de dados;
• Possui todos os atributos do sistema no contexto: createdon, createdby, modifiedon, modifiedby, etc. Só para termos uma ideia, na criação de um cliente potencial, como apenas o Tópico e Nome preenchidos temos 41 atributos dentro do objeto “Target”, contra 30 nos estágios Pre;
• O perfil do usuário é validado para qualquer operação que desejamos realizar;
• Devido o registro já ter sido commitado na base de dados, podemos recuperar seu id do contexto e realizar relacionamentos com outras entidades. O exemplo abaixo, recupera o id de um cliente potencial do contexto e cria um tarefa relacionando o cliente potencial:

Entity entity = (Entity)context.InputParameters["Target"];

Entity tarefa = new Entity("task");
tarefa["regardingobjectid"] = entity.ToEntityReference(); // EntityReference do Lead de contexto
tarefa["subject"] = "Tarefa criada no estágio Post";

service.Create(tarefa);

Bom acredito que tenha atingido minha ideia de detalhar um pouco mais desta vez, para  cada estágio de plugin e por que utilizá-lo!

[]’s,

Tiago Cardoso