你好，基兰，

如果生成代码但失败了，则可以显示生成的错误消息。 如果代码在执行时失败，则只能返回客户代码作为消息返回的内容。 如果有转储，您可以建议ST22。 如果发生某些异常，则可以使用自己的捕获代码捕获该异常，并使用异常提供的信息根据该异常格式化某些内容。 使用诸如get_text或get_source_position之类的例程。 这些是cx_root的方法，因此您可以在其中查找适当的名称和API。

希望这会有所帮助。

Marcel

哇！ 我希望它不是免费的源代码！ （很好的漏洞！您的系统已准备好受到攻击！）

（但是，如果它不是免费的源代码，则意味着短暂的转储是由您自己的API引起的，因此，恐怕您的系统会 易受攻击）

您好 kiran rachamalla

正确，您正在为某些第3个应用程序创建API。 在这些情况下，通常在函数中有一些返回参数，这些参数将返回有关已执行操作结果的信息。 这可能是一个简单的整数字段，或者更准确地说是错误报告，可能是一些更复杂的结构或字段集。

现在，正如我所看到的，您的API不应直接返回SAP错误。 它应该首先尝试处理这些错误并在可能的情况下"修复"它们。 如果可能的话，它还应该尝试避免任何错误。

如果错误是无法避免且不可修复的，则应将信息返回给第三方应用程序，还应在返回之前对其进行处理-将其标准化-可能在错误消息中添加一些描述性文本（某些SAP错误） 根本不清楚）。 以某种方式使第三方应用程序知道发生了什么以及为什么。 但是，不要不先处理就直接返回SAP错误。

请注意，
Mateusz

编辑：此外，正如我刚刚注意到的那样，您正在使用API​​做什么 -允许第三者在您的系统中执行ABAP代码，我强烈建议您不要使用这种解决方案。 更不用说明显的最坏情况，即第三方应用程序可以简单地从SAP删除数据，其他问题可能是：如果直接插入数据库中的错误记录，与未优化代码有关的性能问题，缺少缓冲或简化逻辑的可能性 。
API应该允许系统内的某些操作，但是应该在API本身内部明确定义和编程这些操作。 第三方软件未动态定义。

您好，桑德拉·罗西，

没有非免费的源代码。 问题是我有几个程序可以动态调用并执行。 但是如果其中存在转储，则很难准确地找到错误的出处。 因此他们要求进行st22错误分析之类的事情。

嗨，海森，

感谢您的考虑。 我已经做完了，意思是使用了cx_root并提供了get_text和get_source_position的详细信息。 但是他们想要完整的细节，例如在重复转储的情况下，他们不知道是哪个表转储引起的。

此致

kiran rachamalla。

我不了解那些无法访问SAP系统的人如何比SAP员工更好地理解短期交易。

请注意，当发生短暂的转储时，它们不仅不会收到任何东西，还应该至少能够接收运行时错误的名称（例如SYNTAX_ERROR，CONVT_NO_NUMBER等）+简短说明