出於工作需要，Jerry寫了這篇文章，給某些Partner做參考。

以前Jerry曾經介紹過SAP C/4HANA的五朵雲到底包含哪些具體產品，其實在SAP官網上有更權威的中文解釋：

SAP C/4HANA Sales Cloud使用OData服務和第三方系統整合的一個具體例子

其中明確提到銷售雲包含SAP Cloud for Customer(C4C)，SAP Revenue Cloud和Callidus Cloud。

有Partner詢問有沒有更詳細的步驟介紹，關於如何在第三方系統裡呼叫SAP C4C暴露出的Restful API進行整合。本文就給出一個具體的例子，將SAP C4C銷售訂單的建立功能透過自定義的OData服務暴露出來，然後Partner可以根據專案需要選擇合適的程式語言(本文選擇JavaScript)來消費。

Jerry以前釋出過一個影片，演示瞭如何在SAP C4C裡手動建立一個銷售訂單，步驟可以說簡單易懂。

https://v.qq.com/x/page/d0809f4tswl.html

現在我們透過OData的方式將銷售訂單的建立功能暴露出來，就能在第三方系統或者應用裡完成C4C的訂單建立。

大家如果對SAP OData還不太瞭解，可以先讀一讀我這篇文章開頭的部分：

SAP OData程式設計指南

下面是詳細步驟。

登入C4C系統，訪問工作中心Administrator，工作中心檢視OData Service Explorer，這裡可以在SAP釋出的標準OData服務和客戶自定義的OData服務之間切換。

因為客戶自定義OData服務能夠允許客戶自行決定從哪一個Business Object的哪一些節點，選擇哪一些欄位來生成OData模型，透過這種靈活的方式可以避免Business Object上客戶業務場景裡不需要的欄位出現在OData模型中。

點選New按鈕新建一個OData服務：

給Work Center View欄位指定一個用來做許可權控制的檢視，只有分配了這個檢視的使用者才有許可權訪問這個OData服務。

點選Select Business Object從彈出對話方塊中選擇基於哪一個Business Object建立OData模型。

下圖就是一個已經建立好並處於Active狀態的OData服務。左邊顯示的是CustomerQuote這個BO的Root節點的所有欄位，每個欄位都有一個可以勾選或取消的Select屬性，勾選則該BO欄位會出現在右側的OData模型裡。

除了Root節點之外，BO的其他子節點上的欄位當然也是可以出現在OData模型裡的，比如我上圖右邊OData模型的子節點CustomerQuoteItem, CustomerQuoteParty和CustomerQuoteText等，就是分別從左邊BO的同名節點選中後自動帶到右邊的OData模型中去的。

理論上，完成基於BO模型進行OData模型的建立並啟用後，這個OData服務就可以使用了，這體現了SAP C4C OData服務自定義框架的強大之處。然而我也收到了一些朋友從後臺給我提的一些問題，羅列如下。

問題1：仍然以本文銷售訂單建立這一場景為例，假設我希望我建立的OData服務能夠允許消費者呼叫時指定External Reference的值，但是我找遍整個BO列表，也沒發現銷售訂單的BO上有叫這個名稱的欄位啊？

Jerry答： External Reference是UI文字，不是BO欄位的技術名稱。

給C4C系統在瀏覽器裡的url新增引數 debugMode=true , 然後重新整理頁面，按住Ctrl鍵再單擊External Reference欄位，

就能看到這個UI欄位繫結到UI模型上哪一個欄位了。

在這個UI模型欄位上再點選Show Model，就能看到這個UI模型欄位繫結到的BO欄位名稱為BuyerID。

所以我們在OData開發工具裡，只需把BO欄位BuyerID選中，移動到右邊的OData模型裡即可。

問題2：我想讓我的OData服務支援行專案資料的建立，比如指定產品ID，描述和購買數量等等。我怎麼知道哪些BO節點上的欄位需要新增到OData模型中去？

Jerry答：現在我們換一種方法，開啟Cloud Application Studio的UI Designer，定位到銷售訂單建立頁面的UI模型COD_SALESORDER_QC，找到Product ID欄位，在它的Properties皮膚裡即可看到這個Product ID欄位繫結的BO欄位的名稱和完整路徑：

Root-.ItemProposal- ProductUUID- content

因此我們需要將BO對應路徑下面的ProductUUID欄位新增到OData模型中去。這裡能觀察到ProductID的Create和Update是沒有勾選上的，而ProductUUID則支援Create和Update，這個行為和C4C銷售訂單行專案建立的標準實現有關——消費者需要提供待建立行專案包含的產品UUID，然後C4C會根據UUID到系統中查詢出對應的產品，顯示其ID到UI上。如果消費者在呼叫OData服務時，沒有指定ProductUUID，則行專案建立邏輯不會執行。

OData模型建立好之後，在用程式語言消費之前，我們可以先用工具Postman(或者C4C自帶的測試工具)進行測試。

因為SAP C4C後臺對 Cross-site request forgery(跨站請求偽造) 這種攻擊採取的防禦實現和SAP CRM，SAP S/4HANA一樣，採取的是 CSRF token驗證機制，因此我們在呼叫OData服務進行銷售訂單建立時，需要將一個合法的CSRF token一併傳遞給C4C系統。

如何得到一個合法的CSRF token呢？在Postman裡構造一個HTTP GET請求，頭部欄位名為

x-csrf-token , 值為fetch：

傳送這個HTTP GET請求，伺服器端會生成一個CSRF token，透過HTTP響應結構頭部欄位x-csrf-token返回給消費者：

sNwnYC9cV4xeGSYZmJ8Dtw==

下面我們再在Postman裡新建一個HTTP Post請求，將之前透過HTTP GET拿到的CSRF token，以HTTP Post請求頭部欄位的方式傳送給C4C系統。

關鍵在於HTTP Post請求的請求體。下圖高亮部分是我在HTTP Post請求裡指定的建立銷售訂單的輸入資料：

在Postman裡傳送這個Post請求，幾秒鐘後得到C4C的響應，訂單建立成功，ID為9000000451：

為了方便大家對比，下面是我用Postman消費我建立的OData服務生成的銷售訂單在系統裡的顯示。欄位1～6對應的Postman輸入欄位可以在前文找到。

藍色區域高亮顯示的欄位，我在Postman裡構造的輸入裡並沒有維護，而是透過SAP C4C系統的各種determination配置，自動決定出來的。最典型的有SAP老司機們天天打交道的Partner determination，Organization determination，Pricing determination等。

Postman裡測試透過後，就可以寫程式碼消費了。

如果想直接複製貼上我下面列出的程式碼，可以從我的github上獲得：

注意本程式碼只用於演示目的，缺少健壯的出錯處理，不能直接用於生產環境中。

下面的程式碼使用nodejs提供的request模組向C4C請求CSRF token。注意第3行的url和第11行的Authorization頭部的值，我都是用的虛假值，請大家替換成自己實際使用的C4C url和認證資訊。