标记，

我已经使用了此功能，并在内部测试环境中对其进行了测试，对我而言它是有效的。

" IF保留拒绝的数据"功能是对交易数据加载的增强。

按照最初的设计，被拒绝的数据意味着该数据是无效的，不应再保留。 在这种情况下，我们只是将拒绝的数据输出给最终用户。

但是，客户要求我们提供一项功能，以在回写步骤中保留拒绝的数据：

a）。 流程链/CPMB/LOAD_DELTA_IP是一个特殊的链，当前的包执行基于上一次包执行的结果。 b）。 要求如果由于一个数据区域的锁定工作状态而拒绝数据，那么应该可以解锁该数据区域并重新加载被拒绝的数据。

由于软件包的执行是基于之前的执行，因此我们提供了增强功能，可以保留在WRITE BACK步骤中为下一个软件包运行而拒绝的数据。 （工作状态检查处于回写阶段）

执行：如果检查软件包日志，您会发现有3个任务：任务1：SOURCE DELTA INFOPROVIDER --->此任务用于加载存储的数据（包括上次拒绝的数据）。 如果加载数据成功完成，它将从请求中读取上次加载的数据。 否则，它将以错误结束，并且将不执行后续步骤。

请注意，加载存储的数据的步骤是通过调用WRITE BACK完成的。 因此，如果仍然拒绝数据，则将其存储以用于下一个包执行。

任务2：转换->如果任务1在上次存储的数据之上有新数据，则必须根据转换文件和转换文件转换此数据。

任务3：APPEND LOAD DELTA INFOPROVIDER->此任务再次调用回写以尝试写入已转换的新数据。

如果在此步骤中有任何拒绝的数据，它们将被存储以用于下一个程序包执行，并将在第一个任务中进行处理。

注意：如果转换文件中的" VALIDATERECORDS = YES"，则意味着您想验证Task2（CONVERT Task）上的数据。 在这种情况下，将在"转换"步骤拒绝数据。 我们不会保留此类被拒绝的数据。 如果将关键字更改为" VALIDATERECORDS = NO"，则在CONVERT任务中将不会验证数据。 在这种情况下，数据将被放入TASK3（APPEND LOAD DELTA INFOPROVIDER TASK）。 该任务将通过调用Write来拒绝此类数据，并将其存储。

因此，如果在Delta Load日志的CONVERT任务中拒绝了任何数据，则此数据将不会在后续执行中再次加载。

请确认您的情况是APPEND任务中正确拒绝了被拒绝的数据。 如果是这样，一旦纠正了拒绝的原因，随后的执行将加载该数据。

-彼得