从Dynamics CRM 2011升级到CRm 2016后遇到形式和插件的奇怪问题

Question

Client company just upgraded to 2016 from 2011. I've been testing the plugins to make sure they all still function and I've finally (after much frustration) figured out what is happening, but no idea why or how to resolve this.

I have several plugins and they all function exactly as expected - as long as the updates to the data are not run through the forms.

Let me explain:

I have plugins (Synchronous) that trigger on a change to a field. If the field is changed via a workflow, or some other coded process, everything runs just fine.

But when I update the field on the form it's self. It fails with a very generic error (below).

I support a couple of other clients already on 2016, and I'm not experiencing this same problem. So I'm not even sure where to begin. I've been going crazy here the last couple of days to check the code. But it only happens when updating the field on the form. Every other method of updating the data that I have tested works with no errors.

I also have another issue. When the field is updated (through a test workflow), it runs and updates a child record. The child record then has a workflow that runs to deactivate the record. The workflow says it ran and deactivated the record, but it never deactivates).

Anyway. if ANYONE has ANY idea at all about what could be causing this. I would love to hear it. I'm at my wits end on this.

Thank you in advance.

I've tested the code and had it run successfully, as long as I don't update the field through the form. To test this I created some test workflows that update the data, they successfully run and the plugins fire off with no problems.

EntityReference contact =    
(EntityReference)preImageEntity.Attributes["ipmahr_contact"];

QueryExpression cn = new QueryExpression("ipmahr_recertification");
cn.ColumnSet = new ColumnSet("ipmahr_contact", "statecode");
cn.Criteria.AddCondition("ipmahr_contact", ConditionOperator.Equal,  
contact.Id);
cn.Criteria.AddCondition("statecode", ConditionOperator.Equal, 0);

EntityCollection results1 = server.RetrieveMultiple(cn);

if (results1.Entities.Count > 0)
     foreach (Entity a in results1.Entities)
     {
      a.Attributes["ipmahr_deactivaterecertificationrecord"] =   true;
         server.Update(a);
     }    

The code is pretty straightforward in most cases, and works fine as long as things aren't updated on the form.

Here is the error: Exception: System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: System.ServiceModel.CommunicationObjectFaultedException: #595EB751 (Fault Detail is equal to Microsoft.Xrm.Sdk.OrganizationServiceFault)., Correlation Id: fd1a79ca-c846-407b-b578-ac9207d6dd0e, Initiating User: 274d55dc-3f4d-e811-b30f-0050569142af Exiting Recertifications.Main.DeactivateUsedRecertificationsonEndDateChange.Execute(), Correlation Id: fd1a79ca-c846-407b-b578-ac9207d6dd0e, Initiating User: 274d55dc-3f4d-e811-b30f-0050569142af

---

New information. I have found that not all the plugins I've written have an issue on this server. This is good. But I also found that there is a commonality on those plugins that do fail.

Any plugin using a Query Expression fails with the generic error. Adding robust error checking didn't show anything (once error checking was added, it just didn't run anything, and didn't produce any errors in the logs). Trace logs didn't show anything significant either.

So now I'm wondering if there is something in the way the Query Expression is formatted, or if there is an issue with the SQL. I mention SQL because I found this morning that if I create fields too fast, I get a generic SQL error. Wait a minute and I can create new fields without a problem.

Answer 1

I think it likely that this plugin is not actually failing based on the error you are receiving and the fact that it happens conditionally. More likely, your server.Update(a); call is resulting in a failure within a secondary plugin or workflow action triggered by update of the Recertification record.
- Comment out that line and verify that the plugin works
- See if you can reproduce a failure by directly updating that field on the Recertification record
- Review plugin/workflows running against the Recertification entity

Most likely this has one of the following root causes:
- A security issue based on different executing users between the form update or workflow update
- Other tangential fields are being updated by one or the other of those two methods which subsequently cause different behavior in a secondary plugin/workflow