SAP TM模塊

縮寫	全稱
TM	Transportation Management
OTR	Order-based Transportation Requirement
DTR	Delivery-based Transportation Requirement
FWO	Forwarding Order
FWQ	Forwarding Quotation
FUBR	Freight Unit Building Rule
FU	Freight Unit
FO	Freight Order
ADS	Adobe Document Service
BOPF	Business Object Processing Framework
FPM	Floor Plan Manager
FBI	FPM BOPF Integration
OVP	Overview Page Floorplan
OIF	Object Instance Floorplan
GAF	Guided Activity Floorplan

1.2 業務流程概覽

TM（Transportation Management）主要包括四個主要步驟：訂單管理，運輸計划，運輸執行，費用與結算，

具有以下幾點優勢：

l 減少成本，提升操作效率

l 提高運輸工具的容錯率及資源利用率

l 高效的端到端訂單及進程管理

l 高效的物流及執行過程

l 提高執行的可視化及響應率

圖表 1

1.2.1 訂單管理

l 與ERP集成：通過PI，由銷售訂單或采購訂單生成OTR（Order-based Transportation Requirement），或由交貨單生成DTR（Delivery-based Transportation Requirement）

l 與第三方集成：第三方平台通過PI創建FWO（Forwarding Order）或在TM系統中創建FWQ（Forwarding Quotation），然后發送到第三方確認后，基於FWQ創建FWO（類似於采購訂單之前的詢價單）

l 獨立系統：直接在NWBC界面創建FWO

1.2.2 運輸計划

l 運輸主控室（負載可視化）

l 計划與優化

l 運輸工具選擇

l 訂單招標

運輸計划的作用：根據訂單管理中的憑證及FUBR（Freight Unit Building Rule）產生的FU（Freight Unit），對FU進行容量和運輸網絡的計划，並產生FO（陸運則是Freight Order，海運和空運則是Freight Booking）

1.2.3 運輸執行

主要包括以下幾點：

l 事件管理：常用的事件包括裝貨開始，裝貨結束，啟運，運達，卸貨開始，卸貨結束等

l 憑證打印：基於PPF（PPF的講解在后續，這里可以理解為一個觸發器）實現通過Smart Forms開發或Adobe Forms與ADS（Adobe Document Service）開發的表單，在某個條件后才可查看，並能在NWBC界面預覽

l 與EWM的集成：如貨物出庫后，司機才能點擊提貨，並隨后觸發啟運事件等功能

目前與APP進行集成的，基本都是運輸執行部分，能讓司機通過手機實現對FO事件的管理以及行車記錄單等憑證的打印來查看運輸任務

1.2.4 費用與結算

l 定義運費（標度，費率表，計算單）

l 定義貨運協議或轉運協議

l 生成結算憑證

l 將代運結算憑證集成到SAP ERP中，生成財務憑證，用於開票給客戶（收款憑據）

l 將結算憑證集成到SAP ERP中，生成采購訂單，進而生成相應的財務憑證（付款憑據）

l 可分為貨運結算，內部結算和代運結算：其場景用通俗的話來講就是，當別人幫我們運時候就是貨運結算，自己運自己的時候就是內部結算，我們幫別人運的時候就是代運結算

1.2.5 主數據

l 位置

l 產品（即ERP中的物料主數據）

l 業務伙伴（用於承運商等）

不同的業務場景需要的業務主數據不同：

l 國內/國際外向運輸：由SAP ERP發起，銷售訂單和交貨單集成是主要的步驟，因此，客戶，工廠，裝運點，產品等主數據需要同步到TM系統

l 國內/國際內向運輸：由采購訂單集成觸發，因此，供應商，工廠，裝運點，產品等主數據需要同步到TM系統

l 外包運輸：通過TM系統來執行基於訂單的承運商選擇，招標，因此，運輸在其他運輸公司完成，因此不用關心細節，那么ERP就成了主數據的主導系統，包括位置，業務伙伴，產品，運輸工具等主數據

1.3 開發框架概覽

