关于 Salesforce Spiff 中的数据优化和性能

设计者和佣金引擎

Designer 和佣金引擎在本质上相似，但用途不同。Designer 使用佣金引擎实时显示计算结果，与电子表格非常相似。佣金引擎单独计算语句，为每个语句分配固定的内存和时间。

此表显示了每个组件的关键特征。

由于 Designer 在比佣金引擎更低的内存和处理限制下运行，因此 Designer 中的超时是调查和优化的有用信号，但这并不始终意味着语句计算将失败。对于较小的配置，设计器中的超时通常表示相同的逻辑将在语句规模下挣扎。对于更大或更复杂的计划，即使等效语句计算成功，设计器也会超时。

当语句超过其内存或时间分配时，有两种路径可用：联系 Salesforce 支持以请求增加资源，或优化计划逻辑和数据筛选器。实际上，当在接近工资单运行时发现问题时，资源增加通常是最快的解决方法。优化解决了根本原因，如果仅靠资源增加不足以解决问题，或者作为减少报表资源消耗的长期策略，优化是推荐的后续行动。

例如，假设您在业务机会对象上构建了一个计算字段，该字段使用sum()函数来汇总代表所有已结束业务机会的年初至今年经常性收入 (ARR)。当您在 Designer 中为具有两年历史的单个代表预览报表时，计算超时。如果在 Designer 中发生超时，当佣金在一次运行中处理整个代表群体的语句时，它会遇到相同的问题，而且可能更大规模。修复方法是在转移到生产之前优化计算：关闭sum()字段上的跟踪，将其封装为单独的工作表计算，或使用筛选的数据范围替换完整历史记录扫描。

提示 在将复杂计算推广到生产之前，先在 Designer 中测试它们。设计器中的超时是调查逻辑和数据筛选器的信号，但语句计算成功是生产基准。对于较大的计划，即使语句计算正确，设计者超时也可能持续存在。

优化工作的重点

Spiff 的性能改进来自三个方面：数据如何进入系统，计划逻辑如何处理这些数据，以及哪些字段被配置为显示在报表页面上。同时解决这三个问题会产生最佳结果。

将优化工作集中在这三个层。

• 数据层。优化数据筛选器，通过上游筛选（在源系统中）减少记录量，并了解对象之间的模式和关系。请参阅在 Salesforce Spiff 中优化数据筛选性能，并通过上游数据更改减少佣金引擎负载。
• 规划逻辑层。封装计算，在不需要的地方禁用跟踪，并使用查找表和动态逻辑，而不是硬编码值或复杂的嵌套公式。请参阅在 Salesforce Spiff 计算中使用封装和在 Salesforce Spiff 中使用查找表和动态逻辑。
• 报表页面配置。将报表页面上的字段限制为代表需要查看的内容，并将中间计算和诊断字段从面向代表的视图中移除。佣金引擎为每个语句运行每个可见字段，甚至是引擎在计算路径中不会遇到的字段。

性能原则

在整个实施过程中，请记住这些指导原则。

• 从第一天开始优化，并定期重新访问。将性能改进改造到现有配置中比从一开始就构建它们更难。计划逻辑和数据量会随着时间的推移而变化，因此将性能审查纳入常规计划维护周期，而不仅仅是初始实施。
• 在数据到达引擎之前对其进行整合和聚合。构建您的数据，以便代表处理有意义、可管理的义务集，而不是数百或数千条个人记录。在数据同步到 Spiff 之前，在上游聚合和整合数据会降低代表和佣金引擎的复杂性。有关控制哪些数据同步到 Spiff 的特定技术，请参阅在 Salesforce Spiff 中优化数据筛选性能。
• 随着时间的推移，了解数据量。在启动时表现良好的配置可能会随着记录计数的增长而下降。与数据团队一起计划归档并审查预计数量。
• 将报表页面字段限制为代表需要的内容。在报表页面上选择的每个字段都由引擎为每个报表运行，而不管计算路径是否以其他方式到达它。将中间计算和内部跟踪字段从面向代表的视图中移除。
• 仅在符合目的的地方打开跟踪。跟踪存储数据并消耗内存和计算时间。对于代表需要在报表中查看的字段或 Comp 管理员需要报告的字段，启用此选项。对于中间计算、关系遍历和任何不需要显示在代表视图或导出中的字段，请将其关闭。
• 避免硬编码值。在工作表字段中存储变量金额并使用查找表，以便逻辑在业务规则更改时保持可维护性。