嗨，

我写了一本有关该问题的完整圣经，然后找到了此SAP注意： 2625466 -基于ODP源创建DTP实时请求失败，但发生异常。 这是对此问题的更正，似乎它已经在过去的xD中发生过

对于任何有兴趣的人...或者如果您尽管有注意事项仍需要解决此问题...我是从ODQMON的观点出发的，我不是WHM（流程链，流式传输等）的专家。

首先，检查您收到的消息：

a）"无效条目TSN_CONFIRMED> TSN_REQUESTED" =这意味着您正在从过去已经请求并加载增量数据的时间请求增量。 如果此订阅具有用于"过去"的TSN，则如果允许此操作，则该机制将完全混乱。 说明：TSN以顺序方式对写入队列的数据进行排序，因此TSN不允许将增量数据写入已经占用的空间（即使不再存在，例如，按时间顺序占用的空间）。

b）...."无法完成open_delta_no_data操作" =它试图说这里没有更多数据要加载-无论如何这都不是可行的TSN指针，因此"程序"无法解释为什么 但是，这些错误消息通常会得到改善，您可以使 2622317 申请利用这一优势。 C。 "有没有办法从源ODQMON手动处理这些订阅？" =从我的立场出发，我想将TSN_REQUESTED中的指针设置到正确的位置（==或>到TSN_CONFIRMED``），或者将TSN_CONFIRMED <= TSN_REQUESTED（这可能会导致重复） 数据，我可以考虑一致性的问题...因此选择第一个）。

->在更改任何内容之前，我将检查以该TSN指针开头的数据是否已经在BW中（检查ODQMON与Request监视器中的作业，看起来该负载已经存在，但当前没有负载（这是 如果失败，则可以从此处删除请求并转发并再次执行此加载。

当我说请求而不是订阅时，我希望我对你很了解。 您可以有多个类似的订阅，但是在一个订阅中，您将收到请求。 它们*不得重叠*。 但是，这种对数据的调用是从BW端完成的，并且只有在有新数据可供提取时才完成。

->这使我认为您的BW请求失败（从现在开始，我指出了可能的根本原因，因为我发现了 2625466 以上。这个假设的请求进入了源系统，这项工作很好地进行了，但是并没有得出结论 BW（例如，由于超时！它将在源上完成并设置TSN，但是在BW中，负载将保留在不成功的旧TSN上。当发布新数据时，BW使用旧TSN失败而去了那里） ，然后开始出现许多不一致（上帝知道扩展名）如果ODQDATA中有新信息，则实时守护程序将通知订户（BW）有关新数据并更新ODQ表（如ODQSSN和ODQREQ）。 我建议检查它们在ODQSSN中的一致性-是TSN_REQ = TSN_CONFIRMED ?.您看到的每个值的最后一个是什么？由于作业选择参数，它们可能在几秒钟内有所不同 ..如果请求失败-我们可以一直保持下去-为什么没有重复重复？ 有人将其设置为绿色（noooooo pls）吗？如果发生故障，为什么允许PC执行继续？ 等等...

请随时与我们分享您的疑问和结果，以便我了解历史的终结..

干杯！