BW之資料來源增量管理DELTA

SAP中的增量機制，可以有助系統提高資料幫浦效率，在初始化執行後，每天只更新新增和修改了的記錄。在我們正常的使用或開發中，這些東西並不需要知道，只要資料正常上傳，就好了，此處所介紹的內容之為大家參考用。

在介紹DELTA機制之前，先介紹下DSO和CUBE：
DSO：一般DSO用來儲存詳細資料，其結構比較簡單。對於值的轉換（決定了可用的DELTA類型），既可以使用合計，也可以使用覆蓋的方式。啟用DSO後，其在後台對應3個資料表：
A表，存放了最後啟用的資料。即存放了匯總後的資料。
LOG表：儲存了資料變化的資料記錄
N表，NEW表，臨時存放更新的資料，待啟用後，將資料轉入A表和LOG表
以上資料表，可以通過在SE11中，描述中搜尋DSO技術名稱找到

CUBE：典型的星型結構描述。CUBE只支援資料值的合計上傳。
建立了CUBE之後，可以到SE11中，通過在表名中搜尋CUBE的名稱，找到對應的維表和事實表。

同樣都是資料模型，而DSO更多用於儲存詳細資料，星型結構描述的CUBE更適合作為分析資料源。關於具體的DSO和CUBE，我們以後再介紹下面給大家介紹兩個表，是定義DELTA類型的基本表，如下：
ROOSOURCE：定義了每個資料來源的屬性，大部分屬性我們在建立自訂資料來源時已介紹，請參考http://community.kingdee.com/pages/chunguangz/blog/archive/2010/03/18/401671.aspx，其中，DP列定義了增量類型。

RODELTAM：定義了每種增量提取方式的方法，即：DP的屬性

DP：增量處理名稱
T： 標識是否為 僅全量更新
NIM：標識是否為傳輸 新鏡像（即：新資料的狀態）
BIM：標識是否為傳輸 前鏡像（即：更新前的狀態）
AIM：標識是否為傳輸 後鏡像（即：更新後的狀態）
ADD：標識是否為傳輸 差額鏡像（即：更改的差額狀態）
DID：標識是否為傳輸 刪除鏡像（即：刪除狀態）
RIM：標識是否為傳輸 反轉鏡像（即：沖銷的狀態）
SER：標識為 哪種序列化方式，即：資料的排序
1. 無所需序列化
2. 所需的請求序列化
3. 所需的資料包序列化
類型：DELTA處理的類型。標識何種資料幫浦方式。BW中的增量機制就是圍繞RODELTAM表設定來進行的，首先介紹增量類型的定義，我們假設有一筆業務建立100，而後更改為80，然後刪除，對於以上設定，會產生什麼樣的影響：
ORDER NO STATUS QTY RECODE TYPE
建立訂單
100000000 CREATED 100 N 將帶有記錄類型為‘’的建立記錄上傳到BW，BW以N載入DSO
更改 100->80
100000000 CHANGED -100 X 前鏡像產生
100000000 CHANGED 80 “” 後鏡像產生
100000000 CHANGED -20 A 差額鏡像產生

標誌刪除
100000000 DELETED 0 R 反轉鏡像產生
100000000 D 刪除鏡像產生

建立100的業務：此為建立操作，傳輸新鏡像，在R3端，以‘’表示新鏡像
更改100->80：
如果前鏡像設定：以X表示前鏡像傳輸。
如果後鏡像設定：以‘’表示後鏡像傳輸
如果差額鏡像設定：以A表示差額鏡像傳輸我們下面用兩種類型來說明DELTA在R3和BW端的處理步驟：
ABR：MM中採購用到這種類型，我們可以看出ABR存在新鏡像、前鏡像、後鏡像和反轉鏡像，我們建立一採購訂單，並查看，R3資料來源給BW提供的資料。

根據ABR的定義，對於採購訂單操作，應按以下順序傳輸資料：
ORDER NO STATUS QTY RECODE TYPE
建立訂單
100000000 CREATED 100 “” 將帶有記錄類型為‘’的建立記錄上傳到BW，BW以N載入DSO
更改 100->80
100000000 CHANGED -100 X 前鏡像產生
100000000 CHANGED 80 “” 後鏡像產生
標誌刪除
100000000 DELETED 0 R 反轉鏡像產生
通過RSA7查看統計的待傳輸資料：
首先建立採購訂單：訂單號為4510000010
查看RSA7的統計資料：

