从拥有的案例中检索开放活动的数量
我有许多案例详细信息实体，这些实体根据类型都有不同的案例解决方案。选择案例解决类型后，我可以使详细信息表单处于非活动状态，并调用子工作流程来解决所属案例。但是，如果拥有案件有公开活动，那么当然不会得到解决。有没有一种方法可以从拥有的案例中检索开放活动的数量，从而在我的工作流程中使用。
I have a number of case detail entities which all have different case resolutions dependent on the type. On selection of a case resolution type I can make the detail form inactive and call a child workflow to make the owning case resolved. However if the owning case has open activities then of course it will not be resolved. Is there a way I can retrieve the number of open activities from an owning case and therefore use in my workflow.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
工作流不支持聚合函数（例如计数），因此您需要添加一些逻辑来维护父案例上未完成活动的计数。我能想到的保持案例活动计数的最佳方法是编写一个插件，该插件在活动的创建后/更改状态后/删除前运行，检查它们是否与案例相关，如果是的话，向 CRM Web 服务发出 RetrieveMultiple 请求以计算属于父案例的活动总数，然后使用活动总数更新父案例上的自定义活动计数字段（通过 Web 服务）。
完成此操作后，您将能够在案例工作流程中使用父案例活动计数。这样做会导致性能下降，因为 Web 服务调用需要一点时间，尤其是在删除操作上，因为它们必须在删除发生之前同步运行。删除可能不会很常见，因为您可能想要跟踪已关闭的活动。根据您的需要，您可能可以将后期插件设置为异步运行，并且您不会看到这些插件的直接性能影响，但您必须等待异步插件触发，就像工作流程一样。如果设计得当，您可以通过一个插件完成所有这一切，只需 3 个步骤（每个事件 1 个步骤）。
Workflow doesn't support aggregate functions such as count so you would need to add some logic to maintain a count of open activities on the parent case. The best way I can think of to maintain the activity count on the case would be to write a plugin that runs on post-create/post-changestate/pre-delete of activities that checks to see if they are regarding a case and if so, does a RetrieveMultiple request to the CRM web services to count the number of total activities that belong to the parent case, then update a custom activity count field on the parent case (via web services) with the total number of activities.
Once you have done that you will be able to use the parent cases activity count in your case workflows. You will incur a performance hit with this since the web service calls will require a little time, especially on the deletes since they must run synchronously prior to the delete occurring. It is likely that deletes will not occur very commonly since you probably want to track your closed activities. Depending on your needs you can probably set up the post plugins to run asynchronously and you will not see a direct performance hit for those, but you will have to wait for the async plugins to fire much like workflows. If designed right you can accomplish all of this with one plugin, with 3 steps (1 for each event).