使用jMeter對基於SAP ID service進行Authentication的Restful API進行併發測試

這篇文章本來Jerry只在SAP社群上寫了英文版的，可以透過點選文末的“閱讀原文”獲得。後來有兩位做Marketing Cloud開發的德國同事，寫郵件詢問關於文章的更多細節，聲稱這種方式對他們自己的API效能測試很有用，所以我覺得還是值得用中文再寫一遍。

在SAP官網api.sap.com裡有大量釋出的API，方便合作伙伴和客戶自開發應用同SAP解決方案進行整合。

比如Jerry上個月做的一個專案，就是和國內一家專注於提供人臉識別技術解決方案的企業合作, 使用者透過微信掃碼從而完成人臉識別後，在使用者授權的情況下，會呼叫SAP Marketing Cloud的contact API，生成對應的contact資料，並且將人臉識別得出的面部特徵碼透過Marketing Cloud擴充套件欄位的方式一併存入contact資料中。

因為這個專案最後會在2019年6月5日於上海舉行的SAP雲大會上展示，所以當時Jerry完成整合工作後心想，還是得提前測試一下我們們的Marketing Cloud在響應併發請求時的效能, 做到心裡有數。

我們在SAP上海雲大會上演示的場景是，將SAP Marketing Cloud的Launchpad透過大螢幕投影出來，參會嘉賓完成人臉識別後，Marketing Cloud contact建立API自動被呼叫，在系統生成contact資料，並且Launchpad contact tile的計數器加一。

所以下一步就是如何模擬大量對Marketing Cloud API的併發請求。

對於程式設計師來說，最容易想到的方式就是自己動手寫一個程式來傳送大量請求。Jerry選擇的最簡單的程式設計方式，在Java程式裡新建大量執行緒，每個執行緒傳送一個請求，當然也可以直接用JDK裡提供的執行緒池庫。我的Java程式原始碼在github上：

除了自己動手編寫程式碼外，還可以重用一些API測試工具來達到同樣的目的。Postman是一個API開發人員常用的介面除錯利器，它也有定義變數和簡易的程式設計功能：

可以透過稱之為Collection Runner的功能，一鍵執行Collection裡的多個請求。

Jerry在這篇SAP社群部落格裡詳細介紹過Postman的程式設計：

Just a single click to test SAP OData Service which needs CSRF token validation
https://blogs.sap.com/2019/06/10/sap-just-a-single-click-to-test-sap-odata-service-which-needs-csrf-token-valid/

Jerry還在成都C4C開發團隊時，組內同事就告訴過我，jMeter是另一個功能強大的基於Java的API壓力測試工具。所以這次我選擇用jMeter來對API做壓力測試。

下文介紹的內容需要大家對jMeter的使用有最基本的瞭解，如果還不太熟悉的朋友，可以先查閱jMeter的官方文件。

總的思路就是使用jMeter提供的Thread Group(執行緒組)和控制器這兩個工具。Thread Group幫助工具使用者實現了透過多執行緒傳送HTTP請求的功能，比如下圖設定的100，意思是透過100個執行緒同時傳送請求。

而涉及到對系統進行寫操作的SAP API，比如新建，修改或者刪除資料的SAP OData服務，在請求的HTTP頭部必須附帶防止跨域請求偽造攻擊的CSRF token(有時又稱XSRF token:Cross-site request forgery). 我們可以將從伺服器獲取CSRF token的請求和真正呼叫contact API的請求放到同一控制器裡，這樣能確保同一執行緒內，拿token和建立contact這兩個請求依次執行。

SAP雲平臺的官網上有一個幫助文件，對使用者訪問SAP雲平臺上的服務的Authentication流程做了清晰的闡述：

這張圖描述了在Authentication場景下，幾個名詞User(有時稱為Client), Service Provider和Identity Provider(途中簡寫成IdP)的相互作用關係。

雖然Jerry本文介紹的場景，我用jMeter消費的是Marketing Cloud上的服務，而非SAP雲平臺上的服務，不過這些服務對應的Idp都是SAP ID service，即accounts.sap.com, 因此Authentication原理仍然相同。

