HelloBärbel，

感谢您上周的电话。 让我分享我们与社区讨论的内容。 也许其他社区成员会觉得它有用。

我们讨论了以下选项：

1）使用标准用户授权。 通过用户配置文件简单地删除创建DDIC对象的功能

您向我们解释说，如果您删除创建ddic对象的权限，那么在DDIC环境中也将无法执行某些其他操作，

2）使用当前的SAPGUI userexit

这是不可能的了。 用户出口硬连接到SAPGUI SE11 UI实现。 ADT REST服务重新使用了大多数ABAP工作台代码，但是显然，SAPGUI UI层中的退出不再起作用。 实际上，我们的ADT REST服务不再与任何UI技术绑定。 他们不知道是否正在从Eclipse，从iPhone App，从浏览器调用它们。这使得无法提供与UI相关的新用户退出。

3）使用ADT授权BADI

有一个中央BADI，可以对每个REST通信请求进行权限检查。 首先，BADI目前不属于我们的官方API。 其次，此出口对于您的要求来说太技术性了。 您将不得不检查将来可能会更改的单个URL

4）使用运输区域中现有的BADI（如Abin Baby等人所述）

系统允许您根据自己的规则和条件阻止将对象分配给运输请求。 该解决方案的最大优点是它独立于各自的IDE。 传输系统不知道Eclipse中的ABAP还是SE11将对象分配给传输。 这使其成为最稳定和最可靠的解决方案。 即使使用了完全不同的IDE（ABAP社区甚至正在进行VSCode扩展项目），也可以确保执行相同的检查。 此选项的缺点是，在用户流程的最后而不是开始时检查用户授权。

结论

我们同意旧的UI用户出口具有以下优点：当用户尝试创建/编辑/删除DDIC对象时，会立即获得反馈。 但是，我们的服务器体系结构现在独立于UI。 因此，旧的行为不再可实现。 我们的建议是使用选项4）

致谢
Thomas

巴贝尔·温克勒正确。 您还可以集中设置授权以防止使用一些战略性标准工具，但允许使用自己的工具...

Abin Baby

嗨，Abin

感谢您的回应-很明显-这不是我所希望的，但也不会太大 惊喜 我真的很想知道我们的要求是否如此"奇特"，以至于还没有提供ADT SAP方面的中央挂钩？ 从我的角度来看，与在Eclipse中创建某些开发人员尚未安装的东西相比，集中放置一个挂钩是很有意义的。 一个插件，但其他人却没有，您无法真正控制谁可以通过哪种设置访问SAP。

因此，猜测这将花费相当长的时间，我们将 必须使用以下临时解决方案，例如使用FM TRINT_OBJECTS_CHECK_AND_INSERT中的增强功能，如下面提到的 ？

干杯

Bärbel

"据我所知，Codeinspector不会检查DDIC对象，并且 这也将为时已晚。"

默认对象收集器不会拾取DDIC对象，但是您可以编写自己的对象，也可以使用 https://github.com/larshp/abapOpenChecks/blob/master/src/collectors/zcl_aoc_embedded_pa​​ckages.clas.abap

我同意在您的流程中为时已晚，但这是一个适合标准工作流程且无需用户退出的选项。