• 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 发现出错的请求

    1. 看job。
    2. 在SLG1里面看数据抽取日志,object ODQ,sub-object Extraction。
    3. 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
    在这里插入图片描述
    三个保留时段:

    1. 对于已经被客户用DTP拿走的,或者说人家取消不要了的。这个请求数据会被标志成retrived 或者 invalid。默认24小时内保留,24小时后的删除。在24小时内,可以再重新抽被cancel掉的请求。
    2. 对于所有低相关性的请求,不管有没有被拿走或者被取消,10天后删除.
    3. 中等相关性的,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…
    待续…权限不够…

  • 相关阅读:
    哪个更快?document.addEventListener VS element.addEventListener
    ELK企业级日志分析系统
    完美解决多种情况下的 java.lang.NullPointerException 的异常
    Flutter高仿微信-第21篇-支付-向商家付款(二维码)
    springboot 集成 zookeeper 问题记录
    PPT目录页怎么设计才高大上?告诉你一个万能排版法!
    操作系统简介(下)
    堆排序和优先队列
    uniapp搭建项目
    web前端——javaScript
  • 原文地址:https://blog.csdn.net/weixin_45689053/article/details/126095412