相比於從零開始構建全套資訊化系統，基於成熟的ERP等行業軟體做二次開發是更多中大型企業應對個性化軟體需求的首選方案。如何在二開模組中，可靠地對成品軟體的資料庫進行讀寫操作，以滿足單據自動建立、元資料自動同步等系統整合要求，是擺在開發者面前的難題。今天，我們基於活字格低程式碼平臺的技術支援工作中較為常見SAP HANA為例，為您介紹幾種典型的路線。

方案1：通過ODBC直連HANA，操作原始資料

SAP HANA的客戶端程式中提供了ODBC的資料來源，這就使得開發團隊可以直接通過ODBC連線HANA資料庫，並通過SQL語句對資料庫中的原始資料進行讀寫操作。

（通過ODBC操作HANA）

首先，我們需要在開發環境、測試環境和生產環境的伺服器上，配置SAP提供的ODBC資料來源。在安裝有SAP Client（推薦x64）之後，開啟系統的odbc資料來源管理程式（注意區分64為和32位，需要和SAP Client保持一致）。在"系統DSN"選項卡中點選"新增"，選擇HDBODBC，之後按照介面提示輸入資料來源的名稱，如"HANA-測試庫"、伺服器IP地址、使用者名稱和密碼就可以了。

（建立到HANA的ODBC資料來源）

配置完成後，我們就可以像操作其他資料庫一樣，對 SAP HANA的資料進行讀寫了。回到活字格里面，我們使用"連線到外聯表"功能，引入HANA中需要操作的所有資料表。之後就可以用拖拽的方式完成資料繫結，或者在服務端拼接和執行SQL語句了。

（在活字格低程式碼平臺中引入ODBC資料來源）

如果僅僅是讀取元資料或者一些簡單的單據，這種方案確實是一個簡單的辦法。但是，SAP的資料表結構複雜，且缺乏有效的資料庫指令碼跟蹤能力，我們很難確定一個單據建立過程需要操作哪幾張表的哪些欄位。所以，在涉及到稍微複雜一點的應用場景時，通過ODBC直接操作原始資料的做法的風險較高。

（純程式碼，通過ODBC操作HANA的資料表）

基於多年的技術支援經驗，我們通常不會推薦客戶採用這個方案。

方案2：呼叫NetWeaver API，操作業務物件

SAP顯然也清楚開發者直連HANA，操作原始資料帶來的可靠性風險。所以，SAP推出了NetWeaver整合平臺，給開發者提供了一個原廠級二開解決方案，"儘量"確保寫入的資料不會對SAP系統執行造成威脅。然而，這個平臺的開發成本依然不如人意，以至於大多數開發者在二開專案之初就放棄了這個方案。不過，NetWeaver中對資料表中原始資料的操作封裝成對業務物件的操作，並加入了一些必要的校驗邏輯，這一點對於二開來說還是非常有意義的。更重要的是，這些封裝的介面是開放的，即便我們採用了其他的二開方案，依然可以通過RFC協議，呼叫NetWeaver提供的HANA操作能力，從而避免直接讀寫原始資料帶來的風險。

引入NetWeaver後，二開模組可以不再直接操作HANA資料庫，而是通過位於二開伺服器上的RFC橋（如果對可維護性要求不高，也可直接整合到二開模組中）和位於SAP叢集中的NetWeaver來完成。二開模組通過HTTP等協議呼叫RFC橋，RFC橋則通過RFC協議轉調NetWeaver，NetWeaver則負責在HANA上直接對應的SQL語句。

之所以我們將RFC呼叫部分抽象成一個專門的RFC橋模組，主要是考慮到這部分採用了一個第三方元件庫（SAP原廠的.NET SDK口碑不佳），將其與二開模組進行隔離，可有效降低維護風險。因為客戶採用的是低程式碼的開發方式，這個RFC橋的實現方式為基於活字格服務端程式設計介面開發的自定義WebAPI。對於純程式碼開發者來說，RFC橋通常是一個ASP.NET MVC或Java SpringBoot的Web服務。在實現邏輯和架構原理上，低程式碼與純程式碼大同小異，都需要通過寫程式碼的方式完成。

（通過RFC + NetWeaver操作HANA）

步驟一：使用C#開發呼叫NetWeaver的RFC橋

在這一步中，我們需要使用到Visual Studio（截圖是VS2021）、活字格服務端程式設計介面（截圖是活字格V7.0 Update1）、SAP NetWeaver RFC SDK（截圖是7.5）和開源專案SapNwRfc（https://github.com/huysentruitw/SapNwRfc）。其中SAP的SDK需要客戶使用SAP賬號，從SAP官網下載。