http://note.youdao.com/noteshare?id=08e30c63bbbf05c662a4978fb822352e&sub=DA09EBD7F1224C15AFF3E6E4188378E3

2 TM開發框架

2.1 MVC架構

TM整體開發架構基於MVC架構，即Model,View,Controller，其中Model對應的就是TM模塊的核心BOPF（Business Object Processing Framework），View對應的就是NWBC界面，通過FPM（Floor Plan Manager）實現，而Controller對應的是FBI（FPM BOPF Integration）。

TM模塊開發都是基於面向對象實現的，因此封裝性和可讀性非常強。

數據通過BOPF以業務對象的形式存儲下來，使其具有層級和關聯關系，更易與業務場景進行理解，接下來會對BOPF進行詳解講解，然后通過FBI將數據進行邏輯處理后，通過FPM展示出來。

2.2 BOPF

2.2.1 BOPF組成部分

BOPF包含以下組成部分：

l 節點（Nodes）：節點是業務對象的一系列語義關聯屬性的集合，並通過父節點和子節點的形式，使其產生層次和關聯。通俗來講，以交貨訂單為例，分為了交貨訂單抬頭和交貨訂單行項目，那么如果以BOPF的節點形式存儲，即可將抬頭作為父節點，抬頭的屬性即抬頭表的LIKP的各個字段，也就是說屬性就是數據結構中的字段；行項目作為子節點，這里只是一個簡化模型，僅供理解。

因為對應的屬性實際上就是結構中的字段，因此可以對節點進行增強，增加屬性

l 關聯（Associations）：指兩個節點之間的關聯，關聯方式可以為方向性關聯（從A到B與從B到A結果可能不同）或非方向性關聯，並可輸入參數來篩選關聯結果

l 操作（Actions）：個人認為這是TM模塊非常好用的一個功能，可以理解為TM中的各種BAPI，只不過由於基於面向對象，都封裝在類的方法里：在其他模塊，需要通過BAPI*去查詢或者通過調試標准程序或者查看相應包下的函數來查找我們需要的標准BAPI，而TM模塊將操作分配在各個相應的節點下，使得我們可以通過業務場景能直接在對應的節點下找到我們需要的操作。

l 確定（Determinations）：即由輸入參數進行邏輯處理后，確定和填充業務對象節點的屬性值

l 驗證（Validations）：可用於操作之前判斷是否符合相應的觸發條件

l 查詢（Queries）：類似於select語句，但是靈活性不高

TM模塊中的開發基本都是圍繞BOPF進行，因此這部分是整個模塊的核心，必須要掌握的基礎

2.2.2 常用事務代碼及使用方法

l BOBF：用於瀏覽業務對象及業務對象詳情，如下圖：

圖表 2

展開Transportable Business Objects->Business Process Objects->/SCMTMS/TOR（貨運訂單業務對象名），然后雙擊查看詳情

通過Node Structure可以查看業務對象的節點層級結構，右方可查看節點的相關信息，包括節點名，數據結構名，及擴展數據結構名（用於節點增強），以及節點對應的數據庫表

圖表 3

通過Node Elements可查看節點對應的其他屬性，這里不一一展開。

圖表 4

l BOB

用於BOPF增強，會在增強的章節中介紹

l BOBT

用於查詢數據，由於在TM系統中，不是以憑證號作為key值（憑證號為Alternative Key），因此需要打開多個界面復制粘貼進行查詢，非常不方便，通過此事務代碼，只需要輸入一個key值和業務對象名（Key或Alternative Key均可）即可搜索此單據所有的信息（由於BOBT不是必需知識點，后續會專門介紹BOBT的使用方法）

界面圖如下：

圖表 5

2.2.3 Service Manager

前面介紹了業務對象，那么如何訪問它呢？我們需要獲取對應業務對象的service manager實體，進而對此業務對象進行增刪改查等操作。

查詢數據主要為示例程序的三種方式：

l Retrieve

l Retrieve by association

l Query

