張偉磨刀霍霍，帶著10個大殺器，就攻入了BAPI的腹地，開始了正式的探寶！
進入BAPI介麵後，張偉開始了剖析，介麵有兩種查詢BAPI的方式，一種是層級選單模式，一種是關鍵字模式，張偉準備了10個探索的誘餌，直接奔著關鍵字模式就去了！
首先是主資料，按照關鍵字往下，沒滑動多少，就找到了“Customer”客戶主資料！畢竟是字母C開頭！
進去後，張偉發現，點開後，下拉很多具體的BAPI，有“create、edit、change、delete.......”等等，拉下來有幾十個BAPI!
目光移到了右邊，張偉發現了熟悉的身影“KNA1”，非常好，自己寫報表用過無數次的客戶主資料的表，但是在這裏這個“KNA1”的抬頭名變了，變成了“objecttype”物件型別？
什麼鬼！為什麼不叫table名了？叫“objecttype”這是幾個意思？object，物件，麵相物件？
張偉想起，結出實心藍丹時，對程式語言進行了分代，第一代麵向機器如組合語言，第二代程式導向如C語言，第三代物件導向如Java語言，第四代麵嚮應用如張偉現在做SAP的ABAP語言，當然後麵張偉對第四代又進行了細化，第四代，應該是麵向特定方向的應用，張偉現在這個ABAP語言，就隻能在SAP裡使用，隻能編輯SAP的程式，不能編輯其他需求的程式，因此應用起來很窄，但是封裝非常的完善，基本上把ERP這個領域的常規處理邏輯都封裝好了，直接使用即可！因此第四代會有很多種麵向最終應用的語言，比如麵向動畫的、麵向工程的......隻在自己領域使用的程式語言！
而張偉結出的SAP實心藍丹，是沒有第三層物件導向程式層的，從C語言層，直接就到了ABAP層！當時張偉是有點想不通的！覺得這和自己劃分的4代程式語言，有衝突，中間少了一層！
當時想如果中間加一層物件導向層，可是ABAP又不是物件導向，張偉程式設計時明顯沒有感受到，物件導向的程式思維習慣！ABAP給張偉的感覺就是簡單，比Java，C#等這些正統的物件導向程式語言來說，就太簡單了，而且程式設計效率很高，基本就是直接麵向終端使用者需求去的！因此張偉就把當時結出的SAP藍丹直接把第三層定義成了ABAP程式層！
可是現在打算結第六層丹時，居然跳出了這麼一個“object”的玩意，張偉就有點懵圈了！而且跳出的這個還是對“KNA1”客戶主資料表！
難道是把KNA1看做一個物件，進行BAPI程式設計？
張偉誕生了這個想法，異常的興奮，可能第六層一開局就封層結丹了，同時好像覺得很合理，那麼需要驗證下了！
張偉手上準備的大殺器，探路誘餌還有很多，現在才用了一個“客戶主資料”甚至都還沒用完，就有收穫了，現在需要丟擲第二枚、第三枚誘餌了！
張偉很是興奮啊，可以拋誘餌，代表魚兒已經上鉤了啊！可以往前猛攻了！
丟第二個探路誘餌“vendor”供應商主資料，V首字母排在最後，張偉基本上拉到了底部才找到！
張偉迫不及待的點開，心中默唸這“LFA1”，這是供應商主資料的表，點選後迅速看向了右邊的資訊欄！
我靠！果然！熟悉的“LFA1”表出現在眼前，NND多麼熟悉的表！LFA1自己在當時的報表編寫中使用了無數次，對這個表簡直是如數家珍！
現在他在自己期待的位置，“objecttype”的後麵就是“LFA1”.
該放第三個探路誘餌“Material：物料主資料”了，張偉期待的點開了這個選單，心中無比篤定，出現那個意料之中的，熟悉表名“MARA”自己寫報表，用過無數次的物料主資料表！
當點開這個介麵時，張偉石化了！不是期待中的“MARA”而是一個完全陌生的“Objecttype：BUS1001”！
我靠什麼情況！上麵明明標註的物件名是“Material”為什麼物件型別不是“MARA”？
張偉有點丈二和尚摸不著頭腦了！懵叉叉了！
張偉馬上又丟擲了，剩下的誘餌！都是那種不認識的，不熟悉的物件型別名！
張偉有點暈晃晃的了，難道前麵兩個自己眼花了！看錯了！
於是張偉又去看了客戶、供應商主資料，沒有變啊！就是那兩個表“KAN1和LFA1”沒有錯啊！
那為什麼隻有這兩個，而其他的都不是了？張偉陷入了困惑！難道自己的推導邏輯錯了麼嗎？張偉有點自我懷疑了！
張偉想，ABAP語言跨越了一個程式語言分代，那麼中間肯定需要在某個地方補齊的，現在自己差不多找到了這個分代的補齊地方了！
那為什麼，前麵兩個是自己認為正確的物件導向邏輯思維，設定的物件！
而後麵這些都不是了？這是為什麼啊！
但是他們的物件名，都是對的！物料的物件名“Material”，採購訂單的物件名“PurchaseOrder”....，但是他們的物件型別，為什麼不是對應的資料表名了？
NND！這是什麼情況！張偉有點抓狂了！
物件名是和自己物件導向的認知匹配的！可是物件型別不是啊！
**！哪裏出錯了！哪裏有問題？張偉想抓耳撓腮！辦公室的環境有點不允許！
NND，廁所，放點水去！換換腦子！
回來後，張偉心情有點平復了！
張偉不知道哪根筋搭錯了，雙擊了下物件名！
我靠！暗門！居然有暗門！
跳出新的內容了！新大陸！
NND還有暗門啊！這寶藏設計的也夠精巧的！
哈哈！張偉有種柳暗花明的感覺啊！
點進去後，映入眼簾的是“Businessobject：BUS2012PurchaseOrder”！名字變了！變成了商業物件！或者叫業務物件，更加的貼切！
張偉現在這個對英文的翻譯能力，練出來了，不過僅僅隻針對這種，SAP專業的詞彙翻譯！而且是單詞模式，不是那種整句整句的！
“業務物件”！妥了，這個命名妥了！對啊就應該叫業務物件！採購訂單，就是一種業務形態的單體啊！也就是一種業務物件啊！如果用表反而不對，因為採購訂單，有兩個表，一個單頭，一個單身！用表反而不對，用業務物件反而是對的！
但是，至少有“EKKO”這個實體的表資料物件存在吧，找找看？
張偉往下看，還有5個下拉選單，都是合起來的，其中有一個“Keyfields”關鍵欄位！這不就是表麼！
張偉興奮的點開！我嘞個去！妥了！
“EKKO”!心心念念，夢寐以求，朝思夢想.......，張偉把所有能想到，思念一個人的詞語都想了一遍！對著這個EKKO在心裏默唸了一通！
NND！妥了！
張偉這才仔細看了下另外4個選單內容，更加妥了！就是物件導向的思維啊！
他們是“Interfaces：介麵，Attributes：屬性，Methods：方法，Events：事件”!
NND妥妥的物件導向設計思路啊！
張偉發現與採購訂單處理相關的，所有BAPI都在Methods：方法裏！
張偉立馬檢視了自己準備的其他幾個誘餌！
NND！
妥了，都是這樣的結構！包括最開始的供貨商、客戶主資料，也是一樣！
張偉覺得，這個“Businessobject：業務物件”的取名，簡直是太貼切了！客戶、供應商主資料為什麼直接用資料表名來當業務型別名，估計是太簡單了，直接就用表名了！而其他為什麼不用？因為複雜了啊！業務物件需要涵蓋太多的物件實體，直接用表名實體，估計涵蓋不住吧！或者乾脆就是那個程式當時懶！搞個簡單的名字！
哈哈！張偉覺得懶這個解釋是正解！基於奧卡姆剃刀推導而來的結論！
張偉為什麼特別在意這個表，和物件的關聯啊？以及這個Businessobject：業務物件取名覺得很貼切啊！
張偉推導的SAP結丹，是層狀的，其次是網狀的！
現在張偉結出的第5層，是資料表，第五層和第四層的欄位是連結的，第五層表間也是連結的，其實表間的連結張偉是基於自己寫報表推匯出來的，而沒找到例項佐證，現在還差向上第六層和表的聯絡了！
現在妥了了！因為業務物件啊“Businessobject：業務物件”，比如採購訂單，有兩個實體表“EKKO，EKPO”，而客戶主資料，一個表就行“KNA1”，因此對採購訂單這種，有多個實體物件的，如果從業務物件的角度，就不能隻用一個表名，來定義物件型別了！就得重新命名了！
以採購訂單為例，EKKO,EKPO,這兩個實體表，組合成了一個業務實體，採購訂單，也就是業務物件！
這纔是，當時自己為什麼隻找到供應商，客戶的業務物件型別，就是表名，其他的都是被重新定義了業務型別名的真正原因！
同時這也是第六層真正的聯絡！
每個業務物件，包裹了一個，或者幾個實體的表！表和業務物件，在BAPI裡，基於業務邏輯融合在一起了！也就是表間關係，其實是被BAPI定義的，張偉之前認為表和表之間有聯絡，僅僅是從結果來考慮的，因為報表取數需要他們聯絡在一起，才能取到正確的報表資料！
而為什麼要聯絡，怎麼聯絡的，張偉是不知道的！現在都知道了，因為是由BAPI幫他們聯絡起來的啊！
第六層結丹，正式完成了！
第五層是表，第六層是BAPI層！或者叫業務物件層！一個業務物件，有很多個BAPI!每個BAPI，定義了表間的關係！
第五層從此和第六層貫通了！
張偉把SAP的結丹道統，推向了第6層！結出了擁有1.2.3.4.5.6層的實心SAP藍丹！
看女頻小說每天能領現金紅包🧧