大部分知识源于TBW350和SAP SDN。

对数据源抽取机制的深入探讨

一、什么数据源需要初始化，为什么要进行初始化

有增量机制的数据源就需要初始化，初始化的目的是为了给系统一个时间点，来生成Delta队列。
怎样进行初始化：其实当我们跑I包的时候，Delta队列就建立了，这个和Setup table没有关系
Setup table是怎么回事儿：在LO（Logistic，后勤）的抽取中，Extractor不允许直接操作应用表，也许是为了方式读写的冲突，也许是为了保证凭证的安全，也许是为了减轻负载…反正就是不行，所以就得在initialization的时候Delete然后Fill Setup table。仅限于LO的数据源。

FI的为什么不用Setup table：因为FI的数据可以直接从Table里抽取。
RSA7(Delta Queue)，这是虚拟的，真实存放数据的是SMQ1 (Out bound Queue)

    所谓的V1、V2、V3有如下解释，这个东西在激活LO数据源的信息结构时可以看到：

V1 同步更新模式，即凭证产生就更新增量，与业务数据同步更新；
V2 异步更新模式，就如一个两步的操作一样，第一步业务凭证更新了，然后再更新第二步的数据源增量表
V3 异步更新模式，与V2的区别在于他的更新时通过后台事件来触发的，即定一个任务定是收集增量并更新至增量表
下图源自LBWE：

这里三种简单的说一下，更新方式的解释详见附件：Gist of LO Cockpit Delta，据说本来还有个Serialized V3，7.0后就被取缔了。

Direct Delta:这是一种V1，直接V1到Delta Queue，我们目前的LO数据源统统采用这个
Queue Delta:这是一种混合型，先V1到Extraction Queue，后V3到Delta Queue
Unserialized V3 Update:这是一种V3，先V3到Update Table，后V3到Delta Queue

来张图，解释下整个过程：

Records在Transaction tables里
在初始化时，执行一个将Transaction data存放在setup table里的setup操作，也就是我们的填充设置表
在执行初始化和Full包时读取的是设置表的内容
新的Transactions被送到Transaction tables，之后被提取到Update tables / Extraction Queue（SM12/SM13），也就是SMQ1
之后呢，会有一个周期性的Job，来把数据提取到Delta Queue中（如果是V1的话就不用啦）
当Delta上载执行时，会去读这个Delta Queue。

二、Delta机制

我们的R/3系统提供了这么一种功能，来标记新旧数据的差别，可以通过Time stamp，Calendar Day，Numeric Pointer来标注。

设置方法：

数据源要提供字段，用来填充Delta Specific Field
RSO2àGeneric DeltaàTime stamp，有需求可以设置Safety Interval Upper/Lower Limit，拓展Time stamp和Calendar Day的边界。
只要在建立数据源的时候设置增量的特定字段，选取时间标记。这里拿ZMAT_ATTR做例子，选的是Calend. Day，Safety Interval Upper Limit是1Calend. Days，New Status for Changed Records，这么说来，就会每天跑一次，每次跑前两天的数据，而且以最后更改的记录为准（这个在下面会说到）。

这样做的效果可以在RSA7里看到，点Generic Delta：Current Status：

很简单，当前的Time stamp。

Notes：为什么不是所有的都有呢？因为这个叫做Generic Delta，可以简单的看一下，LO的数据源一个都没有，那种比较BT，一般来说非后勤和主数据还有自建的数据源都是Generic Delta。

看几张表：ROOSPRMSC，222系统

要了解这张表，还需要知道一个概念叫做LUW，

另外，想看这些请求号，可以到表RSREQDONE，这个要在200系统里。

Notes：咱们用的Time stamp叫做UTC Time Stamp，什么是UTC，等同于GMT，就是世界时，咱们要+8:00，也就是说这个DTP的时间是2009.03.13,08:36:26。

PS：不过和222那边有那么10s的时间差（RSREQDONE表里的时间小10S），我也不知道怎么回事儿，后来查了下03_BF的，也是有10s的差，知道的同志可以告诉我呀。。。当然这些并不重要

接下来几张表：

不多做解释，参照附件BW_DELTA-QUEUE-详细说明，第11页

这个可以用两张表来做解释：

第一个：

这里的四个数据源，分别是LO（后勤），FI，主数据和自建数据源，各有不同。

这里的Delta Process共有20种，于是需要第二张表：

这里的几个列，控制了Delta方式对镜像的操作，序列化方式，Delta处理类型等等。

需要着重的是DeltaType：

E Extractor Delivers OLTP Source Delta——这种方式叫做PULL

一般来说：

CO的数据源都是ADD的，差额镜像，E
FI的基本都是AIE，后镜像，E
LO的基本都是ABR，这个就不用说了，很明细，新、前、后、翻转的镜像都存，量很大，D
自建的默认是AIE，同FI（BT的是没有提供更改方法，所以自建的统一都是AIE），E
主数据的一般采用AIE、AIM和NEWE，说明比较侧重结果和新增数据
下面简述下AIE和ABR的区别：

ABR的方式注定了，不仅适合直接上载到DSO，可以直接上载到CUBE，不通过DSO，因为不仅序列化，而且是连带各种镜像。
AIE不同，只支持后镜像，也就是说，只能首先加载到DSO，然后进行分析，会在激活数据时帮我们补齐前镜像，到DSO的LOG表里，从而保证了DSO的明细要求，又能在CUBE提取LOG表的时候获得正确的数据。因为CUBE只有汇总，没有覆盖功能。
最后还要说明一下，FI与其他模块的数据抽取方式不太一样。

FI是通过BW的请求，到R3中执行对应的FM，然后获得数据，写入DELTA队列，这种方式就叫做PULL。自定义数据源也是这样的方式。一般来说，时间都是1h。如下图：RSA2

对于其他模块，如MM，是通过将数据写入DELTA队列，BW请求后，并不直接读取真实的数据源，而是读取DETLA队列。
对MM，激活信息结构的时候，会让我们选择，更新类型，也就是V1，V2，V3的方式，与FI的抽取方式差别太大，而且需要我们在源系统进行必要的操作。感觉好像不是一批人开发的，实现DELTA的逻辑从本质上不同，SAP的解释是说，对于不能直接实现DELTA抽取的数据源，可以采用这种方式。
另外，关于FI的Delta方式，有如下解释：节选自SAP HELP，另外附件里还有一些Notes，有兴趣可以看下

SAP Tech. Consultant,专注于SAP ABAP, SAP BW, SAP BI.email:yefei@cqcxo.com