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官方教材還真是有很多閃光點的，窩在一些無人關注的角
)
