• BW:BW增量更新方法(假增量)


    1 说说假增量


    我们都知道,对于BW来说,很多ECC的标准数据源自带了增量更新功能,每天各种凭证产生的增量数据会自动堆积到增量队列里,然后BW端做一个增量信息包按天把这些增量抽取到数据仓库里,非常轻松自然,对于客户和顾问,都是透明的自动的容易实施的,这也是上过ECC的企业数据仓库采用SAP BW的一个优势所在。

    但是对于非ECC的一般数据库或者ECC的自定义数据源,做增量更新就苦了。对于ECC的自定义数据源,SAP给了一种标准方案,我们看看这种方法:用一个时间字段或数字字段标记增量,当这个字段在表里的数值变化时,就认为是增量,把这条记录作为增量记录,增量信息包会挑出这些记录传送上去。这种方法的问题是显而易见的,不管是时间还是数字字段,我们都需要ABAP工作者额外编程去控制这个字段的变化,这样才能正确让系统选择出增量(用表中的凭证创建日期等字段作为时间字段去控制是不可行的,因为你不能保证今天不会修改昨天的数。)对于非ECC的一般数据库连接,SAP很干脆的说,不支持增量(06年是这么讲的,以后支不支持不晓得)

    总结一下,在不同的数据源下,对增量的支持是这样的 :


    因此,对于不支持或不好实现增量的情况,我们比较推荐的方法是,使用带选择条件的完全抽取信息包,每一次定期抽取之前N个月的数据(前提是客户保证,不修改N之前月的数据),然后上传到DSO中,如果这N个月的数据没有变化,则会被覆盖掉,系统当什么事都没发生;如果有变化,则会把变化部分覆盖DSO相同主键的数据,然后记录到DSO的更改日志表,再往CUBE中传变化部分(当然:DSO到CUBE的DTP要设置成增量DTP),这样,就以比较小的抽取时间的代价(每天只要抽最近N个月,N尽量小的数据),换来了增量抽取的几乎全部优点(每次抽取时间比较短,数据量小,传到CUBE也同样只传增量部分)。这种做法,SAP 官方教材极力推荐,见下图(取自教材350增量更新一章最后一节),BW江湖人送外号假增量即是此种方法。

    比如说,每天抽取最近两个月的数据,在信息包里我们可以这么写例程去控制(时间选择字段为T_DATE):

    data: l_idx like sy-tabix.
    data: tmp_date type d.
    read table l_t_range with key fieldname = 'T_DATE'.
    l_idx = sy-tabix.
    tmp_date = sy-datum - 60.
    l_t_range-high = sy-datum.
    l_t_range-low = tmp_date.
    l_t_range-sign = 'I'.
    l_t_range-option = 'BT'.
    modify l_t_range index l_idx.
    p_subrc = 0.

    这样最近两个月的数据每天抽取,每天覆盖,再利用DSO的更改日志表,就实现了“假增量”。

    如果数据源对应的不是DSO,是CUBE,那么就无法使用更改日志表,BW也给我们一种实现假增量的方式,见下图:

    解释一下这个图,CUBE里的数据是不能覆盖的,所以,如果要每天抽取部分数据的话,必须要把上次相同抽取条件(比如:今年)的数(请求)给删掉,这个我们可以在处理链里设置:删除信息块中的重叠请求:

    一般来说,数据源都是先把数传递到DSO再到CUBE,每次删除重复请求感觉上也不是很安全,所以上述方法使用的不多。

    先到DSO再到CUBE,每一次用程序抽取最近N个月数据的这种假增量方法看似比较完美,其实背后隐藏了一个极大的问题,即用户在源系统物理删除的那部分记录如何在BW也每天自动删除掉。原系统物理删除掉的记录,BW在抽取过程中是无法自动识别的,在DSO的更改日志里当然也体现不出来,CUBE端肯定也不会自动删除掉,这个如何处理?放任不管是肯定不行的,在这次首钢项目的开始,项目组就提出了这个问题,要求给出合适的解决方案。

    1 让客户最偷懒的,解决物理删除问题的假增量方案

    解决方案经过研究,可以有以下两种主要思路。第一种,由开发源系统的客户方维护人员,在视图里增加一个删除标记,每一次数据删除了,都打上这个标记,BW抽取上来后,在报表里设置条件,凡是有这个标记的数据,就不显示出来。这种方案的问题在于客户必须要修改它那边源系统的代码,很多时候,客户想偷个懒,不太愿意改,这种方案需要客户配合,也不是标准的解决方案。第二种方法,在BW这边识别,并在抽取时自动进行处理,这样客户什么也不需要做,相当舒服,但是BW这边如何能尽量方便的处理,就得综合考虑一些问题了。

    问题一: BW如何找出被物理删除的记录?

    可以在开始例程里统一判断,即把开始例程的SOURCE_PACKAGE和DSO中相关记录进行比对,DSO中有,而SOURCE_PACKAGE找不到的记录,即可认为是删除,例程如下:

    SELECT * FROM /bic/az3pp_o0900 INTO TABLE it_dso.

    LOOP AT it_dso INTO st_dso.

    READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =

    st_dso-calday.

    IF sy-subrc <> 0.

    “ 确认删除,此处开始处理问题二

    ENDIF.

    ENDLOOP.

    问题二: 找到被删除记录后,怎么能让DSO的更改日志知道这条记录被删除了?

    我们知道,DSO的更改日志会自动把这一次的数据和上一次的数据进行比对,把差异记录在日志表里,再传递到CUBE中,因此,我们可以考虑,手工把被删除数据的关键值统一设置为0,这样,假设原来关键值是15的话,DSO会被覆盖成0,DSO的更改日志表会变成-15,再传到CUBE中就是15 +(-15)= 0了。这样等于针对删除记录自动产生了反冲记录,可以同时保证DSO和CUBE数据的准确性了(DSO和CUBE该记录都为0了),例程如下:

    LOOP AT it_dso INTO st_dso.

    READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =

    st_dso-calday.

    IF sy-subrc <> 0.

    st_source-STAT_DATE = st_dso-calday.

    st_source-L4_FACILITY_ID = st_dso-plant.

    st_source-L4_WORKCENTER_ID = st_dso-workcenter.

    st_source-EQPT_OUT = 0.

    st_source-EQPT_SCRAP = 0.

    st_source-SACRPT_HRM_INPUT = 0.

    st_source-SALE_OUT = 0.

    st_source-SALEMAT_HRM_INPU = 0.

    st_source-record = tmp_record.

    APPEND st_source TO SOURCE_PACKAGE.

    ENDIF.

    ENDLOOP.

    注意,上述例程中非关键值要设置成和原先一样,关键值都要设置成0.

    完整例程如下:

    DATA it_dso TYPE TABLE OF /bic/az3pp_o0900.

    DATA st_dso TYPE /bic/az3pp_o0900.

    DATA st_source TYPE _ty_s_sc_1.

    DATA tmp_record TYPE rsarecord.

    SELECT * FROM /bic/az3pp_o0900 INTO TABLE it_dso.

    READ TABLE SOURCE_PACKAGE INTO st_source INDEX 1.

    tmp_record = st_source-record.

    CLEAR st_source.

    LOOP AT it_dso INTO st_dso.

    READ TABLE SOURCE_PACKAGE INTO st_source WITH KEY STAT_DATE =

    st_dso-calday.

    IF sy-subrc <> 0.

    st_source-STAT_DATE = st_dso-calday.

    st_source-L4_FACILITY_ID = st_dso-plant.

    st_source-L4_WORKCENTER_ID = st_dso-workcenter.

    st_source-EQPT_OUT = 0.

    st_source-EQPT_SCRAP = 0.

    st_source-SACRPT_HRM_INPUT = 0.

    st_source-SALE_OUT = 0.

    st_source-SALEMAT_HRM_INPU = 0.

    st_source-record = tmp_record.

    APPEND st_source TO SOURCE_PACKAGE.

    ENDIF.

    ENDLOOP.

    这样的方案,我们每一次都只需把数据源到DSO的转换增加一个类似的开始例程,所有物理删除的问题就可以得到统一的解决了。以后有少数字段调整,修改起来也比较方便。对源系统那端的开发人员,工作量=0,对BW顾问,工作量也很小:)

    写了这么多,总结一下,用户物理删除(无删除标记的)的假增量方案,也就是如下两步而已:

    1) 每次抽取最近几个月的数据到标准DSO再到CUBE,

    2) 从数据源到DSO的转换增加一个开始例程,把每次传输源系统删除的数据找出来,以关键值为0的形式更新到后续的数据目标中。

    2 备注:

    关于这种场景,SAPBW350的标准教材里说到一种方法,好像就是我本文这个意思(写的非常简略,我这篇文章把它细节化了),还有一种可能是手工把RECORDMODE这个字段设置成D或者R(删除或反转映像?)的意思,教材没有提!我们这种做法经过实验是肯定可以的,手工设置RECORDMODE字段如果可行的话,应该更节约代码量….留待大家挖掘。。。

    教材原文:

    请关注最后两句!我是写这篇文章的时候去翻教材才发现的,具体方法应该就是本文这种或者备注猜测的那种。

    本文说了那么多,教材这两句竟然给概括掉了,真牛!有的时候想想,SAP官方教材还真是有很多闪光点的,窝在一些无人关注的角

  • 相关阅读:
    深入分析 Java 中的中文编码问题
    随便写写20160411
    Linux GDB 程序调试工具使用详解
    「美国花好几亿造出太空圆珠笔后,发现苏联航天员用铅笔」的故事真实吗?
    verynginx部署
    harbor私有仓库部署
    rancher学习
    harbor部署
    zabbix-proxy docker
    NFS部署
  • 原文地址:https://www.cnblogs.com/hanmos/p/2629082.html
Copyright © 2020-2023  润新知