Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
When Does the Parent Plugin Context contain the actual Target? RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have a plugin registered on the Post Operation of an Update for a custom Entity, that operates on the Target.  As long as I don't change the StateCode  or StatusCode, it works as expected.  If, however, I send in an Update request that changes the StatusCode, the target contains only these attributes:

    • new_entityId
    • statecode
    • statuscode
    • modifiedon
    • modifiedby
    • modifiedonbehalfby

    But the context's ParentContext contains the actual target I'm expecting, with these attributes:

    • new_entityId
    • new_name
    • statecode
    • statuccode
    • new_skipexport

    I'm assuming this is a bug, but for now, I will work around it by checking for the stage and parent context instead of the current context.  Are there other situations where I need to be checking for the target in the parent context, besides a status/state change?

    Tuesday, April 26, 2016 5:39 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Mystery solved!  I was only ever seeing one plugin because the filtering attributes are honored for the double execution of the plugins!  So from a stage 20 and stage 40 plugin perspective, by default, they are seen as two completely different requests, with different targets.  One target will contain everything but the state and status codes, the other will contain the values listed in my question (id, state, status, modified).  Not sure if it is supported, but I much prefer the idea of grabbing values out of the ParentContext, instead having to register another plugin in stage 10, to "store relevant information"

    It should also be noted, that if the state/status don't actually change from whats in the DB, the Update plugin does not trigger.

    • Marked as answer by Daryl LaBarMVP Wednesday, April 27, 2016 5:49 AM
    Wednesday, April 27, 2016 5:49 AM

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote

    I believe this is by design. Please refer https://msdn.microsoft.com/en-us/library/dn932124.aspx


    Here is the relevant section from the link.

    When update requests are processed that include both state/status fields plus other standard fields, plug-ins registered for the Update message in pipeline stage 20 and/or stage 40 execute once for all non-state/status fields, and then once for the state/status fields.

    In order for plug-in code to receive the full data changes of the update, you must register the plug-in in stage 10 and then store relevant information in SharedVariables in the plug-in context for later plug-ins (in the pipeline) to consume.

    Also as per https://msdn.microsoft.com/en-us/library/microsoft.xrm.sdk.ipluginexecutioncontext.parentcontext.aspx parent context will be populated whenever CRM has to internally generate another request, so in this case it will be SetState with the Update.

    • Edited by NatrajYMVP Tuesday, April 26, 2016 11:17 PM Added note about ParentContext
    Tuesday, April 26, 2016 10:13 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks for the link!  That was very helpful.  The problem is that it isn't entirely true.  

        "plug-ins registered for the Update message in pipeline stage 20 and/or stage 40 execute once for all non-state/status fields, and then once for the state/status fields"

    My plugin registered in stage 40 is only being executed once, not twice.  So now the question becomes, should the documentation change, or is this a bug?

    Wednesday, April 27, 2016 12:26 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Based on my tests, the plugin does fire twice, if the statecode is updated. So the behaviour is as described in the msdn article. I believe Microsoft.Crm.ObjectModel triggers the second update. Below is the profiler screenshot, when I profile the plugin using plugin reg tool.

    Wednesday, April 27, 2016 3:44 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Mystery solved!  I was only ever seeing one plugin because the filtering attributes are honored for the double execution of the plugins!  So from a stage 20 and stage 40 plugin perspective, by default, they are seen as two completely different requests, with different targets.  One target will contain everything but the state and status codes, the other will contain the values listed in my question (id, state, status, modified).  Not sure if it is supported, but I much prefer the idea of grabbing values out of the ParentContext, instead having to register another plugin in stage 10, to "store relevant information"

    It should also be noted, that if the state/status don't actually change from whats in the DB, the Update plugin does not trigger.

    • Marked as answer by Daryl LaBarMVP Wednesday, April 27, 2016 5:49 AM
    Wednesday, April 27, 2016 5:49 AM