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

在ABAP工作台团队的支持下，我们可以激活Badi 方法if_ex_cts_request_check〜check_before_add_objects并通过那里的新全局类实现所需的检查。 有关此实现的一些详细信息，请参见我的博客文章 SAP社区-和SAT-如何帮助我理解和理解 写我的第一个单元测试和评论线程。

非常感谢大家在此方面的帮助！

干杯

Bärbel

由于我昨天在德国DSAG网站的开发论坛上发起了"同级"讨论，这是一个非常有前途的更新。

建议是 在功能模块TRINT_OBJECTS_CHECK_AND_INSERT的末尾添加一个增强功能，可以在将对象附加到传输请求或任务之前对其进行访问。 内部表LT_E071包含要附加到传输器的对象，因此可以在使用TABL，DTEL，DOMA等对象时查询对象类型并仔细查看。

这似乎是放置一些逻辑的好地方，因为只有在进行更新活动时才会调用该逻辑，因此无需担心意外阻止显示操作。 我已经在沙盒系统中开始了一些原型制作工作，到目前为止，看起来不错，因为可以同时从Eclipse和SAP GUI处理中调用该增强功能，并且可以在需要时触发错误消息。

什么？ 将需要做一些工作来确定需要哪些信息来阻止某些活动（例如通过SE11发生的事情），但仍允许其他活动（即通过WE31进行IDOC定制）。

将保持您的状态（并向下滚动） 行，我可以将此讨论变成博客文章。）

欢呼声

贝尔贝尔

由于马修·B（Matthew B）已经提出了过时的业务主题 流程要花钱，我还要补充一点，您还要为这些"特殊"用户维护DDIC对象而支付昂贵的开发人员许可证，因此这是"硬"成本，应该在您进行变更管理的论点中很容易地量化。

嗨贝尔，

因此，存在一个BADI" CTS_OBJ_CHECK_AND_INSERT"，它提供了IF_CTS_OBJ_CHECK_AND_INSERT〜CHECK_AT_OBJECTS_INSERT方法，该方法可用于为用户提供任何对象，然后再将其分配给传输请求。 每当通过ADT创建新对象以及编辑对象时，都会调用此BADI。 实际上是从FM TRINT_OBJECTS_CHECK_AND_INSERT中调用的。 因此，您可以检查一下它是否已经适合您，而不用更改FM。

--------------------------------------------------- -----------------

[更新]

BADI CTS_OBJ_CHECK_AND_INSERT似乎仅供内部使用 ，不建议客户使用。

致谢

Abin

没关系，DSAG论坛上的评论已经指向正确的方向。

为什么在执行任务时不移动此检查 已发布。 因此，您还可以确保以后没有人可以在系统中进行类似的操作，并且"特殊"用户也可以在此之前完成主管任务。

不问为什么"正常"开发人员可能无法做到这一点 自己创建一个数据元素。 我个人无法想象这将不会导致更长的开发任务，即使是很小的更改，最终还是有人用真钱支付了：-）