我总是在项目中为每个用户使用具有ID Z_ID_MODE属性的" IDM模式"。 这样，您就可以顺利进行铺展。 该属性具有以下模式状态值：

IDM_MANAGED
BACKEND_MANAGED
UNMANAGED 离开

在IDM推出之日，您将2名或3名雇员从UNMANAGED切换到IDM_MANAGAED，并确保正确配置了所有内容。

因此，您只能部署少量用户，并且仍然可以按设计在BACKEND_MANAGED模式下运营公司（某个国家/地区）的部分业务。 例如，如果公司的一部分未引入IDM。

BACKEND_MANAGED意味着用户帐户仍保留在后端的SU01中，但IDM会通过BACKCHANNEL_JOBS读取这些用户帐户，并且IDM会将数据分发到 其他SAP客户（AD，...）

BACKEND_MANAGED身份没有IDM-FORMS，因为它们是在SU01中进行管理的。

我在项目中使用了多年，每个人都喜欢它 ，因为您在项目的所有阶段都非常灵活。

在大型项目中还有更多的ID_MODE。

您只需要在IDM的某些方面（初始负载，BACKCHANNEL负载，提供，FORMS的访问控制..）考虑（加入）此属性，但这 没什么。

非常妙的是，通过IDM来控制UNMANAGED和BACKEND_MANAGED员工的USERID（MSKEYVALUE）也唯一。 因此，在非常大的项目中，可能会有BACKEND_MANAGED受雇女性"按设计"，绝不会是IDM_MANAGAED，因为一个国家仍在使用SU01或其他工具。 IDM读取BACKEND_MANAED用户，并将SU01中维护的数据分发到其他连接的系统。 可能还存在"设计无人管理"的ID，因为它们是不受中央控制的技术帐户或员工。

UserID不管是唯一的，都是因为MSKEYVALUE和数据集在IDM中，导致有BACKCHANNEL作业定期读取所有已连接系统的UNMANAGED，BACKEND_MANAGED和IDM_MANAGED数据集。 #LOVE

您还可以将用户从UNMANGED切换到IDM_MANAGED，再切换到BACKEND_MANAGED。 #LOVE

我将为此写一个最佳实践博客，因为我和IDM管理员都喜欢这个。

请注意，需要完全理解不同的IDM_MODE并在IDM的所有部分中100％正确地实施，导致IDM中最重要的步骤之一是正确定义和实施了领先系统的定义 （在用户级别，属性级别上……）