DATA:
  lt_root     TYPE /scmtms/t_tor_root_k, lt_root1 TYPE /scmtms/t_tor_root_k, lt_item TYPE /scmtms/t_tor_item_tr_k, lt_sts TYPE /scmtms/t_tor_stop_succ_k, lt_id TYPE STANDARD TABLE OF /scmtms/tor_id, lt_selpar TYPE /bobf/t_frw_query_selparam, lt_item_key TYPE /bobf/t_frw_key, lt_key TYPE /bobf/t_frw_key, ls_key TYPE /bobf/s_frw_key, lo_srv_mgr TYPE REF TO /bobf/if_tra_service_manager. FIELD-SYMBOLS :<fs> TYPE any. *--------------------------------------------- * 獲取TOR業務對象的service manager實例 *--------------------------------------------- lo_srv_mgr = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( iv_bo_key = /scmtms/if_tor_c=>sc_bo_key ). *--------------------------------------------- * 將alternative key轉換為key *--------------------------------------------- APPEND '00000000000610000462' TO lt_id. lo_srv_mgr->convert_altern_key( EXPORTING iv_node_key = /scmtms/if_tor_c=>sc_node-root iv_altkey_key = /scmtms/if_tor_c=>sc_alternative_key-root-tor_id it_key = lt_id IMPORTING et_key = lt_key ). *--------------------------------------------- * 根據key讀取node數據 *--------------------------------------------- CALL METHOD lo_srv_mgr->retrieve EXPORTING iv_node_key = /scmtms/if_tor_c=>sc_node-root it_key = lt_key IMPORTING et_data = lt_root. *--------------------------------------------- * 根據key + association讀取關聯節點數據 *--------------------------------------------- CALL METHOD lo_srv_mgr->retrieve_by_association EXPORTING iv_node_key = /scmtms/if_tor_c=>sc_node-root it_key = lt_key iv_association = /scmtms/if_tor_c=>sc_association-root-stop_succ iv_fill_data = abap_true IMPORTING et_data = lt_sts. *--------------------------------------------- * 根據相應查詢條件通過query的方式查詢結果 *--------------------------------------------- lt_selpar = VALUE #( ( attribute_name = /scmtms/if_tor_c=>sc_query_attribute-item_tr-qdb_query_by_attributes-platenumber sign = /bobf/if_conf_c=>sc_sign_option_including option = /bobf/if_conf_c=>sc_sign_equal low = '鄂A12345' ) ). lo_srv_mgr->query( EXPORTING iv_query_key = /scmtms/if_tor_c=>sc_query-item_tr-qdb_query_by_attributes " Query * it_filter_key = " Key Table it_selection_parameters = lt_selpar " Query Selection Parameters * is_query_options = " Query Options iv_fill_data = abap_true " Data element for domain BOOLE: TRUE (='X') and FALSE (=' ') * it_requested_attributes = lt_requested_attributes " List of Names (e.g. Fieldnames) IMPORTING * eo_message = " Message Object * es_query_info = " Query Information * et_data = lt_item_res et_key = lt_item_key ).

Retrieve by association(dependent objects)：這類查詢對應於獨立的業務對象，如附件，不屬於任何一個業務節點的屬性，是一個公共使用的容器，理解上會相對復雜，會在后續專門介紹。

增刪改則都可以通過service manager實例中提供的modify方法來實現

