【问题标题】:PATCH in Dynamics CRM WebAPI throwing an exception Generic SQL errorDynamics CRM WebAPI 中的 PATCH 引发异常 Generic SQL 错误
【发布时间】:2016-10-25 20:45:00
【问题描述】:

我正在开发一个与 Dynamics CRM Online 2016 对话的应用程序。

我正在为联系人修补一个简单的对象。有效负载看起来像这样 -

PATCH https://<crm_tenant>.crm4.dynamics.com/api/data/v8.1/contacts(00000000-0000-0000-0000-000000000000)
{
  "emailaddress1": "test@emailaddress.com",
  "firstname": "John"
}

这适用于 POSTMAN 或任何其他 REST 客户端。但是,如果我从并行修补大约 34 个联系人(一次 4 个)的应用程序中执行此操作。对于大多数联系人,我都遇到了这个例外 -

{
  "error":{
    "code":"","message":"Generic SQL error.","innererror":{
      "message":"Generic SQL error.","type":"System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]","stacktrace":"   at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.Execute(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode, ExecutionContext executionContext)\r\n   at Microsoft.Crm.Extensibility.OData.CrmODataExecutionContext.Upsert(Entity entity)\r\n   at Microsoft.Crm.Extensibility.OData.CrmODataExecutionContext.Update(Entity entity, UpdateOption updateOption)\r\n   at Microsoft.Crm.Extensibility.OData.CrmODataServiceDataProvider.UpdateEdmEntity(CrmODataExecutionContext context, String edmEntityName, String entityKeyValue, EdmEntityObject entityObject)\r\n   at Microsoft.Crm.Extensibility.OData.EntityController.PatchEntity(String entityName, String key, EdmEntityObject entityDelta)\r\n   at lambda_method(Closure , Object , Object[] )\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.<GetExecutor>b__9(Object instance, Object[] methodParameters)\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments)\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n   at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__0.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n   at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n   at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()"
    }
  }
}

我尝试在互联网上搜索可能的解决方案,但找不到任何解决方案。任何帮助将不胜感激。

拉胡尔。

【问题讨论】:

  • 我知道您说的是在我的许可环境中的在线字节,大多数“通用 SQL 错误”的情况是,遗憾的是...超时。即使实体没有任何插件。更多并发的事情要做,更多的 I/O 饱和,更多的锁,更高的超时概率。
  • 我们怎样才能摆脱它? @笔2?缓慢、受限制的 PATCH 和 POSTS?

标签: dynamics-crm microsoft-dynamics


【解决方案1】:

CRM Online 不允许超过 2 个并发请求

限制并发调用 - 对于 Microsoft Dynamics CRM Online,每个组织限制 2 个并发 ExecuteMultipleRequest 执行。如果超过该限制,则在执行第一个请求之前会引发“服务器忙”错误。对于本地部署,默认情况下不启用限制。此限制的部署设置为 ExecuteAsyncPerOrgMaxConnectionsPerServer。

https://msdn.microsoft.com/en-us/library/jj863631.aspx#limitations

【讨论】:

    【解决方案2】:

    我不确定并行运行是否会导致问题,但如果您想一次更新大量记录,最好使用批处理请求。

    这是文档: https://msdn.microsoft.com/en-us/library/mt607719.aspx

    我发现实现起来有点棘手,因为构建批处理请求对使用正确的格式非常敏感。

    【讨论】:

    • 我不进行批处理的唯一原因是实体生成可能相当复杂。例如我创建了一个联系人,并且可能有另一个实体将联系人作为查找字段。所以我需要在后面的有效载荷中使用contactid。
    • 很好的理由。您是否测试过它是否是由并行运行 PATCH 引起的?我知道当您同时运行某些进程时我会遇到 SQL 异常错误(尽管这些是配置,而不是对记录的更新)。
    • 我删除了并行性,它突然又开始工作了。如果我并行发送请求,则某些请求会因此异常而失败。这很可悲。错误应该是优雅的
    • 我同意,如果你真的想要性能,你可能想要做一个批处理并解析响应以从中获取联系人 ID。但这是一些严肃的文本解析。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-05-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多