使用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上：

https://github.com/i042416/JavaTwoPlusTwoEquals5/tree/master/src/odata 除了自己動手編寫代碼外，還可以重用一些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流程做了清晰的闡述： https://cloudplatform.sap.com/scenarios/usecases/authentication.html

這張圖描述了在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流程。

浏覽器打開SAP Marketing Cloud Fiori Launchpad連結，HTTP請求發送到了Marketing Cloud系統，後者可以視為Service Provider。

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

關于什麼是SAP ID service，可以檢視SAP官方幫助文檔： https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/d6a8db70bdde459f92f2837349f95090.html IdP的職責是完成實際的使用者認證工作，它給使用者傳回一個登入頁面，要求其輸入使用者名和密碼。

上圖顯示的是SAP ID Service的登入頁面，UI雖然簡單，但是這個頁面的源代碼裡存在很多隐藏字段。

用Chrome開發者工具能夠發現這些隐藏字段：

xsrfProtection

spId

spName

authenticity_token

idpSSOEndpoint

這些字段都是在SAP ID Service的伺服器端生成，然後傳回給用戶端。

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

dP完成使用者認證，頒發一個"assertion"響應，值存儲于HTTP響應頭部的SAMLResponse字段裡。

這個字段的SAML表明這是一個基于SAML協定的認證過程，把上圖Chrome開發者工具裡觀察到的SAMLResponse字段值通過BASE64解碼，得到下圖的XML格式的assertion内容：

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

SAML協定規範的官方文檔：

http://saml.xml.org/saml-specifications

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

我把jMeter項目的工程檔案放到我的Github上了，友善大家重用：

https://github.com/i042416/KnowlegeRepository/blob/master/ABAP/C4COData/jMeter/01-contact-creation.jmx 在jMeter裡，我們按照SAP官網認證架構圖的6個步驟來配置

1. 使用jMeter提供的正規表達式提取器，将認證流程第3個步驟，IdP傳回的登入頁面的5個隐藏字段的值提取出來，存儲成jMeter變量：

   

   下圖顯示了這些隐藏字段的值被成功提取出來并存儲成jMeter變量：

   

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

   

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

   

   發送新的請求給伺服器，擷取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注冊流程。