企业门户里有一类功能看起来很普通，背后的技术链路却相当长。客户打开注册页面，填写用户名、姓名、邮箱和密码，提交之后收到一封激活邮件，再点击邮件中的链接完成账号激活。从 Web 开发角度看，这很像一个标准的注册接口加邮件验证流程。但放到经典的SAP Gateway架构里，事情会复杂不少，因为账号最终不是只存在于一个普通应用数据库里，而是要进入 SAP 的用户管理体系，还可能涉及SAP Business Suite、SAP NetWeaver、SAP Gateway、后台用户复制、权限模板以及通知机制。SAP Gateway User Self Service就是为这类场景设计的一套能力。SAP 官方文档把用户账号创建明确拆成两个阶段，一个阶段负责注册用户名，另一个阶段负责激活用户。注册和激活都由/IWBEP/USERREQUESTMANAGEMENT这个OData服务承载。经典架构中，当整个流程完成后，用户会在SAP Business Suite系统中创建，并按照配置复制到SAP NetWeaver系统。SAP 也明确说明，标准User Self Service并不直接支持Multiple Origin Composition，如果存在多个后台系统，可以借助相应的BAdI扩展用户复制和通知逻辑。这里有一个很容易被忽略的概念，UserRequest并不等同于最终的 SA
企业门户里有一类功能看起来很普通，背后的技术链路却相当长。客户打开注册页面，填写用户名、姓名、邮箱和密码，提交之后收到一封激活邮件，再点击邮件中的链接完成账号激活。从 Web 开发角度看，这很像一个标准的注册接口加邮件验证流程。但放到经典的SAP Gateway架构里，事情会复杂不少，因为账号最终不是只存在于一个普通应用数据库里，而是要进入 SAP 的用户管理体系，还可能涉及SAP Business Suite、SAP NetWeaver、SAP Gateway、后台用户复制、权限模板以及通知机制。SAP Gateway User Self Service就是为这类场景设计的一套能力。SAP 官方文档把用户账号创建明确拆成两个阶段，一个阶段负责注册用户名，另一个阶段负责激活用户。注册和激活都由/IWBEP/USERREQUESTMANAGEMENT这个OData服务承载。经典架构中，当整个流程完成后，用户会在SAP Business Suite系统中创建，并按照配置复制到SAP NetWeaver系统。SAP 也明确说明，标准User Self Service并不直接支持Multiple Origin Composition，如果存在多个后台系统，可以借助相应的BAdI扩展用户复制和通知逻辑。这里有一个很容易被忽略的概念，UserRequest并不等同于最终的 SA
