亲爱的社区，增强（SD用户出口、客户出口、业务外接程序、源代码增强等）是定制自己流程的好方法。

但是，如何实现增强很重要。你可以得到真正的过程优势，同时你可以得到设计（技术）问题，这将伴随你很长一段时间，也许永远。根据"一次编程，维护一千次"这句话，这样的事情会让生活变得困难…一千次。

不幸的是，我在实践中不时遇到一些增强实现的负面例子。我对他们中的一些人不是无辜的，所以我分享我的经验和想法，以便其他人能够在将来做更好的增强实现。

我也为这个异常长的博客道歉。阅读时请喝两杯咖啡或茶。

这里有一个非常经典的例子：增强"MM06E005"（采购文档中的客户字段）。可与交易单SMOD核对，

可用于采购订单表头和物料级的增强（例如见交易单ME23N）。但不仅仅是采购订单。此外，还包括协议和报价要求。

这是一个很好的细节，但在增强的描述中使用了术语"采购文件"。这意味着三种不同的事情（业务对象类型）：采购订单、协议和询价。开发人员实现了采购订单的增强（或者他们认为这样做了），但同时也影响了协议和报价请求

用于增强不同业务对象类型的屏幕是分开的（不同的dynpro）。应用程序逻辑不是这样的。例如，如果您在Include ZXM06TOP中定义了一个全局变量，那么它在所有三种业务对象类型的应用程序逻辑中都是可见的。如果您不小心，这将导致"污染"内存和误解。

请查看功能模块"EXIT_SAPMM06E_006"（将数据导出到采购文件标题（PBO）的客户子屏幕）。此功能模块有一个导入参数"I\u BSTYP"。它的存在是为了区分采购订单、协议和询价。您可以根据业务对象类型设计应用程序逻辑。正如我所说："您可以"…

此外，您经常会在这些增强中发现许多应用程序逻辑。太多的应用程序逻辑导致无法再区分进程。全局变量和局部变量以及常量、导入、导出、更改和表格参数形成了一个丰富多彩的组合–任何人在这里更改某些内容都是非常有经验、勇敢、绝望或被迫的

如果两个增强提供相同或类似的选项，情况会变得更糟。例如，增强"MM06E005"和业务外接程序（BAdI）ME\u PROCESS\u PO\u CUST。然而，BAdI也可以用来增强事务逻辑（dialog）和业务应用程序编程接口（bapi，dialog/background）。

这里的可能性和草地上的花一样多。不幸的是，这种情况也带来了问题。

幸运的是，人们能够找到复杂问题的答案。以下是我的一些方法。有的已经试过了，有的还在考虑。很乐意评论和讨论。

在中国经典文本《道德经》中有一段话是这样写的："整理尚未混乱的东西"（对不起，我的翻译不好）。我经常遇到没有充分考虑问题的情况。人们常说必须要有所发展。这个决定做出得出奇地快。

那是不对的。至少在我看来不是。编程不是万能的。有时有非常好的标准解决方案，公有云市场，或者需要对过程进行重组。当然，阿里大数据应用平台，这是一场"严肃/激烈"的讨论，也许是一场冲突。但必须解决。增强实现的后果可能比解决冲突和选择不同的非编程解决方案更昂贵。

我在openSAP课程"为ABAP编写可测试代码"中第一次听到这个术语。在我们被污染的海洋里，对不起，这些是小救生筏（小岛）。您可以通过调用类的方法将增强扩展扩展到自己的源代码中。不多了。这个类和其他类（组合）实现所需的应用程序逻辑。在增强中没有进一步的应用逻辑。

这有许多积极的方面。调用方法时的参数已经阐明了什么是重要的。类名和方法有助于对意义和目的作出结论。局部变量可以减少。可以保证可测试性（不要忘记编写接口）。调试更舒适。

增强实现的开/关开关可以挽救生命。例如，可能有一个中央框架来管理所有增强实现的开/关状态。或者您有单独的开关，因为它们依赖于某些组织数据，例如公司代码和采购组织。

在任何情况下，您都应该能够通过关闭来对不可预见的情况作出反应。顺便说一句，对我来说，"紧急关闭系统"并不是一个迹象，表明你还不了解问题的方方面面。它们更多的是对现实生活的尊重（见墨菲定律）！

在增强实现中，应将全局变量、类型和常量减少到最小值。否则，大数据中心是什么，它们会污染内存。常量和类型可以外包给类或接口。一定要使用合适的名字。

增容在哪里真正有影响？你应该仔细检查和测试，以避免任何负面的惊喜。如上所述，当通过远程函数调用（RFC）调用bapi时，它们会受到影响。这可能会在SAP ERP系统以外的系统中引发问题（错误日志）。