{"id":1276,"date":"2015-05-11T12:41:29","date_gmt":"2015-05-11T07:11:29","guid":{"rendered":"https:\/\/www.inogic.com\/blog\/?p=1276"},"modified":"2015-05-11T12:41:29","modified_gmt":"2015-05-11T07:11:29","slug":"api-enhancement-service-update-message-in-crm-2015-update-1","status":"publish","type":"post","link":"https:\/\/www.inogic.com\/blog\/2015\/05\/api-enhancement-service-update-message-in-crm-2015-update-1\/","title":{"rendered":"API enhancement \u2013 Service.Update Message in CRM 2015 Update 1"},"content":{"rendered":"

Introduction:
\n<\/strong><\/span><\/p>\n

For updating an existing record in Dynamics CRM, we have always had the Service.Update message. Pass in the entity object and it would update the corresponding record back in CRM. This message however only allowed you to update regular fields. CRM has always had some special fields like Status, Owner etc that could not be updated using the Update Message. These had special messages in the SDK to update the values.<\/p>\n

To update Owner, use Assign request<\/p>\n

To update Status, use the SetState request.<\/p>\n

In this current release, the API has been update, to remove the need to execute special messages for Status and Owner and instead we can now update these by setting these fields and passing them as a part of the Update request to CRM.<\/p>\n

Code Sample differences:
\n<\/strong><\/span><\/p>\n

Updating the rating, the Owner and the status of the contact record in Dynamics CRM
\n<\/strong><\/span><\/p>\n

Entity contact = new Entity();
\n<\/span><\/p>\n

 <\/p>\n

\/\/specify the entity logical name
\n<\/span><\/p>\n

contact.LogicalName = “contact”;
\n<\/span><\/p>\n

 <\/p>\n

\/\/specify the contact that need to be updated
\n<\/span><\/p>\n

contact.Id = new Guid(“A925C42D-CFE4-E411-80E8-C4346BAD5414”);
\n<\/span><\/p>\n

 <\/p>\n

\/\/Set the fax field<\/p>\n

contact[“fax”] = “412”;
\n<\/span><\/p>\n

 <\/p>\n

\/\/Call the update message<\/p>\n

service.Update(contact);<\/span>
\n<\/span><\/p>\n

\/\/Call the Assign to change the owner<\/p>\n

AssignRequest assign = new AssignRequest<\/p>\n

{<\/p>\n

Assignee = new EntityReference(SystemUser.EntityLogicalName, _otherUserId),<\/p>\n

Target = new EntityReference(Contact.EntityLogicalName,new Guid(“A925C42D-CFE4-E411-80E8-C4346BAD5414”)<\/span>)<\/p>\n

};<\/p>\n

\/\/ Execute the Request<\/p>\n

_service.Execute(assign);<\/p>\n

\/\/Now change the status<\/p>\n

\/\/ Create the Request Object<\/p>\n

SetStateRequest state = new SetStateRequest();<\/p>\n

EntityReference contactReference = new EntityReference()<\/p>\n

{<\/p>\n

LogicalName = Contact.EntityLogicalName,<\/p>\n

Id = new Guid(“A925C42D-CFE4-E411-80E8-C4346BAD5414”)<\/span><\/p>\n

};<\/p>\n

state.EntityMoniker = contactReference<\/p>\n

\/\/ Set the Request Object’s Properties<\/p>\n

state.State = new OptionSetValue(1);<\/p>\n

state.Status = new OptionSetValue(2);<\/p>\n

 <\/p>\n

\/\/ Execute the Request<\/p>\n

_service.Execute(state);<\/p>\n

 <\/p>\n

As you can see, it took 3 separate request to get these 3 fields updated.<\/p>\n

With the new API you can simply perform all of these three with a single Update request<\/p>\n

Entity contact = new Entity();
\n<\/span><\/p>\n

 <\/p>\n

\/\/specify the entity logical name
\n<\/span><\/p>\n

contact.LogicalName = “contact”;
\n<\/span><\/p>\n

 <\/p>\n

\/\/specify the contact that need to be updated
\n<\/span><\/p>\n

contact.Id = new Guid(“A925C42D-CFE4-E411-80E8-C4346BAD5414”);
\n<\/span><\/p>\n

 <\/p>\n

\/\/set the fax
\n<\/span><\/p>\n

contact[“fax”] = “412”;
\n<\/span><\/p>\n

\/\/change the owner of the contact
\n<\/span><\/p>\n

contact[“ownerid”] = new EntityReference(“systemuser”, new Guid(“FB8C44BF-B0E9-E411-80ED-C4346BAD5414”));
\n<\/span><\/p>\n

 <\/p>\n

\/\/change the status to inactive
\n<\/span><\/p>\n

contact[“statecode”] = new OptionSetValue(1);
\n<\/span><\/p>\n

 <\/p>\n

\/\/change the state to inactive
\n<\/span><\/p>\n

contact[“statuscode”] = new OptionSetValue(2);
\n<\/span><\/p>\n

 <\/p>\n

\/\/update the contact
\n<\/span><\/p>\n

service.Update(contact);<\/span>
\n<\/span><\/p>\n

 <\/p>\n

Impact on Plugins:
\n<\/strong><\/span><\/p>\n

The SetState and Assign request have always called the Update request also internally. This means, if you had a plugin registered on SetState, Assign and Update message of the “Contact” entity. The sample code above would have executed the SetState and Update, both plugins for just the SetState request. Similarly the Assign would have executed the plugin registered on both Assign as well as Update message. So it was the Update message that was executed irrespective of which fields or through which message a record was updated in Dynamics CRM.<\/p>\n

The new API Update message, will not internally execute the SetState or Assign request if you were to execute the above sample code to update the owner and the status. So any previous plugins registered on the SetState or the Assign request will be have to re-registered on the Update message, should you plan to start using the new Update message to update the owner and status as well.<\/p>\n

When you change the owner or the state of the record from CRM UI, it still executes the SetState and Assign Plugin, so it does not impact there.<\/p>\n

The new API would not execute the SetState or Assign message plugin, BUT, it will call an UPDATE request for each of these messages i.e the sample code above would result in the UPDATE plugin being executed thrice.<\/p>\n

1st<\/sup> time for the updating Fax \u2013 This time, the target would receive only the Fax field (non-owner\/non-status fields)<\/p>\n

2nd<\/sup> time for the Owner \u2013 only the owner field is available in Target<\/p>\n

3rd<\/sup> time for the state \u2013 This time only status fields are passed in Target.<\/p>\n

The following sample plugin code, would help you understand how to identify for which field the plugin has been triggered.<\/p>\n

\/\/ Check if plugin context contains the Target<\/p>\n

if (context.InputParameters.ContainsKey(“Target”))<\/p>\n

{<\/p>\n

Entity targetContactEntity = (Entity)context.InputParameters[“Target”];<\/p>\n

string desc = “”;<\/p>\n

if (targetContactEntity!= null)<\/p>\n

{<\/p>\n

\/\/ When fired for owner change<\/p>\n

if (targetContactEntity.Attributes.ContainsKey(“ownerid”))<\/p>\n

{<\/p>\n

desc = “Owner changed”;<\/p>\n

}<\/p>\n

\/\/ When fired for status change<\/p>\n

if (targetContactEntity.Attributes.ContainsKey(“statecode”))<\/p>\n

{<\/p>\n

desc = “Status Changed”;<\/p>\n

}<\/p>\n

\/\/ Create Task activity<\/p>\n

Entity task = new Entity(“task”);<\/p>\n

task[“subject”] = “Task from plugin : ” + desc;<\/p>\n

_service.Create(task);<\/p>\n

}<\/p>\n

}<\/p>\n

 <\/p>\n

    \n
  1. Once for all non -owner \/ non-status fields i.e. “fax” \u2013 When fired for rest of these fields the target entity attribute does not contain “owner” and “statecode”. Hence the “Task” which we are creating in this plug-in is created with subject \u2013 “Task from plug-in”.<\/li>\n
  2. Once for owner field change \u2013 When fired for owner field the target entity attribute will only contain updated owner field. So here we can find out if the plug-in has been fired for owner field change by checking for if the target entity attribute contains “ownerid” as done in above plug-in code. Hence the “Task” is created with subject \u2013 “Task from plug-in : Owner changed”.<\/li>\n
  3. \n
    Once for Status field change – When fired for status field the target entity attribute will only contain updated status field. So here we can find out if the plug-in has been fired for status field change by checking for if the target entity attribute contains “statecode” as done in above plug-in code. Hence the “Task” is created with subject \u2013 “Task from plug-in : Status changed”.<\/div>\n

     <\/li>\n<\/ol>\n

    So total 3 tasks will be created on single update request executed in the sample code above. The depth each time would be 1.<\/p>\n

    Impact on Workflow<\/strong>:<\/p>\n

      \n
    1. Workflows registered for the Assign<\/strong> message by users continue to be triggered by updates to owner fields.<\/li>\n
    2. Workflows containing the Change Status<\/strong> step continue to be triggered by updates to state\/status fields.<\/li>\n<\/ol>\n

      For example<\/strong>:<\/p>\n

      If you have a workflow registered to execute when a record is assigned, updating the owner of the record using “Update<\/strong>” operation would trigger the workflow. Similarly for the Status changes workflow, they are triggered as well when the state is changed using the new Update message.<\/p>\n

      Conclusion:
      \n<\/strong><\/span><\/p>\n