FIELD-SYMBOLS: 
               <ls_root> TYPE /scmtms/s_trq_root_k, <ls_trq_qdb> TYPE /scmtms/s_trq_q_result. DATA: lo_srv_trq TYPE REF TO /bobf/if_tra_service_manager, lt_mod TYPE /bobf/t_frw_modification, ls_mod TYPE /bobf/s_frw_modification, lv_trq_new_key TYPE /bobf/conf_key, lo_chg TYPE REF TO /bobf/if_tra_change, lo_message TYPE REF TO /bobf/if_frw_message, lo_msg_all TYPE REF TO /bobf/if_frw_message, lo_tra TYPE REF TO /bobf/if_tra_transaction_mgr, lv_rejected TYPE abap_bool, lt_rej_bo_key TYPE /bobf/t_frw_key2, ls_selpar TYPE /bobf/s_frw_query_selparam, lt_trq_qdb TYPE /scmtms/t_trq_q_result. * Get instance of service manager for TRQ lo_srv_trq = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( /scmtms/if_trq_c=>sc_bo_key ). *--- Creating a new TRQ instance ---* ls_mod-node = /scmtms/if_trq_c=>sc_node-root. ls_mod-key = /bobf/cl_frw_factory=>get_new_key( ). *--- set operation ---* ls_mod-change_mode = /bobf/if_frw_c=>sc_modify_create. CREATE DATA ls_mod-data TYPE /scmtms/s_trq_root_k. ASSIGN ls_mod-data->* TO <ls_root>. <ls_root>-trq_type = 'ZENH'. APPEND ls_mod TO lt_mod. lv_trq_new_key = ls_mod-key. lo_srv_trq->modify( EXPORTING it_modification = lt_mod IMPORTING eo_change = lo_chg eo_message = lo_message ).

2.2.4 Transaction Manager

TM中的更改操作需要通過實例化transaction manager來實現保存動作，類似於BAPI_COMMIT操作。

*---------------------------------------------
* 創建transaction manager實例
*---------------------------------------------
  lo_tra_manager = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manager( ).

