Hello Henrik，

您是否在谈论如何处理prod和test idm系统或如何处理dev和qs系统，例如 ERP吗？

关于用户和角色，这些系统是IDM的"产品系统"，因为需要正确设置帐户和权限（因为否则开发人员或测试人员无法完成工作）。 无论系统本身的使用如何，但从IDM的角度来看，它们都与产品ERP相同（例如）。

。

因此，我们当然可以通过产品IDM对其进行管理。

。

此致

Steffi。

Hello Henrik，

我们的前景并不广阔，无法掩盖我们可怜的IDM。 ;）但是，即使我们有20多个非产品系统，我仍然会采用相同的方式。 就像我说的那样：对于IDM来说，那些仍然是生产系统，需要从用户和权限的角度维护它们。

因此，无论用户数量如何，我还是会比较喜欢一个IDM系统而不是多个IDM系统。 如果您拥有一个具有10.000个帐户的生产型ABAP系统，则不会分开这些帐户，对吗？ 为什么这些帐户在哪里累积很重要？ 不应对IDM有所作为。

也是明智的配置。 那些不同的IDM系统也需要维护。 你们每个都有不同的配置吗？

。

此致

Steffi。

Hello Henrik，

我更喜欢第一个选项，因为它为我提供了在成功完成UAT之前不触摸生产配置和数据的选项。 这样，在开发和UAT期间不会对业务产生影响。 这种方法的另一个优点是，这里的包可以直接从Dev传输到UAT，从UAT传输到PRD，而无需任何更改。

同意维护独立服务器比较困难，费时，昂贵并且涉及较高的初始成本，但是，如果业务本质上非常关键并且可以负担得起此类费用，则可以忽略这一点。 通过为PRD，QA和Dev选择不同的系统配置，再次可以使成本最小化。

在第二种方法中，一切看起来都不错，但是我们需要安装多个SAP NW AS JAVA来从IDM UI管理生产和非生产身份存储。 为了减少调度程序和运行时引擎上的负载，还建议我们使用不止一个运行时引擎，因此，这种方法最终将导致IDM数据库数量减少。 在采用这种方法时，在开发新作业/流程时我们必须非常小心。 将包导入生产身份存储后，必须更改在pass/SQL查询/脚本中使用的身份存储值。 如果我们可以管理此类手动操作，那么第二种方法也很好。

正如您已经提到的那样，从单个IDM管理所有环境确实是一项棘手的工作，并且还会添加大量数据并在单一的SAP IDM服务器上加载。

此致

C库马尔

感谢您的输入！

我认为我们将为非生产性IdM使用一个单独的系统，因为我们有不同的流程，要整合到生产性IdM中会很复杂。 显然它将仍然被视为富有成效的景观！