Diferenças na criação de instâncias do CrmService (Microsoft Dynamics CRM 4.0)
Os plug-ins em CRM 4.0 são executados sob a conta de segurança responsável pela Application Pool do CRM no IIS.
Por defeito, a conta usada é o Network Service (Serviço de Rede).
É bastante comum usar a seguinte linha para instanciar o serviço:
ICrmService service = context.CreateCrmService(true);
Mas quais as verdadeiras implicações do parâmetro que é passado para o método CreateCrmService?
Imaginemos o cenário em que temos vários plug-ins encadeados (em que o primeiro plug-in causa a execução dos seguintes).
Nesse caso, o que este parâmetro significa é que para o primeiro plug-in, que será lançado na Parent Pipeline de execução após uma acção do utilizador, não veremos nada de anormal, ou seja, no exemplo desse plug-in criar um objecto no CRM, o campo Owner será o utilizador que causou a execução. Mas, para os restantes plug-ins, causados pelo primeiro e lançados na Child Pipeline, o contexto de execução será completamente diferente.
Se nesta situação os seguintes plug-ins procederem à criação ou actualização de objectos no CRM, veremos que o Owner já não será o utilizador que causou a execução do primeiro plug-in.
Por defeito, a plataforma de CRM passa para o plug-in em runtime o id do utlizador, através da propriedade IPluginExecutionContext.UserId. Esta propriedade pode ter um dos três valores seguintes:
UserId Value |
Condition |
Initiating user or "system" user |
The impersonatinguserid property of the sdkmessageprocessingstep or SdkMessageProcessingStepRegistration class instance is set to null or Guid.Empty at plug-in registration. |
Impersonated user |
The impersonatinguserid property is set to a valid system user ID at plug-in registration. |
"system" user |
The current pipeline was executed by the platform, not in direct response to a Web service method call. |
No caso de se passar “true” como parâmetro, o valor que estiver na propriedade IPluginExecutionContext.UserId será usada nas acções que requerem um utilizador (como no caso do Owner se tentarmos criar um objecto).
É, portanto, equivalente a usarmos:
ICrmService service = context.CreateCrmService(context.UserId);
No caso de passarmos “false” como argumento, a plataforma de CRM irá usar o “SYSTEM” como utilizador nas suas operações e nas interacções com o web service. A conta de “SYSTEM” tem privilégios elevados mas também algumas condicionantes, como por exemplo o facto de não conseguir criar Tarefas.
No cenário em que tenhamos vários plug-ins encadeados e o objectivo seja que o contexto do utilizador se mantenha, a opção mais indicada é então a de passar como argumento para o método CreateCrmService o InitiatingUserId, o que vai fazer com que se mantenha para todos os plug-ins na mesma execução a identidade do utilizador que despoletou o primeiro dos plug-ins:
ICrmService service = context.CreateCrmService(context.InitiatingUserId);
Por fim, se tivermos vários métodos dentro da mesma classe IPlugin, podemos usar a propriedade IPluginExecutionContext.InvocationSource para identificarmos se estamos a executar um determinado método na Parent ou na Child pipeline:
public virtual int InvocationSource {get;}
Property Value
The value of this property is an Int32 type.
Toda esta informação pode ser consultada no SDK do CRM:
A versão actual é a 4.0.13.
André Mestre
Este post é publicado “AS IS” sem garantias e não confere nenhum direito.