点击此处--->   群内免费提供SAP练习系统（在群公告中）

加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）

你好

我们正在尝试构建一个品牌的Windows客户端，该客户端可以携带Agentry.DB。 这是非常必要的，因为我们要在复杂表中引入大量数据。 我们希望一次获取数据，并在我们的用户社区中分发品牌客户，这样我们就可以节省第一次同步应用程序所需的时间。 否则，首次加载应用程序可能需要10到15分钟的时间。

我们正试图通过包含一个已导出的SAP Work Manager 6.4 Agentry.DB文件来对Windows Agentry客户端（70.15.2）进行品牌化/自定义。

SAP Work Manager 6.4应用程序已托管在SMP 3.0服务器（开发版）上。

A）导出Agentry.DB文件的步骤

• 设置"代理配置"中未加密的数据库。
• 运行标准的Windows客户端，完成同步并从客户端导出.DB文件。
• Agentry.DB文件已由用户" USER01"导出

B）塑造客户品牌的步骤

在此消息中附加了名为" Agentry Client Branding Instructions.docx"的文件。

C）"应用程序（代理层）侧的代理配置"中的其他设置

• 1）复杂表已设置为在用户更改时不重新加载
• 2）数据表已设置为在用户更改时不重新加载。
• 3）在应用程序设置中，将复杂表设置为"每周检查一次"
• 4）数据表在应用程序设置中设置为"每次传输都签入"

D）后端"配置"面板中的其他设置

• 1）将每个复杂表的TABLE_CHECK参数设置为0
• 2）TABLE_REFRESH参数设置为168（1周）设置

E）预期功能在为客户添加品牌并将其与预建数据库（Agentry.DB）耦合之后

预计，品牌客户将不再从后端同步所有必需的复杂表数据。 预期将从脱机数据库" Agentry.DB"中获取所需的数据。 根据维护的配置，它应该每周仅一次检查复杂表中数据的更新。

F）非标准配置和修改

• 1）复杂表的定义没有变化。
• 2）在强制执行每次执行时将复杂表重新加载（对willRebuildTable（）方法的显式增强）方面，未对Java POJO类进行任何修改

G）面临的问题：

1）当除导出Agentry.DB文件的用户以外的其他用户（在本例中为USER01）尝试启动品牌客户端并使用其凭据登录时-客户端尝试为所有客户端同步数据 复杂的表格。 客户端未引用脱机数据库（agentry.DB），而是尝试从后端获取所有内容。 这与维护设置不一致，即当用户更改时，不会强制重新加载复杂表。

2）当同一用户（在本例中为USER01）尝试启动品牌客户端时，客户端不会从后端加载复杂表。 而是从本地包含的Agentry.DB文件中读取数据。 读取复杂的表和UI定义后-尝试获取事务数据-在这种情况下：工作单，通知等。

让我们假设离线数据库（Agentry.DB）总共为用户提供4个工作订单。 我们在后端为同一用户创建一个工作单。 当客户端尝试获取工作单时，它只会带来脱机数据库中包含的工作单。 它不会从后端读取较新的工作单。 这与标准配置不符，在标准配置中，客户端应在每次传输中检查数据表。

H）到目前为止我们已经尝试过的事情：

1）在发现复杂表数据仍然依赖于最初导出Agentry.DB的用户时-我从Agentry.DB文件中删除了用户的加密详细信息。 我在第三方数据库文件浏览器中打开了Agentry.DB文件，检查了名为" exportinfo"的表。 删除了针对AgentryUserSalt和AgentryUserHash存储的值。

这迫使Agentry Client不考虑先前从Agentry.DB文件中登录的用户。 当我们切换用户时，该解决方案也对我们有用。 现在，用户USER02可以登录并获取复杂表中的数据，而无需与后端进行排序。

但是，此解决方案又产生了两个问题：

i）离线同步是命中还是未命中。 我观察到它在开始的3-4天内可以正常工作，而无需返回到复杂表数据的后端。 有时，在某些计算机上，它不起作用。 在所有机器上运行3-4天后，它肯定会停止工作。 这意味着它将返回到后端以同步复杂表。

这仍然与复杂表的"每周检查一次"的维护配置不符。

ii）：遗漏工作单（G节中的问题2）的问题仍然存在。 它无法获取为新用户（USER02）指定的工作单，而是读取为较早用户（USER01）导出的工作单。

2）使用TABLE_CHECK和TABLE_REFRESH参数的设置，但是从后端获取数据仍然不稳定。 Branded Agentry Client将随机获取复杂的表数据。

3）编辑了Agentry.DB文件中复杂表的lastUpdate时间。 将其设置为NULL。 这没有帮助。

我们希望确保在初始同步期间从脱机数据库（agentry.DB）读取的内容是一致的。 但是，同步行为非常不稳定且令人困惑。