Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
In the example code given by microsoft in followup plugin (link below)
there is a code line which tries to attach account as regardingobject to the task which will be created.
Guid regardingobjectid = new Guid(context.OutputParameters["id"].ToString());Why is that Output parameters are used to get the ID of the initiating entity when you canget it easily by entity.Id from Target.Thanks.
Not sure without testing, but because this is a plug-in to be executed on create of account, it's possible the id would not exist yet. The create output is a new account with an id. If this were a workflow activity the account would likely exists depending on how the workflow is called. Again, not sure without testing though.
The OutputParameters will contain the Response object properties - so for a Create Request, it will contain the Create Response properties - which is why it contains the id property that will be returned by the platform - msdn.microsoft.com/.../microsoft.xrm.sdk.messages.createresponse.id.aspx
For more information see msdn.microsoft.com/.../gg309673.aspx
Hope this answers your question!
Do you need any more help from Tom or I?
Just wanted to verify my understanding regarding this.
Scenario : A plugin is written on Create message of a entity A. Through this plugin I would like to add a task and attach it to the created entity record. So I will need the ID of the created record.
According to your explanation, for a create message, id is found in output parameters as it is a response object but not in input parameters.
I tried getting entity.PrimaryEntityID in the same context. Below are the results.
context.PrimaryEntityId : d736d2f5-c92b-e611-80ca-448a5bb3f17f
(context.OutputParameters["id"].ToString()) ---> d736d2f5-c92b-e611-80ca-448a5bb3f17f
My question still remains the same. Why does the official microsoft code get id from outputparameters when you can easily get from context.PrimaryEntityId in general. Is it due to any performance enhancement?
Look into my reply above.
Additionally, Tom and Scott
i have got the id from both ways, interested in knowing the recommended way and why.
I observed while debugging that, entity on which I have registered the plugin won't be created when I am running a profiler. Post create plugin error will restrict from creating the record ? Can we say this.
The OutputParameters["id"] will only be populated on the Post Pipeline stage - it isn't present in the Pre stage. I think the SDK sample is using the id because it's intended to be registered at the Post stage and the OutputParameters are immutable and so will always give you what was applied in the transaction.
There isn't any performance gain over the context.PrimaryEntityId or indeed ((Entity)InputParameters("Target")).Id - they would all return normally the same.
Hope this answers your question?
Business Applications communities