本文介紹了基于AMDP + XLSX Workbench的報表開發。相對于傳統的ABAP Report開發，該模式有效的縮短了開發周期，實作了資料查詢處理和前端展現的分離，且友善維護和擴充。
本文介紹了我和同僚通過使用AMDP + XLSX Workbench縮短報表開發周期、分離資料查詢處理邏輯和前端展示工作的經驗。歡迎讨論。
前言
最近接到了一套人力資源報表的開發需求，需要以EXCEL表格的方式輸出，且包含大量sheet頁，每個sheet相當于一個獨立的報表。
這種情況下，如果讓同一個人開發所有内容，将會花費較長的開發周期，是以，要将程式分解成若幹個部分，最好每個報表（sheet）都是一個獨立的子子產品，讓不同的人同時開發。
對于這類報表，我們之前的做法是，使用OLE輸出EXCEL檔案，在report程式中，使用邏輯資料庫擷取資料，引入常用的OLE方法，為每個sheet建立一個include檔案，實作不同sheet的代碼分離。
代碼類似這樣：
REPORT zhr_report .
************************************************************************
* INCLUDES
************************************************************************
INCLUDE zhr_report_top. "//資料定義
INCLUDE zhr_report_s01. "//選擇螢幕```````````
INCLUDE z_ole_excel_hr. "//通用EXCEL操作子程式
INCLUDE zhr_report_m01. "//事件
INCLUDE zhr_report_f01. "//通用子產品
INCLUDE zhr_report_ex01. "//Sheet1
INCLUDE zhr_report ex02. "//Sheet2
INCLUDE zhr_report_ex03. "//Sheet3
INCLUDE zhr_report_ex04. "//Sheet4
INCLUDE zhr_report_ex05. "//Sheet5 示意圖：
通過将通用的OLE方法封裝到一個包含檔案中，并使sheet頁的處理放到不同的包含檔案，可以使對它們的同時編輯成為可能。但是，這種做法也是有問題的：
- 包含檔案不是單獨的程式，這意味着隻要有一個include檔案中有文法錯誤，文法檢查時就會給出提示，進而無法激活整個程式。
- 命名空間相同，這意味着定義子程式或FORM名時，很容易發生沖突
- 隻能通過增加包含檔案實作程式的橫向擴充，較難實作程式的縱向擴充。通用部分一旦确定，再想修改會比較困難。
- OLE的性能較差。
為了解決這些問題，我們引入了AMDP + XLSX Workbench的報表開發模式。
改進後的模式示意圖：
本文連結：http://www.cnblogs.com/hhelibeb/p/8422711.html
名詞解釋
AMDP
全稱ABAP-Managed Database Procedure，一種ABAP on HANA的實作方式，提供了在ABAP中運作SQL Script的可能，并且與ABAP中的類和資料類型有良好的內建。之前的有關AMDP的文章：
ABAP中的AMDP（ABAP-Managed Database Procedures ）
XLSX Workbench
一種可視化表單生成工具，相比複雜的OLE，可以用少量代碼+一些拖拽和配置來生成EXCEL報表，性能更好。按XLSX Workbench的文檔介紹，它有九大特性：
- 無需ABAP程式設計技能
- 可視化設計方式
- 高性能
- 支援背景處理
- 強大的表單格式特性支援
- 支援公式
- 支援圖檔
- 支援圖表
- 支援樹
官方文檔：https://sites.google.com/site/sapxlwb/home
代碼例子
注意，本部分内容會假設讀者已經有使用AMDP的XLSX Workbench的初步經驗（至少是能輸出Hello World的水準）。如果不是這樣的話，可能會對其中的某些内容感到困惑。
1，首先，建立一個接口ZIF_XLSX_REPORT。
INTERFACE zif_xlsx_report
PUBLIC .
METHODS get_dataCHANGING
!data TYPE sflight_t
RAISING
cx_amdp_error .
ENDINTERFACE. 接口包含一個get_data方法，方法有一個參數data，它資料類型，即為将要輸出給XLSX Workbench表單的的資料類型。
2，為接口建立實作類。
為接口建立一個實作類，在方法ZIF_XLSX_REPORT~GET_DATA中調用AMDP類方法，進行資料處理後，将得到的資料填充進chaging參數data中。
CLASS zcl_xlsx_report1 DEFINITION
PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
INTERFACES zif_xlsx_report .
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.
CLASS ZCL_XLSX_REPORT1 IMPLEMENTATION.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZCL_XLSX_REPORT1->ZIF_XLSX_REPORT~GET_DATA
* +-------------------------------------------------------------------------------------------------+
* | [<-->] DATA TYPE SFLIGHT_T
* | [!CX!] CX_AMDP_ERROR
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD zif_xlsx_report~get_data.
"調用AMDP類的方法
"資料處理
ENDMETHOD.
ENDCLASS. 3，在report程式中調用各個實作類。
這是關鍵的一步：在report程式中動态地擷取全部實作類，并依次執行個體化、調用其接口方法。
CONSTANTS: c_interface TYPE seoclsname VALUE 'ZIF_XLSX_REPORT'.
TRY.
DATA(gt_classes) = cl_sic_configuration=>get_classes_for_interface( c_interface ).
CATCH cx_class_not_existent .
ENDTRY.
LOOP AT gt_classes INTO DATA(gs_class).
TRY .
CREATE OBJECT go_ref TYPE (gs_class-clsname).
CATCH cx_sy_create_object_error.
ENDTRY.
IF go_ref IS BOUND.
go_ref->get_data( CHANGING data = g_data_structure ).
ENDIF.
ENDLOOP. - 由于XLSX Workbench中的一個表單在同一時間隻能由一個人編輯，對于多sheet頁的表格，無法讓兩個人并行開發表單。但是，因為表單獨立于ABAP 程式，二者隻需要通過約定好的内表結構（在示例中是SFLIGHT_T）通信。是以，可以在約定好通信結構的前提下，由一個人進行XLSX Workbench中表單的元件編輯、上下文綁定等工作，另一個（或多個）人進行資料邏輯處理工作。如果在引入了HANA開發人員，還可以把主要邏輯下推至HANA，進而使多人同時在不同層級上開發同一個套表，以提高總體開發速度。
- 将每個sheet頁寫成一個類，所有類繼承同一個接口，在report程式中動态地調用，可以将報表主程式的代碼穩定下來，實作程式的解耦。不同的類之間也是個例的，可以友善地進行單獨的單元測試，而不會在文法檢查時受到其他人的開發内容的幹擾。
- 相比于本文開頭提到的INCLUDE的方式，使用面向對象的新開發模式不僅提供了更好的橫向擴充能力（隻要增加新的實作類和結構字段即可實作資料處理邏輯和報表内容的擴充），而且也提供了更好的縱向擴充能力，可以通過面向對象的強大特性——繼承——來實作對報表中相似部分進行抽象整合。
注意事項
總結了幾點我們在實際開發中的經驗，以供參考。
AMDP與SELECT-OPTIONS
細心的讀者可能已經注意到上文的示例代碼中并未處理選擇螢幕這一關鍵問題。在Open SQL中我們可以很友善地直接使用range table。而在AMDP中使用它話需要一點點額外的代碼：
可以通過CL_SHDB_SELTAB=>COMBINE_SELTABS( )來将選擇螢幕的輸入條件轉換為AMDP中的SQL Script中的WHERE條件字元串，并使用APPLY_FILTER函數應用這一條件，具體的例子：
（引用自 Handling of SELECT-OPTIONS parameters within AMDP）
異常處理
在本文介紹的開發模式下，HANA視圖、XLSX Workbench表單和ABAP類是可以并行開發的，這意味着開發階段的HANA視圖可能處于不穩定的狀态。ABAP開發者應注意在AMDP方法中顯式地聲明異常、并在調用它時進行處理。不然會很容易遇到程式dump的情況:)
具體的異常可見：AMDP異常
自建結構/表命名
無論是AMDP方法還是XLSX Workbench表單，在實踐中都需要自建結構/表來接收資料。在開發内容分離的情況下，作為通信定義的結構/表類型的命名尤其重要。應當有一套合理的規則來為它們以及其中的字段命名。特别是XLSX Workbench表單的參數結構，在表單複雜的情況下，參數結構同樣會是複雜的深度結構，而且XLSX Workbench的元件自動生成功能會以ABAP結構名為元件命名。如果命名不當的話，将會給後續的開發和溝通帶來相當的負擔。
另外，建立XLSX Workbench上下文時，如選擇自動建立，則生成的元件名和描述會與資料字典中定義的資料名與描述一緻。如果定義時能仔細填入這些資訊，對後續的工作很有幫助。
模闆處理
上傳模闆至XLSX Workbench後，建議首先對空模闆進行測試輸出，确認無誤後，再進行context和template的綁定等工作。因為有時導入的模闆也許會出現相容問題，在輸出報表時會提示檔案錯誤。較早地發現、解決這種問題，可以避免後期一些無謂的工作。
XLSX Workbench設定
在使用XLSX Workbench的過程中，點選滑鼠是一項略顯繁瑣的工作，建議把在配置選項中将确認彈窗關掉，以減輕手指負擔：
大報表的列修改問題
報表中增加列、減少列是常見的需求，在使用XLSX Workbench的時候，如果采取了簡單表的輸出方式，那麼插入或删除新列時，就要把這個新列以右的全部列重新綁定至新位置。
在報表總列數較小的情況下，這很容易做到。但某些報表的列數較多，如我們開發的系統使用情況表，約有167列，需求變更的内容是在第5行新增一列，則意味着要重新綁定162個context value，這是件麻煩的工作。為了避免這種情況的發生，在表單的列數較多時，建議使用動态列或其它動态方式實作對表單内容的填充，以降低變更成本。
參考閱讀：SAP BADI的“多次使用”（multiple use）
Dynamic Range
XLSX Workbench下載下傳
轉載請注明