嗨，

我写了一本有关该问题的完整圣经，然后找到了此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执行继续？ 等等...

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

干杯！

嗨，塔尼亚，

感谢您提供有用且有见地的详细信息。

以下是观察以及我在问题开始时所看到的

1）将```TSN_REQUESTED``中的指针设置在正确的位置............我该怎么做??? 这是我想到的问题，有什么方法可以通过FM/prog手动更新TSN_REQ和TSN_CONFIRMED后端的表项，因为我在RSPMREQUEST中找不到任何内容

2）我建议检查它们在ODQSSN中的一致性-是TSN_REQ = TSN_CONFIRMED?。 您看到的每个值的最后一个是什么？ 由于工作选择参数，它们的秒数可能不同。... Y ES 我看到的值是不同的，我没有最新的错误消息，但是这里是 我第一次看到问题时遇到的样本错误。 但是工作选择参数没有区别

3）如果请求失败-我们可以一直保持下去-为什么没有重复重复？ 有人将其设置为绿色（noooooo pls）吗？如果发生故障，为什么允许PC执行继续？

PC失败； 当我们收到这个错误时，它的执行没有继续； 我们删除了红色请求并重复了DTP，但失败了，并显示了相同的错误msg

4）好心的结果，这样我就知道了历史的终结..

我别无选择，只能重新进行一次，这很烦人，令人沮丧，因为我花了一个星期的时间

嗨！ 看看我昨天发现的内容。 2157434 -" RDA_START失败 使用：指针{...}必须首先关闭"" <<这很有意义。 它也声明了open_delta_no_data，但只声明了信息，没有代码更正...稍后再检查。

现在，谈论业务............. TSN_REQUESTED ...因此，要手动输入，则需要我之前给的注释（ 2625466 ）-从官方的角度来看。 注释的代码显示了对该问题的更正。.现在，它向TSN_CONFIRMED分配了与TSN_HIGH相同的值，之前不是这样，因此看起来有些延迟最终可能最终生成"更大的值"。 因此，如果您在表ODQSSN中手动更改它，将无济于事，因为是在表中写入的框架..反之亦然。 在代码中使用的条目更改之后（表的条目），订阅将不会更新。

自己创建一些东西会很麻烦，所以我不相信即使自定义您也能做到。 如果没有该代码，我将删除每个失败的请求，并在DTP中放入delta指针。.我们这样做是为了从BW调试到Source。 因此，假设您删除了所有内容，您可能会使用ODSSN的指针最后TSN_CONFIRMED = TSN_REQ触发另一个初始化，但这也将打开不一致之门……看看有多少个地方（我什至没有检查所有内容） ），您可以看到以下数据：

最后但并非最不重要的一点（在我的测试系统中是快速分析，没什么大不了的）：

如您所见，手动更改这些内容并不是一件容易的事（出于一致性考虑）。

请记住，绝不建议进行此类更改。 我只是以您的示例为例，进一步分析了各个部分如何组合在一起。

通过查看注释 2625466 中的代码更正， 避免它"现在"发生，因为它仅在当前tsn_confirmed不高于当前请求的情况下才进行ODQSSN的更新。

让我知道是否不清楚，这是一个很大的头脑风暴：D

干杯！