Debug一个ECC的ODP数据源

一个用抽取器提取的数据源。
在RSA3里进行测试提取的时候，可以来debug一下看底层代码。
这个RSA3不适用于S/4HANA的CDS View数据源。

每个Call是一个数据包，records是一个包里多少条数据。

这里会有一个问题，即使你这里数据源提取数据没问题，但是我们到时候是ODP提取数据的，咋知道有没有问题呢？
首先得去RSA6看看，不要你想传过去的字段是hidden的状态。

如果我想去从BW的角度测试这个数据抽取和获取有没问题，咋办？
用这个program：RODPS_REPL_TEST

在了解这个report怎么用之前，你得知道ODQ这个队列，专门给ODP准备的这个队列是咋工作的。

ODP和ODQ是怎么干活的

最基本的，就是现在ODP可以直接用DTP给连到BW的ADSO里了。整个流程看起来就是数据源到ODP，到ADSO。
而且一个ODP可以给多个ADSO做源。在每个源和目标直接，可以有一个转换。
当DTP开始执行的时候，就是说要直接向数据源要数据了，向ECC的data extractor要数据。啥意思呢？就等于说这个DTP立马去建了一个view，然后去读这个view的多个底表的数据去了，或者等于说它建了一个ABAP程序去底表读数据去了。你其实去看DTP的filter就能看到，它有好多where语句，去读数据去了。
然后数据是怎么传过来的呢？
是通过ODQ传过来的。
ODP有个数据复制接口，Full是一直OK的。那Delta的数据怎么弄？
对于一个转换，我们是可以建多个DTP的，建一个Full再建一个delta。
我去要求的数据要到了，要拿过来，会先放到ODQ里面。这个ODQ怎么理解？
我理解是一个仓库。
是位于源系统的一个仓库。这个仓库分三个房间，分别是
ODQDATA_C 存放所有压缩的初始化请求数据
ODQDATA_F 存放所有压缩的全量请求数据
ODQDATA 存放所有的压缩的增量请求数据

这个仓库有个管理系统，叫ODQMON。
管理仓库所有出货单（DTP请求）。

首先有了出货单，仓库才能去配货入库。
存在仓库里的都叫queue。
有些LO的货呢，是自动被push到仓库里的，源系统里有个更新流程。
有些FI的货呢，是被pull进来的，用的是抽取器接口。

queue的名字，一般都是数据源的名字。
客户有些是BW，有些是Odata，还有SAP DATA services等等SAP HANA的SDA啥的。
咱这就是BW是客户，通过DTP去要数据。
BW客户要找queue去要数据货，要来的数据呢，到BW里还要继续加工的。当我BW去要一次了，就会有一个Subscription，一个订货单。这个订货单有个唯一的编号，叫TSN。以时间为名。

我一个客户呢，可以有好多个订货单啊，可以有不同的DTP找它要数据。

我这个queue里面可以存放delta的数据，给客户提供。或者两三个客户提供。
我可能还有另外的客户，不止需要delta的数据，还要所有的full数据。那这种情况下呢，我这个Full的DTP请求，它就不叫一个subscription了。不叫一个订货单了。一锤子买卖，没有后续订货。

我这个ODQMON看delta的queue呢，因为每天都有，不能说我每天都保存在我这个queue里面啊。queue里面只保留delta的数据一段时间，等所有客户都拿完了这个delta的数据，我过一段时间就删除了，给仓库腾地方了。这个时间，可以咱们自己控制。

那么这个仓库管理系统ODQMON都管理些啥呢？

ODQMON里管理什么

queue

每个queue就是每个数据源。这个queue里就是保存数据包（unit），总的列数，数据量的。还有最小和最大的TSN。序列号。

subscription

这个就是客户了，DTP。

requests

就是跑了多少个DTP，上面的DTP，可能一天跑三次的。一天就会有三个requests.

units

数据包，一共多少个数据包，每个包里头多少数据条目。这里头能看到具体的数据。

当你去看一个request的时候，会发现有个composite request，还有个extrations request。是啥意思？

理论上讲如果你有多个数据源，被组合到一个DTP里，那会有一个composite request. 而一个extraction request 就是把queue数据源的数据给传递到queue仓库的一个request。

