在我当前的项目中，我们已经通过使用装饰器设计模式彻底解决了这个问题。

基本上，我们将每个用户出口都转换为Z-BADI。

以下是其中涉及的步骤：

• 使用单个EXECUTE方法为有问题的用户出口（SE24）创建一个接口，该方法可以导入/导出出口本身的参数。
• 创建一个自定义的Z表以征集要从用户出口调用的类。 该表不应包含MANDT字段，因此您可以将定义放入工作台请求中。
• 对于每个不同的功能需求，创建一个实现接口的类（SE24），然后在其中编写您的功能ABAP代码+将您的类放入Z表中。
• 用户出口本身应该从Z-Table中进行SELECT *，为每个类动态创建一个对象，强制转换为接口并调用EXECUTE方法。

如果您这样做：

• 您可以将用户出口+ Z表和界面立即发送到实时系统。
• 对于每个不同的功能需求，创建一个类，在Z表中进行定义，并将其放入相同的请求中。
• 由于实施请求是分开的，因此您可以在不同的时间点将它们发送到实时系统，而不会互相影响。

这是基本思想。

在我当前的项目中，我们甚至没有针对每个用户出口的独特界面。 相反，我创建了一个通用接口和所有用户共享的Z表，并且参数通过容器对象传递（属性容器设计模式）。

但是如果那太复杂了，也可以为每个用户出口创建一个不同的界面（如上所述）。

弗雷德里克·吉罗德（Frederic Girod）不能完全同意，但我从未说过这很复杂；）我实际上很喜欢使用模式进行编码，而我的回答只是作为解决小问题的一种简单方法。 p#

Rebeca-我在2017年对SAPMV45A中的VA01增强提出了类似的问题，该线程中的讨论也可能对您的问题有所帮助：

什么是允许多个开发人员更改SAPMV45A增强功能的最佳实践？ br>

坏消息是，我们希望在这方面还没有取得任何进展，而且情况仍然像3年前一样，甚至还有更多的线索 代码全部告诉了...。

干杯

Bärbel

"包含"方法的典型问题是； 最终，有人会写CHECK或RETURN并阻止其他包含物中的代码执行。

显然，如果您不使用包含，该风险也存在。

我的基于类的方法（上述）也可以防止这种风险。

尝试创建BADI，在用户出口中调用该BADI。 BADI提供接口，多种实现方式，并且取决于过滤器。 因此，只要有需要，就可以像任何标准BADI一样为自定义BADI创建实现。

正如您提到的，有多个项目正在运行，因此请在用户出口和内部创建隐式增强功能。 叫这个巴迪。 您可以随时删除它，并在它退出当前锁定的传输方式后在用户出口内直接调用它。

-Mahesh

教他们...我不会让我的团队在特斯拉的汽车在车库里集尘时坚持骑自行车；）但是，如上所述，一位具有扎实的OO-ABAP和设计模式知识的经验丰富的建筑师应该带领他们。 否则，可能会出现事故/反模式。

丽贝卡。，

< p>是的，您可以在多个include中包含每个内容，并在每个include中编写满足各自情况的必要检查。

还要在编写包含include的代码时使用IF FOUND关键字，以使每个开发项目不会干扰其他开发项目

您可以点击以下链接以包含SYNTAX。

已加入

致谢！