BW-LO抽取详解

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

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

2) To avoid interdependency, while still making changes transactional tables in R/3.

3) Customized cluster and pool tables enhancing extraction easier.

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

V3 Update Mode

1、Based on your delta updated mechanism, it will be either V1 or V2 or V3

2、Delta tables will be based your delta updated process ,it will be either Extraction queue or Update tables and the collective run will be either extraction collective run or V3 collective run

    

    所谓的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机制

Time Stamp

我们的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，

LUW is logical unit of work. The qRFC outbound queue controlled using an Outbound Scheduler (QOUT Scheduler). The QOUT Scheduler prompts the transfer of a LUW to a target system when all previous LUWs in this queue have been processed. When one LUW has been executed, the QOUT Scheduler automatically executes the next LUW in the queue.

In other words when we request delta load from BW, Source system will identify the last delta records which are in form of TID's by using ROOSPRMSC table and it will delete previous confirmed LUWs(repeat delta table) and Process new LUWs(delta table)

另外，想看这些请求号，可以到表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的差，知道的同志可以告诉我呀。。。当然这些并不重要

接下来几张表：

ARFCSSTATE

ARFCSDATA

TRFCQOUT

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

BW Delta Process

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

第一个：

ROOSOURCE

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

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

RODELTAM

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

需要着重的是DeltaType：

D Generic Delta for Service API

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

means the delta data records are determined during the delta update by the data source extractor, updated to the delta queue and passed on to BI directly from there.

一般来说：

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，有兴趣可以看下

Delta Method

Delta extraction enables you to load into the BW system only that data that has been added or has changed since the last extraction event. Data that is already loaded and is not changed is retained. This data does not need to be deleted before a new upload. This procedure enables you to improve performance unlike the periodic extraction of the overall dataset.

Financial Accounting line items are read by extractors directly from the tables in the SAP R/3 system. A time stamp on the line items serves to identify the status of the delta data. Time stamp intervals that have already been read are then stored in a time stamp table. The delta dataset is transferred to the BW system directly, without records being transferred to the delta queue in the SAP R/3 system (extractor delta method).

The Financial Accounting line items are extracted from the SAP R/3 system in their most recent status (after-image delta method). This data method is not suitable for filling InfoCubes directly in the BW system. To start with therefore, the line items must be loaded in the BW system in an ODS object that identifies the changes made to individual characteristics and key figures within a delta data record. Other data destinations (InfoCubes) can be provided with data from this ODS object.