在某个时刻，我们都后悔了存在于电子商务警报和通知功能中的漏洞。SAP SuccessFactors试图在当前版本中提出一些显著的改进，这将使生活更轻松一些。

以下是当前版本中遇到的改进列表：

1>EC警报的改进：排除终止使用者的警报

组件：LOD-SF-EC-ALR编号：ECT-88914/ECT-85239KBAs:2676210

该规则设置为在将来向主题用户发送警报（例如，合同结束前5天）。如果主题用户在警报日期之前终止，物联网操作系统，则仍会创建警报。这是EC警报的一个主要问题，外汇返现，SAP已经认识到这一点，并内置了逻辑，不发送此类警报。

通过此增强，在扫描记录和使用警报规则进行评估期间，已终止主题用户（对于当前已终止用户）的记录被排除，并且未在警报表中获取条目。当警报到达触发日期并被触发时，排除在条目到达警报表后被终止的主题用户的记录。不创建警报，不发送电子邮件；警报状态更改为竞争状态。

之前发生的情况：在静态生成未来某个日期的警报后，为终止警报的用户发送警报，用户在这两个日期之间终止警报。

将有何改进：通过此增强，在扫描记录和使用警报规则求值时，将排除已终止主题用户（对于当前已终止用户）的记录，并且不会在警报表中创建条目。当警报到达触发日期并被触发时，系统还将排除在警报表中输入后被终止的主题用户的记录。未创建警报且未发送电子邮件；警报状态更改为竞争。

警告：如果用户在未来终止，联通物联网，则在合同结束日期之后，仍将发送警报。

2>EC警报提供作业的性能改进：

组件：LOD-SF-EC-ALRID:ECT-85239/ECT-98999

更改逻辑以利用规则批处理过程：获取EC实体列表，迭代每个规则，将实体列表和单个规则传递给规则引擎以使用实体列表评估规则。

之前发生的事情：系统用于获取EC实体列表，迭代每个实体并调用规则引擎API，以使用单个实体计算规则。这种方法没有利用规则批处理过程。规则API允许传入属于同一基本对象的实体列表。

改进之处：系统获取EC实体列表，迭代每个规则，传递实体列表，然后触发单个规则到规则引擎API，用实体列表评估规则。这使得作业的执行效率更高。

3>EC警报设置作业的性能改进：

组件：LOD-SF-EC-ALRID:ECT-85239/ECT-70257

在作业中添加了多个线程，以提高作业扫描大量数据并创建/处理警报时的性能。

以前发生的情况：以前，系统没有同时处理多个记录，在扫描大量数据时会花费大量时间有哪些改进：系统现在采用多线程技术，对n条记录进行批量处理，以加快处理速度。适用于扫描记录和创建警报。

4>EC警报的改进：做瓷砖

组件：LOD-SF-EC-ALR编号：ECT-83768/ECT-85239KBAs:2676650/2676702/2676693

取消/删除操作时，未取消相关警报。但是，什么是淘客，这些警报仍然包含在要采取行动的警报计数中。重新设计后，取消/删除的警报会出现错误消息。

之前发生的情况：即使警报取消，采取措施磁贴计数也不会恢复。

改进措施：如果存在无效的ToDo项，而该项缺少源数据（从而显示ToDo磁贴中显示的计数不正确），系统现在显示默认主题行："由于源数据已被删除，此警报不再有效。请单击"完成"删除警报。"

5>EC警报的改进：作业详细信息中给出的警报规则ID

组件：LOD-SF-EC-ALR编号：ECT-101243KBAs:2677445

EC Alerts job Details现在将在Provisioning的job Details中提供规则ID，以及与该规则匹配的记录计数。

之前发生的事情：当前EC Alerts job Details文本不方便读取，缺乏清晰性，用户友好性较差。

将有何改进：如果在EC警报作业的运行时未捕获任何错误消息，则更新文本以反映"无错误消息"。

仍有少数用例需要访问静态创建的警报，云服务器服务器，并基于这些警报在业务规则中设置条件增强是一个受欢迎的解脱，特别是终止用户被排除在警报之外。