在传统 SAP 项目里，给内部员工创建一个 SAP 用户，很多人的第一反应仍然是事务码SU01。管理员输入用户名、用户类型、角色、参数和初始密码，保存之后账号就存在了。但 User Self Service 面对的场景完全不同。这里的核心需求不是管理员替业务用户建账号，而是允许 SAP Business Suite 的使用者通过前端应用自主提交账号申请，再经过激活流程完成用户创建。整个过程还可能跨越 SAP Business Suite 后端和独立部署的 SAP NetWeaver Gateway 系统。因此，从技术视角来看，它已经不是单纯的用户主数据维护问题，而是一条由 OData 服务、用户申请状态、激活凭据、通知机制、RFC 复制以及 BAdI 扩展共同组成的完整业务流程。SAP 官方定义的标准 User Self Service 用户创建过程包含两个主要阶段，注册用户名和激活用户。只有两个阶段全部完成，真正的 SAP 用户才会在 SAP Business Suite 系统中形成，并按照配置复制到 SAP NetWeaver 系统。这里最容易产生误解的一点，是注册账号并不等同于创建最终 SAP 用户。当一个人提交姓名、Email、电话号码、用户名等资料时，系统处理的是一个 User Request，也就是用户申请。这个申请带有自己的生命周期。只有申请通过后续激活步骤，User Self Service 才会进入正式用户创建逻辑。这种设计其实很符合企业系统的安全要求。如果提交一次 HTTP 请求就立即生成可以登录 SAP 的有效用户，那么只要注册接口暴露给外部应用，攻击者就可能批量创建账号。通过注册和激活两个阶段
在传统 SAP 项目里，给内部员工创建一个 SAP 用户，很多人的第一反应仍然是事务码SU01。管理员输入用户名、用户类型、角色、参数和初始密码，保存之后账号就存在了。但 User Self Service 面对的场景完全不同。这里的核心需求不是管理员替业务用户建账号，而是允许 SAP Business Suite 的使用者通过前端应用自主提交账号申请，再经过激活流程完成用户创建。整个过程还可能跨越 SAP Business Suite 后端和独立部署的 SAP NetWeaver Gateway 系统。因此，从技术视角来看，它已经不是单纯的用户主数据维护问题，而是一条由 OData 服务、用户申请状态、激活凭据、通知机制、RFC 复制以及 BAdI 扩展共同组成的完整业务流程。SAP 官方定义的标准 User Self Service 用户创建过程包含两个主要阶段，注册用户名和激活用户。只有两个阶段全部完成，真正的 SAP 用户才会在 SAP Business Suite 系统中形成，并按照配置复制到 SAP NetWeaver 系统。这里最容易产生误解的一点，是注册账号并不等同于创建最终 SAP 用户。当一个人提交姓名、Email、电话号码、用户名等资料时，系统处理的是一个 User Request，也就是用户申请。这个申请带有自己的生命周期。只有申请通过后续激活步骤，User Self Service 才会进入正式用户创建逻辑。这种设计其实很符合企业系统的安全要求。如果提交一次 HTTP 请求就立即生成可以登录 SAP 的有效用户，那么只要注册接口暴露给外部应用，攻击者就可能批量创建账号。通过注册和激活两个阶段
