ECC端的SBIW界面也可通過BW系統遠程登錄進入：
遠程登錄到ECC源系統，進行數據源的創建與配置：
在ECC端輸入SBIW：
下面以物料主數據的文本為例：
如果不需要某個表里的所有字段，則可以單獨為這個表創建一個視圖，選擇需要的字段，再以這個視圖為基礎創建數據源
下面需要將數據源復制到BW系統中，並且激活后，才能在BW系統里使用，進入到BW系統中：
不等於表示數據源還未激活，需激活才能使用，將數據切換到編輯模式再進行激活（激活過程會為數據源生成相應的PSA物理表）：
下面就可以通過該數據源抽數了
創建信息包：
發現該數據源目錄只支持全量加載，可以使用RSA2來查看數據源是否支持增量，以及增量處理模式：
還可以通過RSA6來查看數據源是否支持增量（但查出來的信息沒有RSA2詳細）：
只有在通過RSO2創建數據源時，才可以設置是否支持增量：
現假設每天0點啟動任務抽數，並抽一天的數據，則需抽從昨天0點到今天0點的數據，任務也是0點起動，但在昨天 23：59分時，用戶在維護一張單子，在今天零晨1點才做完保存，但記錄的是修改時間還是昨天昨天 23：59分，如果任務在0點准時啟動，並且在半小時就抽完了，則這一條在昨天昨天 23：59分修改的數據就會抽不到，明天再啟動任務更抽不到，所以就會用到下面兩個安全值設定：
Safety Interval Upper Limit：安全上限，將抽取的時間向前推多少秒，這樣雖然今天抽不上那條昨天 23：59分修改的數據，但明天0點抽取時一定會抽上來，這種安全設置不好的就是會抽設置時間段的重復數據，不過即使重復數據只要是放入覆蓋DSO是沒有問題的，但放入合計累加的DSO就會有問題了
Safety Interval Lower Limit：安全下限，這種就是直接將抽取任務向后推多少秒后再執行，假設是2小時，這樣那昨天 23：59分修改今天零晨1點的數據就會被抽上來，不用等到明天再抽，這種方式較前一種沒有重復數據，但會推遲抽數的完成時間點
並且選擇增量的字段不能再為作Data Selection字段，因為被用作增量的字段會自動變灰：
注：自建數據源只支持Pull方式的增量方式（所以與財務模塊數據源一樣也不支持刪除），因為我們不可能像為LO后勤數據源那樣，給它們用推的方式主動向Delta-Queue里存增量數據，因為推的方式需要在數據源端使用代碼來實現的。而Pull的方式則會簡單很多，它是基於某個字段來篩選出發生變化的數據來的。
當使用RSO2設置增量數據以“
New Status for Changed Records
”方式記錄時，數據源增量處理方式則為AIE：
當使用RSO2設置增量數據以“Additive Delta”方式記錄時，數據源增量處理方式則為ADD：
下面開始測試AIE增量處理方式的自建數據源：
注：自建數據源也是有Delta-Queue的（就像財務模塊數據一樣）
新創建一個訂單：
當創建好訂單后，如果現在就去查看ZVBAK的Delta-Queue，則是沒有數據的，因為自建數據都是Pull的方式，所以一定要運行BW端的增量信息包才會向此Delta-Queue里存一份數據
下面創建增量信息包后，運行ZVBAK Delta-Queue里是否有增量數據：
但運行完增量信息包后，查看監視器，發現也沒有增量數據上來，怪哉？！
12944訂單號沒有抽上來的原因是，該自建數據源是基於 “Numeric Pointer”類型的 VBELN 字段作的增量，但Pointer當前的狀態值已經到S-6102，在BW拉數據的時候，是要從大於S-6102開始才認為是增量數據，所以12944訂單無法抽上來：
（注：這個Pointer 在這里是不能修改的，是由系統自動填充的，但會隨着增量數據的抽取而自動修改，它記錄了增量抽到哪個位置來了）
通過SE11查看，VBAK里最大單號就是S-6102，因為先前的初始化信息我們選擇的是“只打標記，不傳數據”，這樣目前VBAK里的數據認為已經抽過了，所以打完初始化標記后，Current Status指針的值就會VBAK表里編號最大的訂單號：
注：該示例是以VBELN為基礎的增量字段，但實際上並不合適，因為VBELN訂單號可能含有非數字，作為Numeric Pointer的增量字段，要求字段必須是純數字類型的字段，這樣新增數據時，最新的數據就會在最后，這樣增量抽取時才不會有問題
RSA3：可在ECC端對數據源進行預提測試
