2

I build an app that is able to store OData offline by using SAP Kapsel Plugins. More or less it's the same as generated by WEB ID or similer to the apps in this example: https://blogs.sap.com/2017/01/24/getting-started-with-kapsel-part-10-offline-odatasp13/

Now I am at the point to check the error resolution potential. I created a sync conflict (chaning data on the server after the offline database was stored and changed something on the app and started a flush).

As mentioned in the documentation I can see the error in ErrorArchive and could also see some details. But what I am missing is the information of the "current" data on the database.

In the error details I can just see the data on the device but not the data changed on the server.

For example:

  1. Device is loading some names into offline store
  2. Device is offline
  3. User A is changing some names
  4. User B is changing one of this names directly online
  5. User A is online again and starts a sync
  6. User A is now informend about the entity that was changed BUT:
    • not the content user B entered

I just see the "offline" data.

Is there a solution to see the "current" and the "offline" one in a kind of compare view?

Please also note that the server communication is done by the Kapsel Plugin and not with normal AJAX calls. This could be an alternative but I am wondering if there is no smarter way supported by the API?

Meanwhile I figured out how to load the online data (manually). This could be done by switching http handler back to normal one.

sap.OData.removeHttpClient();
sap.OData.applyHttpClient();

Anyhow this does not look like a proper solution and I also have the issue with the conflict log itself. It must be deleted before any refresh could be applied.

I could not find any proper documentation for that. Also ETag handling is hardly described in SAPUI5 and SAP Kapsel documentation.

4

2 回答 2

2

由于其含义，这个问题非常棘手。我了解您正在模拟由于并发修改导致的同步错误，并想知道客户端是否有办法获取“当前”服务器状态，以便为用户提供一种比较本地和服务器状态的方法。

首先，让我给你一个简短的回答：不，当出现同步错误时，客户端无法通过离线 API 看到当前服务器状态“以供参考”。如上所述进行在线查询可能会奏效，但这肯定是个坏主意。

现在是更长的答案，这解释了为什么这不一定是缺陷以及为什么我说答案有相当多的含义。

同步错误的类型

我们区分了许多同步错误，在这种情况下，我们显然是在处理与业务相关的问题。这里有两个子类型：用户可以更正的子类型，例如验证错误，以及业务流程本身的问题。

如果用户违反了输入范围，例如通过为产品输入负价格，服务器将回复相应的消息：“-1 不是'Price' 的有效输入值”。作为开发人员，您可以从错误存档中向用户显示此类消息，随后的修复确实非常简单。

现在，当我们谈论并发修改时，事情变得非常非常糟糕。事实上，我想说的是，在这种情况下，业务流程存在问题，因为一方面，我们允许数据不同步。另一方面，该过程允许多个用户操作同一条信息。现在应该如何通知和同步所有相关用户，不再只是一个技术细节，而是一个新的业务流程。只是没有办法通用设备如何处理这种情况。在大多数情况下，它将涉及需要决定如何合并更改的后台专家。

更好的解决方案

Angstrom 指出，没有办法在客户端操作 ETag，实际上您甚至不应该考虑它。ETag 在乐观锁定场景中的工作方式类似于版本号，更改 ETag 基本上意味着“只需覆盖服务器上的内容”。在严重的情况下这是不行的。

可接受的解决方法如下：

  1. 确保服务器返回详细的错误消息，以便用户可以看到发生了什么以及导致冲突的原因。
  2. 如果这没有帮助，请刷新数据。这将为您提供更新的 ETag，并将本地更改合并到“当前”服务器状态，但仅限于本地。“合并”实际上意味着本地更改总是会覆盖远程更改。
  3. 用户现在有另一个机会查看数据并可以再次提交。

一个好的解决方案

更好不一定是好的，所以这是你真正应该做的：永远不要让并发修改发生，因为它处理起来真的很昂贵。这意味着不是开发人员应该解决这个问题，而是业务需要改变流程。

正确的问题是，“当您在分布式系统中复制数据时，为什么要允许它同时被修改？” 通常利益相关者不会喜欢这种问题，适当的反应是与他们一起制定解决冲突的过程。只有到那时，他们才会意识到修复这种去同步化是多么昂贵，而且他们通常会看到调整流程比坚持另一个后台流程来解决它导致的问题要便宜得多。即使他们坚持认为需要同时进行修改，他们现在也会明白，解决这个问题不是您的任务，他们需要投资于解决冲突的过程。

TL;博士

无法将服务器和客户端状态与客户端上的服务器状态进行比较，但您可以进行刷新以保留本地更改并获取更新的 ETag。然而，真正的解决方案是重新设计业务流程，因为这不再是一个纯粹的技术问题。

于 2017-03-27T15:13:57.007 回答
1

默认解决方案是 SMP 或 HCPms 通过 ETags 检测错误。在客户端，没有 API 可以在发生冲突时操作 ETag。在设备上实现一种差异视图的潜在解决方案如下：

  1. 显示错误
  2. 缓存错误（可能只在内存中？）
  3. 删除错误
  4. 刷新数据库
  5. 使用当前数据和缓存的错误构建差异视图

这个想法与

sap.OData.removeHttpClient();
sap.OData.applyHttpClient();

也可以工作，但可能非常棘手并且可能会引入副作用。也许一些请求是针对“错误”的后端触发的。

于 2017-03-24T13:01:09.417 回答