亲爱的罗希特，

我有一个理论（参考编号9356）。

来自我的参考资料：

为了提高后端性能， Agentry产品不会将每个Agentry事务都发送到后端进行处理，而是将更改应用于本地对象存储并标记每个更改的对象。 当用户选择传输时，Agentry操作首先循环本地对象集合，并为每个更改的对象创建一个"捆绑的" Agentry事务。
Agentry Client登录工作流程处理用户在登录期间进行更改的情况， 并且该设备先前已在本地数据库中保存但未发送Agentry事务。 在这种情况下，Agentry的"以前的用户"工作流程将执行"以前的用户登录"，以便发送先前保存的交易，并紧跟着新的用户登录。

但是，当交易捆绑时 使用设计模式时，Agentry客户端没有任何本地Agentry事务，这些事务不会触发先前的用户登录。 这意味着对对象存储库的任何本地更改都将被新用户的下一次传输错误地拾取并发送。

为解决上述问题，Agentry团队在SMP 3.0 SDK SP12下所做的工作：

为解决此问题，新的"用户更改操作"将添加到模块定义中。 在Agentry客户端检测到正在进行用户更改之后，但在客户端检查是否有以前的用户事务之前，将立即调用此操作。 期望产品定义将通过创建当前在数据库中为先前用户标记的所有捆绑交易，使用此新操作来"最终确定"先前用户的状态。 这些捆绑交易以及任何现有的常规Agentry交易将由标准的，现有的，以前的用户交易处理逻辑进行处理。

这种方法使产品可以完全支持捆绑交易和设备共享，而无需扩展 捆绑逻辑包括修改每个对象或需要扩展后端发布逻辑的用户，以便能够以与已登录用户不同的用户身份发布事务。

希望以上信息对您有所帮助 。

最好的问候

Mark Pe

SAP白金支持工程师