將100改為80：

將10項目標誌位刪除：
關於在BW中的資料上傳步驟：
對於存在多種鏡像屬性的資料來源，系統會自動為其增加ROCANCEL欄位，作為傳輸鏡像屬性值用。我們這裡的採購訂單資料來源，就是這樣的類型。
我們知道，CUBE只能合計資料，DSO既可以做合計，也可以做覆蓋的匯總，所以，ABR的DELTA類型是既適合CUBE又適合DSO直接更新的。用上面的資料說明，訂單傳輸到合計的更新模式（CUBE或DSO），因為連帶著前鏡像一起傳輸，所以，匯總後的結果就是最後的結果0。如果為覆蓋的話（DSO），那麼序列化後的最後狀態為“R”的記錄，這樣也實現資料的成功上傳。這種方式需要資料來源的序列化，對於ABR設定為2。
因此，這種方式既可以直接上傳到DSO也可以直接上傳到CUBE。但我們一般都會經過DSO，保證資料模型中，儲存了所有的詳細資料。
接下來，我們再對FI的資料來源和自訂的資料來源做一下分析：
首先說明一下，自訂的資料來源預設都是AIE的增量處理方式，即：只提供後鏡像的資料來源，而且沒有提供更改增量處理的方法。與FI的資料來源相似。這樣就說明，這些資料來源只能首先上傳到DSO，然後在進行分析。
以我們前面做的自訂的資料來源為例：
AIE只支援後鏡像，即：所有的建立或修改後，都只將最後的狀態傳輸到BW，並且只支援一種傳輸方式的資料來源不建立ROCANCEL欄位，預設為空白。
執行初始化，並將資料上傳到DSO，不啟用DSO資料，我們在後台資料表中，查看DSO的資料變化：
我們通過在SE11中查詢ZRSO01的描述，找到了其3個表：
A表：/BIC/AZDSO0100
LOG表：/BIC/B0010239000
N表：/BIC/AZDSO0140
並且，可以看到每個表中，都存在RECORDMODE的欄位，有系統自動產生，用來記錄RECORD TYPE。
執行到這裡，只有N表記憶體在資料：

啟用資料：
A表：
儲存了最後匯總的資料

LOG表：
資料轉移到LOG表中，對於以前不存在的記錄，自動將RECORD TYPE置為’N’。

同時，N表被置為空白下面，我們將1234567890的記錄，修改為800，再次執行DELTA更新，並上傳到DSO，查看在未啟用之前的狀態：
這裡說明一下，手工修改記錄的時間戳記，需參考RSA7中的統計時間：

我們將資料修改為：

以下是未啟用DSO前的狀態：
A表：

啟用後：
A表：

LOG表：

從中可以看出，雖然我們只是將後鏡像資料上傳，系統自動為我們建立了前鏡像，保證了DSO儲存詳細資料的要求。關於更多的DELTA處理的問題，大家可以通過以上的方式跟蹤資料在系統間的傳輸來瞭解。最後還要說明一下，FI與其他模組的資料幫浦方式不太一樣。
FI是通過BW的請求，到R3中執行對應的FM，然後獲得資料，寫入DELTA隊列，這種方式叫做”PULL”。自訂資料來源也是這樣的方式。
對於其他模組，如MM，是通過將資料寫入DELTA隊列，BW請求後，並不直接讀取真實的資料來源，而是讀取DETLA隊列。
FI和自訂資料來源，這裡就不說了，大家可以參考自訂資料來源的文章來瞭解。
對MM，啟用資訊結構的時候，會讓我們選擇，更新類型：

同步更新（V1）：DELTA隊列與憑證同步更新，如果DELTA隊列寫入出現錯誤，那麼憑證也被取消
非同步修改（V2）：與V1相比，寫入DELTA若出現錯誤，不對憑證的儲存產生影響
非同步收集更新（V3）：與做憑證沒有關係。在後台定義一程式，定時運行，收集產生變化的資料到DELTA隊列。與FI的抽取方式差別太大，而且需要我們在源系統進行必要的操作。感覺好像不是一批人開發的，實現DELTA的邏輯從本質上不同，SAP的解釋是說，對於不能直接實現DELTA抽取的資料來源，可以採用這種方式。For all information , pls download the attachment.
http://community.kingdee.com/pages/chunguangz/blog/archive/2010/03/21/401977.aspx