解析BW:數據源提取數據的原理

題記：忽然想到這么個問題，后勤數據源和非后勤數據初始化有何區別，然后進行周邊的拓展，所以就形成了下文。大部分知識源于TBW350和SAP SDN。?

對數據源抽取機制的深入探討

一、什么數據源需要初始化，為什么要進行初始化

有增量機制的數據源就需要初始化，初始化的目的是為了給系統一個時間點，來生成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.

總結

以上是生活随笔為你收集整理的解析BW:数据源提取数据的原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。