我們牢牢記住這張圖的幾個步驟，因為我們接下來用jMeter消費Marketing Cloud API時，同樣要遵循這種Authentication流。

我們先用Chrome訪問SAP Marketing Cloud Fiori Launchpad，來深入理解圖中介紹的Authentication流程。

1. 瀏覽器開啟SAP Marketing Cloud Fiori Launchpad連結，HTTP請求傳送到了Marketing Cloud系統，後者可以視為Service Provider。

1. Marketing Cloud把請求透過HTTP 302重定向了它預先配置好的IdP上去，即SAP ID service(也就是account.sap.com).

關於什麼是SAP ID service，可以檢視SAP官方幫助文件：

1. IdP的職責是完成實際的使用者認證工作，它給使用者返回一個登入頁面，要求其輸入使用者名稱和密碼。

上圖顯示的是SAP ID Service的登入頁面，UI雖然簡單，但是這個頁面的原始碼裡存在很多隱藏欄位。

用Chrome開發者工具能夠發現這些隱藏欄位：

xsrfProtection
spId
spName
authenticity_token
idpSSOEndpoint

這些欄位都是在SAP ID Service的伺服器端生成，然後返回給客戶端。

1. 使用者輸入密碼點選登入按鈕後，使用者輸入的使用者名稱和密碼，同第三步介紹的登入頁面的隱藏欄位，會一齊返回給SAP ID Service服務端。可以在Chrome開發者工具裡觀察到這些欄位位於HTTP請求頭部。

1. IdP完成使用者認證，頒發一個"assertion"響應，值儲存於HTTP響應頭部的SAMLResponse欄位裡。

這個欄位的SAML表明這是一個基於SAML協議的認證過程，把上圖Chrome開發者工具裡觀察到的SAMLResponse欄位值透過BASE64解碼，得到下圖的XML格式的assertion內容：

上圖第一處用紅色矩形框高亮的欄位是assertion的狀態，值為success. 因為SAP ID Service和Marketing Cloud系統配置為互相信任，所以這意味著SAP ID Service通知Marketing Cloud，這個使用者的認證已經透過了。

SAML協議規範的官方文件：

有了上述的理論基礎後，進行jMeter專案的配置工作思路也就清楚了。

我把jMeter專案的工程檔案放到我的Github上了，方便大家重用：

在jMeter裡，我們按照SAP官網認證架構圖的6個步驟來配置：

1. 使用jMeter提供的正規表示式提取器，將認證流程第3個步驟，IdP返回的登入頁面的5個隱藏欄位的值提取出來，儲存成jMeter變數：

下圖顯示了這些隱藏欄位的值被成功提取出來並儲存成jMeter變數：

1. 把第一步提取出並儲存在jMeter變數中的五個欄位的值(下圖紅色)的值，再加上使用者手動輸入的使用者名稱和密碼(下圖藍色), 作為請求的頭部欄位，一齊提交給SAP ID service：

登入成功後，收到了伺服器端返回的Cookie值：

1. 傳送新的請求給伺服器，獲取CSRF token. 這個請求的響應裡包含了兩個下圖高亮的Cookie，需要同樣儲存成jMeter變數，以供最後一個請求使用。

1. 最後一個步驟，將前一步獲取到的CSRF token附加到HTTP請求欄位中，同時帶上前一步伺服器返回的兩個Cookie欄位：

至此這個jMeter專案的配置工作就完成了，其優於Java程式設計和Postman之處在於我們不需要編寫一行程式碼，我們對API進行併發測試這個需求的相關功能點全部能夠透過jMeter裡的配置完成。

最後簡單測試一下併發請求的響應時間：

我在使用jMeter呼叫contact API建立工作時用到了簡單的隨機數生成器，在contact的姓後面加上了簡單的隨機數，這是最後透過jMeter生成的contact在Marketing Cloud裡的顯示：

最後一步就是把SAP Marketing Cloud Launchpad裡的contact tile的計數器重新整理間隔設定成10秒重新整理一次：

系統顯示，在2019年6月5日上海SAP雲大會這個演示場景的展臺上，一共有276個嘉賓完成了人臉識別後的Marketing Cloud contact註冊流程。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":