GetAttributeValue vs entity.attributes[""]

Entendendo melhor a diferença entre as formas de obtermos informações de um objeto do tipo Entity. Na imagem abaixo, são apresentadas duas formas de obtermos o valor do campo firstname da entidade contato.

Em determinados cenários, o resultado final de ambas será igual, por exemplo, em um create/update onde este campo este foi preenchido e vira preenchido dentro do target. Porém, em determinadas situações, como em um update, onde o campo firstname não foi atualizado, a primeira linha irá gerar uma exceção, pois o objeto contato não possuirá este atributo. Caso estejamos fazendo o uso do método GetAttributeValue<T>("attributeLogicalName"), juntamente com um atributo cujo tipo e nullable, o retorno será null e nenhuma exceção será gerada.

E quando estivermos trabalhando com tipos de atributos non-nullable, como DateTime, int, bool, entre outros? Nestes casos, o próprio método se encarrega de fazer uma tratativa. A primeira linha abaixo é a minha chamada, a segunda linha, é o que de fato (implicitamente) será executado.

O método GetValueOrDefault(), como o próprio nome já diz, retorna o valor do campo e, quando não encontrado, retorna o valor padrão para aquele tipo de atributo.

Um último ponto a ser explorado no método GetValueOrDefault() é referenete a sua sobrecarga, onde você pode passar um valor padrao para sua variável. Continuando o exemplo com o tipo DateTime que se encaixa bem neste cenário. O valor default para data é 01/01/0001. Esta não é uma data válida para as tabelas do CRM. Sabendo disso, poderíamos fazer a tratativa de duas formas.

Primeiramente, usando uma condição para setar um valor padrão para data, caso o valor retornado seja igual a MinValue.

Ou, podemos usar sua sobrecarga e passarmos um valor padrão que, além de evitarmos exceções, diminuem a quantidade de linhas de código.

TIP #1 - OutArgument Workflow Customizado

Workflows customizados são muito úteis, principalmente quando possuem um baixo acoplamento, permitindo que sua lógica seja reaproveitada por outros componentes (Workflows, Real-time Workflows, JavaScript, entre outros).

No código abaixo, temos um workflow customizado bem simples e útil, que retorna o usuário que está executando o workflow, muito usado em cenários de aprovação, onde é preciso popular algum lookup do tipo systemuser com o usuário que está aprovando/reprovando determinado processo.

 

A dica é referente ao retorno do workflow (CurrentUser) do tipo EntityReference. Conhecendo essa classe, sabemos que a mesma possui três propriedades principais (ID, LogicalName e Name), porém quando utilizado como um argumento de saída de um workflow customizado, conseguimos extrair mais informações que apenas as citadas acima. Na verdade, ele se comporta como se estivéssemos retornando um Entity com todos seus atributos.

No imagem abaixo, é possível perceber que quando selecionamos esse parâmetro em um workflow real-time, usado para setar um campo systemuser, obtemos não apenas a referência do usuário, mas sim todos campos de sua tabela.

Como não encontrei nenhuma documentação descrevendo esse comportamento, achei que valeria a pena compartilhar.

Regras de Negocio - Escopo Entidade

Introdução 

As regras de negócio foram introduzidas na versão 2013 do Dyamics CRM, desde então, é possível economizar tempo e complexidade de desenvolvimento fazendo seu uso para substituir alguns comportamentos que, ate então, só eram possíveis com JavaScript.

Até então, só era possível criarmos regras que rodassem apenas no lado do cliente, porém desde a versão 2015 do Dynamics, onde foi introduzido nas regras de negócio mais um tipo de escopo, chamado Entidade, e possível criarmos regras que são executadas tanto no lado do cliente (Client Side) como no lado do servidor (Server Side).

Bem, para muitas pessoas, não está claro o que exatamente isso significa, afinal, a maioria da documentação encontrada cita apenas que as regras também seriam aplicadas na importação de registros.

Procurando ir um pouco mais a fundo e desmistificando esse conceito, procurei um material que me ajudou a compreender melhor os impactos dessa nova funcionalidade.

Explicação

Quando falamos em regras de negócio que serão executadas também no lado do servidor, queremos dizer que, registros importados, criados ou modificados via SDK, também serão afetados, porém alguns comportamentos ainda estão obscuros quando falamos em ações no lado do cliente e no lado do servidor. Para tentar simplificar, iremos listar os resultados de algumas ações em ambos contextos.

• Exibir mensagem de erro: Vamos supor que foi criada uma regra de negócio que, caso o primeiro nome do contato possua a palavra 'estupido', seja exibida uma mensagem de erro dizendo que o primeiro nome não pode conter devida palavra. 
• Client Side: Mensagem definida na regra de negócio apresentada com sucesso.
• Server Side: Quando tentamos incluir um novo registro via SDK, é retornada uma exceção com a mesma mensagem definida na regra de negócio.

• Obrigatoriedade do campo: Caso algum campo seja definido como obrigatório via regra de negócio e o mesmo não seja preenchido no momento da criação:
• Client Side: Mensagem configurada na regra de negocio e apresentada e o usuário e impossibilitado de salvar o registro.
• Server Side: Mensagem configurada na regra de negócio é retornada como exceção no momento na criação do registro.

• Desabilitar campo: Neste cenário, vamos criar uma regra de negócio que bloqueia o campo Sobrenome do contato na criação do registro.
• Client Side: Campo desabilitado, impossibilitando o usuário de inserir alguma informação.
• Server Side: Via SDK conseguimos definir  o campo com o valor desejado e o registro foi criado com sucesso.

Conclusão

Além de entender um pouco melhor como se comportam as regras de negócio configuradas com escopo a nível Entidade, podemos perceber que, em alguns casos, podemos até mesmo substituir workflows e plugins por essa nova funcionalidade.