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…

crmprepost

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:

Funcionalidades Pre-Validation Pre-Operation Post-Operation
Executado antes das validações internas do CRM X X
Está fora do contexto de transação com o banco de dados X
O registro já está “commitado” no banco de dados X
Possui os atributos do sistema no contexto: createdon, createdby, modifiedon, modifiedby, etc X
Os direitos de acesso do usuário são validados durante a execução X X
Gerenciar os valores de contexto sem a necessidade de interação com os objetos do SDK que realizam “commits” no banco de dados. Por exemplo: Não precisamos atualizar o registro de contexto caso necessitarmos de adicionar uma nova propriedade no objeto de contexto X X
Podemos realacionar o registro de contexto com qualquer outro registro. Por exemplo: Criar e relacionar uma tarefa na conta que está sendo criada X

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

Anúncios

Sobre Tiago Michelini Cardoso

I have been working with IT since 2006, almost of this time using Microsoft Dynamics CRM/365 as a source of solutions. I graduated in Bachelor of Information Systems at FIAP (Brazil) in 2012. I really love what I do! Technology has been my interest since always. Even in a tool different world of the current. When we didn't have internet, tablets, smartphones e social networks! Although I have worked in some roles, I can't give up "the developer life". Even so far of the greatest developers. Development in general is the thing that I love to work! I started my contributions about Dynamics in 2010. At the beginning, I used to help at MSDN and TechNet forums. But now, I'm dedicating all my time in my personal blog! Currently, I have the enormous honour of being the only Brazilian who got the award for Microsoft MVP (Most Valuable Professional) for Microsoft Dynamics CRM/365 product. I have been receiving the award since 2012.
Esse post foi publicado em Dynamics CRM e marcado , , , , , , , . Guardar link permanente.

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

  1. Tiago, no caso do Pre-Validation o codigo que você citou seria para inibir a criação da oportunidade na qualificação do lead? se sim em que message ele roda no Update?
    Desde já obrigado pelos conteudos que você posta ajudam muito a comunidade.

    Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s