将交易标记为失败，增加重试计数器并推迟其在 UiPath 流程中的重新处理
Mark a transaction as failed, increase retry counter and postpone its reprocessing in UiPath process
有没有办法将交易标记为失败并让协调器增加重试计数器，但同时，post阻止交易被处理，比方说 2 小时？
在我的场景中，我正在数据库中查找一些数据，如果没有找到，我想将事务标记为失败并在 orchestrator 中将重试次数增加到 1，我希望这个失败的事务是 post花了几个小时。
假设数据库最终在一小时后更新了相关数据，当编排器触发相关机器人并在 2 小时后尝试重新处理交易时，它将成功。
如果另一方面，数据库仍然不包含数据并且已经过去 2 小时，事务将再次失败，我需要 orchestrator 将重试次数增加到 2，它将 postpone再过2个小时。
最后，如果 2 小时后数据仍然不存在（即已经过去 6 小时），我希望事务再次失败，将重试次数增加到 3 并停止尝试处理它，假设它已达到最大值在 orchestrator 的队列中设置的重试次数。它可能会发送电子邮件通知管理员。
有几点不明白：
为什么业务异常不重试。对我来说，上述场景是一个失败的业务规则（即未在数据库中找到数据），但如果我理解“设置交易状态”工作流程的内容，它不会重试重新处理业务规则异常。对我来说毫无意义，好吧，至少根据我的情况。
这是否意味着在 orchestrator 中增加重试计数器的唯一方法是生成系统异常？这感觉不对，我也不想在处理此类异常时根据 SetTransactionStatus 拍摄快照。我错过了什么吗？？
另外，在调用 postpone activity 时，我可以看到它正在将交易状态从“失败”更改为“新”，这也不理想，但可以接受，如果必要的。这里对我来说重要的是重试计数器在调用时不会在 orchestrator 中重置，但是由于在调用 postpone activity 时状态从失败更改为新，我担心它将重置计数器，这将是一个问题。
我还没有检查调用推迟时重试次数是否剩余activity，因为我还没有完成整个过程。
实现这一目标的正确方法是什么？这能实现吗？
谢谢
PS：很抱歉冗长 post 但我想我已经提供了尽可能多的细节。
UPDATE-1
@kwoxer 建议这可能是一个重复的问题，但我不相信它是。
post 处理创建事务时状态发生的情况，一些 activity 被调用以更改状态，但它没有解决如何处理一个失败的业务规则以及如何处理重试。
如前所述，未找到“数据”并想在几个小时后重试应该可以使用内置功能来实现，同时仍被视为业务规则异常，同时还依赖于重试计数器，以便此操作不会永远持续下去。
它还应该让您更好地控制状态应该发生什么，即推迟失败的交易应该是有效的并且状态不应该重置为“新”或者至少您应该可以选择什么状态应设置为。
我在对@kwoxer 的回复中 post 编辑了一个潜在的“解决方法”，但我认为它很丑陋，我真的希望有一种方法可以通过内置功能来解决这个问题，我'希望有人可能会建议我可能错过的东西或更好的解决方法。
谢谢。
暂时没有解决办法。您不能使用 Orchestrator 中的事务状态来处理进一步的进程 运行s。
相反，您可以做其他事情。创建一个触发器，让进程在 2、4 和 6 点通过：
执行 3 次 运行
现在，在 2 的第一个 运行 因业务错误而失败后，您将重试次数写入任何文件。但实际上，通过 cron 作业对过程 运行 进行硬编码，你不需要它。无论如何，当流程开始时，您只需检查该文件，这样您就有了自己的机制来处理业务流程错误。
这不是您想要的，而是在 UiPath 实现类似功能之前的最佳解决方法。但是现在他们的管道中没有任何东西。
另一个想法是使用队列而不是将其写入文件。但是队列不支持自定义标志。因此，如果通过 Set transaction status 给出的标志足够了，最好接受它。
有没有办法将交易标记为失败并让协调器增加重试计数器，但同时，post阻止交易被处理，比方说 2 小时？
在我的场景中，我正在数据库中查找一些数据，如果没有找到，我想将事务标记为失败并在 orchestrator 中将重试次数增加到 1，我希望这个失败的事务是 post花了几个小时。
假设数据库最终在一小时后更新了相关数据，当编排器触发相关机器人并在 2 小时后尝试重新处理交易时，它将成功。
如果另一方面，数据库仍然不包含数据并且已经过去 2 小时，事务将再次失败，我需要 orchestrator 将重试次数增加到 2，它将 postpone再过2个小时。
最后，如果 2 小时后数据仍然不存在（即已经过去 6 小时），我希望事务再次失败，将重试次数增加到 3 并停止尝试处理它，假设它已达到最大值在 orchestrator 的队列中设置的重试次数。它可能会发送电子邮件通知管理员。
有几点不明白：
为什么业务异常不重试。对我来说，上述场景是一个失败的业务规则（即未在数据库中找到数据），但如果我理解“设置交易状态”工作流程的内容，它不会重试重新处理业务规则异常。对我来说毫无意义，好吧，至少根据我的情况。
这是否意味着在 orchestrator 中增加重试计数器的唯一方法是生成系统异常？这感觉不对，我也不想在处理此类异常时根据 SetTransactionStatus 拍摄快照。我错过了什么吗？？
另外，在调用 postpone activity 时，我可以看到它正在将交易状态从“失败”更改为“新”，这也不理想，但可以接受，如果必要的。这里对我来说重要的是重试计数器在调用时不会在 orchestrator 中重置，但是由于在调用 postpone activity 时状态从失败更改为新，我担心它将重置计数器，这将是一个问题。
我还没有检查调用推迟时重试次数是否剩余activity，因为我还没有完成整个过程。
实现这一目标的正确方法是什么？这能实现吗？
谢谢
PS：很抱歉冗长 post 但我想我已经提供了尽可能多的细节。
UPDATE-1
@kwoxer 建议这可能是一个重复的问题，但我不相信它是。
post
如前所述，未找到“数据”并想在几个小时后重试应该可以使用内置功能来实现，同时仍被视为业务规则异常，同时还依赖于重试计数器，以便此操作不会永远持续下去。
它还应该让您更好地控制状态应该发生什么，即推迟失败的交易应该是有效的并且状态不应该重置为“新”或者至少您应该可以选择什么状态应设置为。
我在对@kwoxer 的回复中 post 编辑了一个潜在的“解决方法”，但我认为它很丑陋，我真的希望有一种方法可以通过内置功能来解决这个问题，我'希望有人可能会建议我可能错过的东西或更好的解决方法。
谢谢。
暂时没有解决办法。您不能使用 Orchestrator 中的事务状态来处理进一步的进程 运行s。
相反，您可以做其他事情。创建一个触发器，让进程在 2、4 和 6 点通过：
执行 3 次 运行现在，在 2 的第一个 运行 因业务错误而失败后，您将重试次数写入任何文件。但实际上，通过 cron 作业对过程 运行 进行硬编码，你不需要它。无论如何，当流程开始时，您只需检查该文件，这样您就有了自己的机制来处理业务流程错误。
这不是您想要的，而是在 UiPath 实现类似功能之前的最佳解决方法。但是现在他们的管道中没有任何东西。
另一个想法是使用队列而不是将其写入文件。但是队列不支持自定义标志。因此，如果通过 Set transaction status 给出的标志足够了，最好接受它。