*---------------------------------------------
* 保存
*---------------------------------------------
  lo_tra_manager->save( IMPORTING eo_message = lo_message " Interface of Message Object ).

2.3 FPM

FPM是基於web dynpro開發的一套更加標准化，對於開發者更加友好便捷的UI開發框架。同時FPM對於開發也是很強大一項技能，篇幅有限不在此展開，會在后續補充FPM開發的相關詳細知識

2.3.1 框架介紹

常用的FPM框架主要分為三類：

l OVP（Overview Page Floorplan）：使用的時候引用FPM_OVP_COMPONENT，最靈活的一種模式，采用stack的概念來安排界面，這是其他component沒有的

l OIF（Object Instance Floorplan）：使用的時候引用FPM_OIF_COMPONENT，進去之后默認只有一個tab UIBB為主界面，所有其他的UIBB要加到這個tab UIBB中去，缺點是只有當前顯示的tab下的UIBB能獲取到拋出的事件，沒有顯示的UIBB的feeder class無法獲取到拋出的事件

l GAF（Guided Activity Floorplan）：使用的時候引用FPM_GAF_COMPONENT，step by step的模式，常用於一步一步指導過程的向導式界面，能清晰的看到執行的順序以及將要執行的步驟，可以參考在NWBC上設置POWL時的界面，就是基於GAF開發的，如下圖：

圖表 6

在TM中主要使用的是OVP，同時也是最靈活的一種。

2.3.2 技術框架

圖表 7

l Interfaces：SAP標准接口，提供相關方法，對應到相關標准的控件

l FeederClass:實現SAP的Interfaces的方法，通過FeederClass控制UI控件

l UIBB:WEB控件

l App Controller：控制器接口，控件的總入口和出口，實現事件統一控制

2.3.3 相關接口

SAP通過內置了大量的標准接口來實現代碼的標准化，我們只需要實現對應的接口作為FeederClass，然后再將FeederClass綁定給UI即可。

接口	說明
IF_FPM_GUIBB_FORM	FORM表單控件
IF_FPM_GUIBB_FORM_EXT	FORM表單控件擴展
IF_FPM_GUIBB_LIST	TABLE LIST控件
IF_FPM_GUIBB_LIST_EXT	TABLE LIST控件擴展
IF_FPM_GUIBB_SEARCH	搜索控件(配合LIST一起使用搜索加結果)
IF_FPM_GUIBB_TREE	樹形節點控件

2.4 Wire Model

線模型，用於通過純配置來實現FPM應用之間的運行時相關性，比如能根據源UIBB的修改輸出來決定目標UIBB的數據內容，例如我們在NWBC界面修改FWO的item某一個list信息，可能會更改FWO item相關的另一個list信息。

例如，我們在NWBC界面做增強，需要為展示FO的界面增加一個UIBB，那么我們肯定會需要定義這個新的UIBB的數據來源，而通過定義Wire Model就能實現，將新的UIBB與已存在的用於顯示業務對象實例的UIBB關聯起來，如下圖：

圖表 8

圖表 9

重要屬性名及屬性值詳解：

Component:目標UIBB的組件類型，此處為FPM提供的通用List UIBB

Configuration ID:目標UIBB的配置ID

Instance ID:默認為1，暫未了解其他用法

Source Component:源UIBB組件類型

Source Config Name:目標UIBB的配置ID

Source Node Association:源UIBB對應的業務對象節點與目標UIBB對應的業務對象節點之間的關聯

Connector Class:提供標准的方法將FPM，FBI及BOPF與Wire Model連接

2.5 FBI

FBI即FPM與BOPF集成，FPM,FBI及BO Layer之間的技術關聯圖如下：

圖表 10

FBI相關概念如下：

2.5.1 FBI View(design time)

在NWBC界面查看對應的FBI View名稱，如下圖所示：

圖表 11

圖表 12

包含界面對應的業務對象，業務對象節點，節點UI結構，Mapper Class和Exit Class。

2.5.2 FBI View Instance(runtime)

FBI View的實例包含了顯示的實例的key值（來源於與UIBB連接的Wire Model），FBI View實例能將修改，執行動作，以及變更通知發送到FBI Controller中，它會對FBI特定的SYNCUP事件作出反應，根據變更通知來決定哪些key值需要刷新，另外，它可以用已修改的Key值在node buffer或者BO層獲取數據，並可以在需要的地方調用Mapper Classes和Exit Classes

2.5.3 FBI Controller(runtime)

用於集中BO層的響應，不包含任何應用程序邏輯，知識提供業務流程的技術框架，為UI上的更改提供一個修改的緩沖區，然后再將緩沖區的數據再轉發到BO層，同時它還能手機來自BO層的更改通知，然后再UI上觸發更新，緩沖區的存在可以保存來自BO層的節點信息，節點屬性等，有助於避免冗余的BOPF服務調用。

2.5.4 Conversion Classes

即Mapper Class，用於將數據在BO 層和UI層進行轉換，數據從BO層到UI或者數據由UI返回到BO層，轉換的過程在獲取數據后，發送更改到緩存之前。

所有的Conversion Classes的實現都繼承於TM的超類/SCMTMS/CL_UI_CONVERSION，對其繼承后都需要重定義方法BUILD_MAP_TABLE，超類已經包含一些通用的轉換規則，比如時間戳到年月日的轉換，時間戳到年月日字符串的轉換，key與Alternative Key之間的轉換

2.5.5 Exit Classes

FBI的大部分邏輯處理都在Exit Classes中實現，因此也是TM增強的一個核心，所有的類實現繼承於超類/SCMTMS/CL_UI_VIEWEXIT_CMN，一個Exit Class需要實現下列接口：

l 核心接口：/BOFU/IF_FBI_VIEW_EXIT_INTF，此接口不含任何方法，用於讓FBI對此類實例化對象

l 定義接口：/BOFU/IF_FBI_VIEW_EXITINTF_DEF，此接口主要用於更改FPM中的get_definition方法（僅在初始化時運行一次），有以下方法：

ADAPT_FIELDS用於修改字段目錄；

ADAPT_ACTIONS用於修改操作目錄；

ADAPT_DND_DEFINITION用於修改下拉框定義

l 定義接口：/BOFU/IF_FBI_VIEW_EXITINTF_RUN，此接口主要用於影響用戶交互的進程即FPM中的GET_DATA,PROCESS_EVENT,FLUSH等方法（在每次交互時觸發），有以下方法：

ADAPT_CHANGE_LOG用於將UI的修改在轉換成BO修改記錄之前進行更改；ADAPT_EVENT用於處理事件；

ADAPT_MESSAGES用於修改來自modify或者do_action的消息；

ADAPT_DATA用於在數據傳遞到FPM之前，修改數據，需要注意的是，這里的數據都是以參考字段的形式，因此訪問UI結構需要通過’ASSIGN COMPONENT’來實現；

ADAPT_FIELD_PROPERTIES用於修改字段屬性；

ADAPT_ACTION_PROPERTIES用於修改action的是否可用屬性；

ADAPT_SELECTION用於修改已選擇行（在List或Tree UIBB中）

3 TM報表POWL

會在后續更新

4 TM表單打印

會在后續更新

5 TM增強開發

5.1 BOPF增強

事務代碼：BOB

增強界面如下圖：

圖表 13

如果要對列表里的標准業務對象進行增強，首先要為這個業務對象創建增強對象，此增強對象並不是替代或拷貝標准的業務對象，只是作為一個存放增強的容器，而標准的業務對象會作為super BO 或者base BO

增強對象如下圖：

圖表 14

上面不是灰色的節點允許增強，下面顯示的是所有節點的實體操作，如果需要看某個節點對應的操作，雙擊該節點即可

圖表 15

這兩個自動生成的組合結構除了包含節點對應的字段外，還會包含db key,parent key,root key

數據庫表則是給出了這個節點數據存儲的表名

5.1.1 創建增強對象

選擇需要增強的節點，右擊選擇創建增強

圖表 16

圖表 17

圖表 18

每個增強對象都有它對應的常量接口（系統在創建增強對象時自動生成的）

圖表 19

對此增強對象下的屬性進行更改時，需要點擊重新生成按鈕，更新常量接口

5.1.2 創建字段擴展

增強節點元素並沒有添加到標准常量接口中而是添加到對應的增強對象的常量接口中

圖表 20

通過永久包含或過渡包含接口進行擴展（過渡包含的用於那些可能只用一段時間的增強字段）

圖表 21

點擊附加結構添加擴展字段，里面的字段名盡量按照ZENH_*的形式進行命名

5.1.3 創建子節點

圖表 22

選擇增強對象的某個節點，右鍵選擇創建子節點，子節點的命名規范ZENH_ROOT_SUBNODE

圖表 23

圖表 24

雙擊進入，創建此結構（這兩個結構用於此子節點的字段擴展）

圖表 25

圖表 26

選擇結構的增強類別

圖表 27

這兩個結構創建后，還需要創建兩個結構，即此子節點本身應有哪些字段的結構，點擊next

圖表 28

這兩個結構也分別創建，同上（也需要選擇增強類型），輸入Node的字段，並include上之前創建的兩個結構

圖表 29

需要注意的是，永久結構里面包含的應該是永久擴展結構，過渡結構里面包含的應該是過渡擴展結構

圖表 30

接着點擊下一步，會自動創建這些結構和表，如果此步完成后，點擊下一步完成，報錯“node couldn’t be created”，那么需要檢查一下對應的結構，組合表類型，以及數據庫表是否創建成功，因為系統自動創建這些數據結構時，系統會自動加上一些字段，如MANDT,ROOT_KEY,DB_KEY,PARENT_KEY等可能會與自己創建的結構中的字段名重復導致創建失敗，但沒有詳細的錯誤消息，因此很難發現

圖表 31

5.1.4 創建活動

圖表 32

選擇操作基數：多個節點實例表示這個操作可以操作在一個或多個節點實例上，單個節點實例表示這個操作只能操作在一個節點實例上，而靜態操作則是無法操作在節點實例上

圖表 33

可點擊建議名稱，雙擊結構進入創建界面（SE11），此結構用於action的額外要求傳入傳輸

圖表 34

雙擊進入實施類

圖表 35

雙擊進入EXECUTE方法進行編輯

圖表 36

5.2 FPM增強

圖表 37

如果需要對FPM進行增強，需要通過事務代碼SICF檢查FPM可增強服務是否已激活

圖表 38

可以通過一個通用的方式去訪問：

http://[server]:[port]/sap/bc/webdynpro/sap/wd_analyze_config_comp

如下圖，選擇查詢方式

圖表 39

5.2.1 字段增強

基本思路：先找到FPM對應的BO node，然后在BOBF中找到此BO node對應的extension include，對此結構附加字段，最后再在FPM的配置界面，選擇對應的字段進行添加

找到需要增強的頁面，在某個字段上，右鍵選擇technical help

圖表 40

得到組件配置名：

圖表 41

點擊link導航至此配置界面

圖表 42

得到FBI view

圖表 43

新建窗口

圖表 44

輸入FBI view，點擊display

圖表 45

得到此界面關聯的BO node

圖表 46

然后通過事務代碼BOBF，獲取到此節點對應的增強結構

圖表 47

或者直接根據上述提供的鏈接查詢組件配置ID

如果未生效，則可以將extension include直接append到UI對應的結構上

圖表 48

5.2.2 操作增強

基本思路：同上，先找到需要增加toolbar button的界面對應的configuration id，獲取其對應的BO node，在BOBF開發工作台中找到此節點對應的action，新增action后，會自動生成綁定的類，然后實施類中的execute方法，最后在FPM前台，添加toolbar，選擇新建的action進行綁定

圖表 49

在類中拋出消息的示例代碼：

圖表 50

5.2.3 頁簽增強（數據來源於增強的子節點）

此增強適用於，需要與SAP中標准的業務對象有着業務上的關聯關系且需要展示的場景，而D頁簽增強（數據來源於外部數據）適用於與標准業務對象基本無關僅需要展示的場景，注意不同增強的使用場景

基本思路：找到需要增強頁簽的界面，找到對應的BO node，在BO node上增加子節點（需要定義1.永久結構，2.組合結構即包含db_key,root_key,parent_key和永久結構的結構，3.組合表結構，4.數據庫表）以及在子節點上新增action（用於頁簽里的按鈕事件），然后需要創建一個新的UIBB（也就需要新的component configuration和feeder class，並編輯feeder class parameter設置業務對象和節點為新增的子節點），繪制頁面（設置顯示字段，添加按鈕等），最后將此UIBB掛載到標准界面上

增強通用鏈接：

https://[server]:[port]/sap/bc/webdynpro/sap/configure_component

按照之前的步驟創建子節點后，先創建一個UIBB

圖表 51

輸入組件名，此處展示為list形式，如為其他形式，需要更改命FPM_XXX_UIBB_ATS

同時，configuration id的命名建議遵循以下規范:ZENH_WDCC_XXX_XXX_UIBB分別為描述和展示形式

點擊創建，選擇包與請求，輸入對應類型的feeder class: /BOFU/CL_FBI_GUIBB_LIST_ATS

圖表 52

編輯feeder class parameter，在此處填入增強的子節點以及其根節點（數據來源）

圖表 53

編輯UIBB，添加field,action等，並修改其屬性，保存UIBB

圖表 54

下一步為找到需要添加此UIBB的主頁面，然后找到其configuration id，方法如下：右鍵點擊主頁面，選擇技術幫助，然后start component中的component configuration即對應我們需要增強的主頁面

圖表 55

雙擊進入，或者復制進行搜索，然后顯示，由於主頁面有很多個page，我們需要選擇main page，然后編輯

圖表 56

選擇overview page schema點擊添加list component，並輸入剛才創建的UIBB的configuration id

圖表 57

編輯list component的屬性，注意此處的title即為展示的頁簽的標題

圖表 58

最后添加wire schema，用於定義UIBB從哪里去取數來展示，它能將已抓取當前展示的業務對象信息的此界面的UI與我們新建的UIBB進行關聯，從而獲取數據

圖表 59

編輯wire list屬性

圖表 60

創建tab成功，查看效果

5.2.4 頁簽增強（數據來源於外部非業務對象節點）

基本思路：先創建用於展示數據的數據源表，然后創建FBI view（包含標准的BO node/UI structure/mapper class/exit class，通過復制標准的BO node對應的FBI view獲得，並在UI structure中增加自己需要的字段），創建list UIBB（包含feeder class即標准的list class，剛才創建的FBI view信息），配置list UIBB的字段，然后在主頁面中添加UIBB，並通過增加wire list將UIBB與UI綁定，重寫mapping class和exit class中的相關方法，通過代碼將數據來源指向自建表