插件仅在实体 /表x中的多个记录的创建 /更新时触发一次
我们有一个拥有3种类型的记录A，B，C的实体。记录A类型A是B的父（每个A可以是多个B记录的父），而进一步的B是C的父（每个B可以是父母到多个C记录）。在每个记录C的创建 /更新时，计算商业插件将运行，该插件将在给定的记录B下将所有兄弟姐妹C记录拉开，并汇总 /汇总总计，并使用这些滚动总和 /总计更新该父记录B。在B唱片总数的更新中也会发生同样的事情，这将使总计将纪录列入纪录。这里的问题是，当我们在给定父母B下创建/更新多个C记录时，这将触发多个计算商业插件实例，这有点效率低下＆amp;资源密集型。是否有更好的方法让计算商业只有在创建 /更新的C记录数量的数量中触发一次？
例如，如果我们在给定时间创建 /更新10 C记录，我们希望CarculatEcmercials插件仅运行一次，这将总计将总数汇总到B，而不是一次更新A，而不是10次（当前它的触发10计算商业插件实例将汇总到B，该插件汇总为B，该插件又触发了另外10个实例，以更新Grand Parent Record type C）。
有时，这条自动训练链导致插件实例超过2分钟的时间限制。是否有更好的方法可以简化对父b的总计滚动，然后再升级为A？
We have an entity which holds 3 types of Records A, B, C. Record type A is the parent of B (each A can be the parent to multiple B records) and further B is the parent of C (each B can be the parent to multiple C records). On creation / update of every record C, CalculateCommercials plugin will run that will pull all the sibling C records under a given record B and aggregate / roll-up the totals and update that parent record B with those rolled-up sum / totals. Same thing happens on update of B record totals which will roll-up the totals to grand-parent A record. The problem here is, when we create/update multiple C records under a given parent B this will trigger multiple CalculateCommercials plugin instances which is a bit inefficient & resource intensive. Is there a better approach where we let the CalculateCommercials to trigger only once irrespective of the number of C records being created / updated?
For example, if we create / update 10 C records at a given time we want the CalculateCommercials plugin to run only once which will roll-up the totals to B and again only once to update A, instead of 10 times (currently its triggering 10 CalculateCommercials plugin instances to roll-up to B, which in-turn trigger another 10 more instances to update grand-parent record type C).
Sometimes this chain of auto-triggers resulting in the exceeding of 2 minute time limit for the plugin instance. Is there a better approach to simplify the rolling up of totals to parent B and then on to A?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
很大程度上取决于如何使用汇总字段及其一致性要求。
最简单的方法是计划最终的一致性而不是严格的一致性。更新的孙子插件只会标记孙子实体中的“肮脏”字段，这不需要额外的DB锁定。另外，预定的工作流程或电源自动材料流每分钟每分钟都运行，从而找到所有肮脏的孙子，更新父母的滚动场并重置肮脏的场。因为该工作流程是安排的，并且在汇总字段上没有其他任何写作锁，所以对父母和祖父母记录几乎没有争议。但是，这意味着，如果孙子们不断变化，汇总值总是过时的几分钟。
D365似乎实现了一个“汇总字段”概念，该概念完全可以做到这一点： https://www.encorebusiness.com/blog/rollup-fields-in-microsoft-dynamics-365-crm/ 默认情况下，计划的任务每小时都可以通过管理员进行配置，但是可以由管理员配置。
为了提高更新延迟，您可以通过对相关孙子字段的更新进行按需流程或触发，但请检查＆amp;更新一个“流量已经触发”表，以确保多个流量实例不会同时尝试更新。该流的“获胜”实例设置了“运行”标志，重复循环直到发现不再肮脏的记录，然后清除“运行”标志。当他们看到另一个实例处于活动状态时，“丢失”实例立即终止。
这种模式需要更多的护理来处理与记录相关的潜在种族条件，该记录在清除运行标志后被标记为脏，以及可能在流动完成之前终止流量的瞬态错误。同样，一个简单的解决方案是安排每小时一次或一天的“清扫”实例。
如果您需要严格保持一致，那么此白皮书可能会有所帮助： https://download.microsoft.com/download/6/6/d66/d661ba-3d18-3d18-49e8-b042-8434e644e64fafca/scalabledynamicsccrmcustomicscrmcustomizations.docx 插件的各种锁定和注册选项。
如果很少消耗汇总字段，则只有在客户读取该实体或祖父母实体时，使用这些实体上的单独插件在阅读父或祖父母实体时，才能更有效地重新计算该字段。您需要确保客户不要求该字段，除非他们需要。
A lot depends upon how the rollup fields are used, and their consistency requirements.
Simplest approach is to plan for eventual consistency rather than strict consistency. The update-grandchild plugin would merely mark a "dirty" field in the grandchild entity, which requires no additional DB locking. Separately, a scheduled workflow or Power Automate flow runs every 'N' minutes, which finds all the dirty grandchildren, updates their parents' rollup fields, and resets the dirty fields. Because this workflow is scheduled and nothing else takes a write lock on the rollup fields, there is little contention on the parent and grandparent records. However, it means that rollup values are always a few minutes out-of-date if the grandchildren are constantly changing.
D365 seems to implement a "rollup field" concept that does exactly this: https://www.encorebusiness.com/blog/rollup-fields-in-microsoft-dynamics-365-crm/ The scheduled task runs every hour by default, but can be configured by an admin.
To improve the update latency, you could make the flow on-demand or triggered by updates to the relevant grandchild fields, but have it check & update a "flow already triggered" table to ensure that multiple flow instances aren't trying to do the updates simultaneously. The "winning" instance of the flow sets the "running" flag, loops repeatedly until it finds no more dirty records, and then clears the "running" flag. The "losing" instances terminate immediately when they see that another instance is active.
This pattern requires a lot more care to handle potential race conditions related to records being marked dirty after the running flag is cleared, as well as transient errors that might terminate the flow before it completes. Again, a simple solution is to schedule a "sweeper" instance once per hour, or day.
If you need it to be strictly consistent, then this whitepaper might help: https://download.microsoft.com/download/D/6/6/D66E61BA-3D18-49E8-B042-8434E64FAFCA/ScalableDynamicsCRMCustomizations.docx It discusses the tradeoffs inherent in various locking and registration options for plugins.
If the rollup fields are rarely consumed, then it might be more efficient to recalculate the field only when a client requests that field while reading the parent or grandparent entity, using a separate plugin on those entities. You'd want to ensure that clients don't request that field unless they need it.