这是我在这里的第一个博客。我一直想写点什么，但从来没有写过。好吧，让我们开始尝试留下一些希望有用的东西。

它是关于在sapbw转换中调试和提高个人生产力，同时在ABAP专家、开始或结束例程中查找问题。以下帮助我在开发或解决问题时每天节省几分钟的时间。这可能有助于避免您的系统监控团队抱怨由于SM21中的这些条目，系统日志已满。你有时会忘记在把东西运到生产现场之前去掉断点吗？

就我个人而言，什么大数据，我对为了达到启动例程而进行的单步调试或者为了达到我的ABAP代码而在转换中进行的特定例程感到恼火：

最简单的解决方法是在正确的位置放置一个条件断点，它不会污染系统日志文件。这非常简单：

这有一个简单的效果：每次以处理模式"在对话进程中串行（用于调试）"启动相应的DTP时，您将直接跳到断点。没有没完没了的单步调试，没有无用的日志条目。这是因为在这个模拟模式中没有生成真正的请求id。只有"DTPR\u模拟"是通用的。

我过去使用过其他不太方便的方法。比如直接在生成的源代码中设置断点，返利购，或者使用"break-pointidxyz"和SAAB。在执行50k次的转换规则中，这些仍然有用。但是如果可能的话，我宁愿使用一个全局变量并设置/取消设置这个变量（同时检查DTPR\u模拟）。"转换前"的断点就在生成的ABAP代码丛林的中间。SCN里曾经有一种"愿望清单"。我应该早点在那儿提的。至少"转换后"一个几乎在正确的位置上。

除了跳转到调试器之外，断点对于其他东西也很有用。虽然这绝对是一种虐待。如果您懒得创建正确的监视器条目，或者这些监视器条目没有被监视，那么有一种简单的可能，淘客模板，就是在系统日志中写入一些内容：

这对于让别人提醒您有时被迫创建的混乱非常有用。老实说，我永远不会用那种东西

，北京大数据公司，大数据和小数据