这样看来呢，其实它们就是两个在ECC里面的request，那么跟BW的DTP里面的request是没有关系的。BW的DTP开始时间要早于composite request, 结束时间要晚于extraction request.

而在queue的请求里的TSN又是啥呢？暂时来看，如果点击进请求就会发现，实际上extractions request的时间记录的是这个提取数据开始的时间，而TSN记录的是所有数据被传输到queue的仓库的最后时间戳。
所以Upper limit for TSN是晚于Extractions request的。
那么下次的DTP开始的时候，上次的upper 就会变成这次的lower，直到extraction request结束的时候，把里面的数据都附上提取结束的时间戳。
如果没有提取到任何数据，那么lower 和 upper还保留上次的时间戳。

整个流程就是如上图。
DTP开始请求，然后生成Composite request,再接着去提取数据，生成extractions request，数据提取到queue的仓库以后，附一个时间戳 upper limit for TSN 。
准备好了后，把数据传到BW，最后DTP完成。

ODQMON 发现出错的请求

看job。
在SLG1里面看数据抽取日志，object ODQ，sub-object Extraction。
reschedule 出错的请求。抽取进程延迟60秒，在此期间可以在SM50里查看进程。
之前的文章有写。
link
这个小旗子
用来关闭未确认的和cancel掉的客户。比如BW端请求断掉了。
比如系统无法抽取delta了。这就得排查啥原因了。

对于已经被抽取的queue里的请求，它会有个保留时间，过了时间会有个cleanup job来删掉。JOB的名字呢：ODQ_CLEANUP

已经被抽取的Delta请求，24小时就删了。
低相关性的10天删。
平均相关性的30天删。

ODQMON里面请求如何被删

在理解它这个queue里面怎么删请求。要先知道，肯定有三种请求。
分别是初始化请求，全量请求和增量请求。

我为什么要去删这些请求？
这每个请求都是去请求了一大批数据啊。长时间保存在我这个ODQ的仓库里，我仓库都没地方存储新数据了。
那这三类请求肯定要删。

首要是删除已经被客户要了的数据。或者客户已经取消不要了的数据。这个默认时间是24小时。
系统时间01:23:45后台删除job启动。
当然这个job的开始时间和频率可以在SM37改的。
淡然这个数据保留时间也是可以改的。
在ODQMON的里面，或者是se38 ODQ_CLEANUP

三个保留时段：

对于已经被客户用DTP拿走的，或者说人家取消不要了的。这个请求数据会被标志成retrived 或者 invalid。默认24小时内保留，24小时后的删除。在24小时内，可以再重新抽被cancel掉的请求。
对于所有低相关性的请求，不管有没有被拿走或者被取消，10天后删除.
中等相关性的，31天删除。

这个数据如果是业务相关的，重要的，如果没有被拿走，那就会一直保留。现在呢，所有的delta请求的队列都是业务相关的。只要没有被客户拿走的，就会一直被保留在系统里。
但是对于增量初始化请求，和全量请求，那就是低相关性，要不然数据量太大了。
差不多明白了，我们再回过头来看，怎么去debug一个ODP数据源。

怎么Debug一个ODP数据源

为啥要去debug它？实际上这个流程就像你去BW建一个数据源到infoprovider的DTP。有了这个DTP，也就是有了个subscription，也就是有了个订货单。然后ECC开始把数据按照前面图上的1,2,3，4,5去拿数。

但是我现在是debug。我不在BW系统建DTP的情况下。让ECC以为我有一个DTP请求。
这个就是要去程序RODPS_REPL_TEST

它这个是一个独立附加的subscriber，也就是说不是单纯的模拟。ODQMON里面的queue是会实打实的把数据传过来的。
请求也会最后被ODQ的clean-upjob给请清理掉的。
所以万一你去用初始化请求，那你要重置这个subscription的。因为你后续的delta queue它会因为没有被所有的DTP按时拿走，会一直被当成业务相关数据放在ODQDATA这个表里。那就仓库地方不够了哦。

到这里就进入到debug 一个ODP数据源了。
进Tcode-SAAB…
待续…权限不够…