首先，我們在VS2021中建立.NET 4.7.2的類庫工程，引用RFC SDK中lib資料夾的sapnwrfc.dll；然後通過nuget查詢並安裝SapNwRfc包和Microsoft.AspNetCore.Http.Abstractions包（活字格服務端程式設計介面需要依賴這個包）；最後引用活字格伺服器程式安裝目錄中的GrapeCity.Forguncy.ServerApi.dll。為了確保RFC SDK的正常執行，簡化部署操作，我們更建議將RFC SDK的檔案直接拷貝到系統盤下的某個目錄，並且在系統的PATH變數中追加這個目錄下面的lib資料夾，以確保執行時可以準確找到所引用的sapnwrfc.dll。

（Nuget中的SapNwRfc包）

然後，我們需要根據SAP的文件說明，建立RFC的傳入和傳出引數所對應的類。SAP為每一個NetWeaver介面準備一個Excel檔案，記錄了方法名，傳入引數和傳出引數的型別和結構。我們只需要找到所需呼叫的那個介面對應的Excel檔案，根據文件要求建立入參和出參對應的class即可。需要注意的是，屬性的名稱、SapName標籤的值需要和文件中的引數名嚴格保持一致。以建立供應商為例，我們需要建立傳入引數類：CreateVendorParameters和傳出引數類：createVendorParametersObj。

（NetWeaver中建立供應商的介面所對應的引數結構）

然後，我們在工程中建立WebAPI，一個繼承自ForguncyApi的類GetSAPInfo，然後建立POST請求的響應方法CallRFCFunction（方法名和類名組成了URL的Path部分）。在程式碼中，我們從請求中讀取連線字串、需要使用的方法和引數，呼叫SapConnection類的對應方法進行處理，最後把結果序列化後返回給該WebAPI的呼叫者。和屬性名稱一樣，呼叫SapConnection時傳入的方法名也需要和文件中的文字嚴格保持一致，如建立供應商的方法名為ZLIFNR_CREATE。

（RFC橋的WebAPI實現）

根據既往經驗，為了降低呼叫RFC橋的開發者的學習門檻，讓他們也可以參照SAP提供的文件直接進行操作，我們推薦將所有用到的介面統合到一個WebAPI中，在程式碼中通過SAP的方法名進行switch分支。

如需使用這些示例程式碼，可以從碼雲獲取：https://gitee.com/GrapeCity/lowcode_extention_demo_hana_via_sap_rfc

步驟二：在活字格中呼叫RFC橋

使用活字格服務端程式設計介面開發出的WebAPI與純程式碼開發出的WebAPI的使用方法完全一致。在使用活字格開發業務系統的時候，都可以通過"傳送HTTP請求"命令來呼叫。

首先，開發和測試的環境下，我們通常會連線不同的SAP資料庫，所以，我們需要將連線NetWeaver所需的必要資訊儲存到資料庫中，隨程式一同釋出，而不是寫死在程式碼或全域性配置檔案中。

（儲存在資料庫中的NetWeaver連線資訊）

在需要操作SAP的資料時，我們需要先使用"設定變數命令"，從資料庫中讀取當前環境所使用的HANA資料庫的引數，拼接成連線字串；然後使用"傳送HTTP請求命令"，通過呼叫RFC橋的WebAPI。

按照步驟一中RFC橋的實現，其URL地址是customapi/{類名}/{方法名}。我們還需要在HEAD中設定連線字串和方法名（來自SAP提供的Excel文件，如ZLIFNR_CREATE）。

（配置NetWeaver的連線字串和方法名）

而具體的請求引數則需要在BODY中進行設定，將二開系統的業務資料作為引數傳遞給HANA，執行對應的資料操作，最終達到系統整合的效果，如這裡舉例的建立供應商檔案。

（配置傳遞給NetWeaver的業務資料）

下面是我們幫助客戶進行技術評估時，快速構建的活字格與SAP NetWeaver整合的Demo。如需使用這個工程，可以從碼雲獲取：https://gitee.com/GrapeCity/lowcode_demo_hana_via_sap_rfc

（使用活字格整合SAP HANA的效果）

討論

為了幫助開發者做二次開發，SAP和用友等主流廠商大多提供了直連資料庫和封裝業務介面兩種開發模式。在純程式碼開發方式下，兩種模式最大的差異在於前者效能上限更高，後者可靠性更強。

進入低程式碼時代後，封裝業務介面的模式體現出了更強的競爭優勢。比如今天的例子中，在RFC橋的幫助下，業務應用的開發者能通過視覺化配置，輕鬆實現對HANA資料庫的讀取和寫入操作，而這一切，無需掌握任何一門程式語言。專業程式設計師藉助平臺的程式設計介面擴充套件平臺能力，非專業程式設計師通過使用這些能力，視覺化完成系統開發，這種"混合模式"正在成為低程式碼開發的主流。