要点1：不，我不认为这是个好主意。 SAP已经提供了良好的错误监视功能，为什么要重新开发同一东西？

要点2：在您的流程中对此建模，这就是工作流的目的！

嗨，迈克，

感谢您的答复。

第1点：是。 有错误监视程序可以从错误状态重新启动。 但是，我的UI5应用程序是具有自定义表和字段的自定义应用程序。 必须针对相应的请求对此进行更新，这尤其会导致错误。 对于每个错误请求，我的自定义表都必须更新为"错误状态"。

第2点：是。 如果工作流出现系统错误，我们必须在哪里应用自定义逻辑程序？ 基本上，如果工作流出现错误，即使我们解决了错误，我们也无法将相同的错误工作流重定向到上一级/下一级批准仪式，因为状态将为"错误...（否则），是否可以触发 立即发生错误的事件？。 这样，通过触发错误事件，我们可以编写自定义逻辑来重定向批准过程？ 如果我错了，请纠正我。 谢谢。

让我换一种说法：

更有效的方法是：每2分钟扫描一次状态，或者在需要信息时读取状态？

如果您正在编写代码以重复工作流状态并尝试对系统错误进行建模，则建议您重新考虑您的方法。

系统错误应该很少发生，如果您对如何处理这些错误有特定要求，则应该对任何预期的错误进行建模。 就像这样：确定代理->如果失败，请路由到其他人进行更正并批准。

我建立自定义工作流已有10多年了，从没将工作流状态复制到另一个表中。 数据建模101.而是将精力集中在构建可最大程度减少故障的健壮应用程序中。

工作流错误应本质上是技术性的，对于特殊情况应集中处理。 SAP已经为您提供了所需的工具：ST22，发送给WF管理员，SWI2_DIAG，SM58，解决方案管理器，CCMS等。

为什么要编写一个重复所有这些的报告？ 您打算如何应对所有这些情况？ 请记住，您的WF在许多情况下都不会出错。 并考虑一下测试工作。 只需确保已为所有应用程序（而不仅仅是一个应用程序）准备了处理这些情况的流程。

第2步：将状态推送到应用程序总是 一个坏主意。 您可以在需要时阅读WF状态并将其发布在您的应用程序中。 有许多方法可以恢复失败的工作流程，在每种情况下如何处理重置状态？

祝你好运。

嗨，

您也可以借助fm SWP_WORKFLOW_LOG_READ读取工作流日志。

谢谢