摘要：因為這個項目最后會在年月日于上海舉行的云大會上展示，所以當時完成集成工作后心想，還是得提前測試一下咱們的在響應并發(fā)請求時的性能做到心里有數(shù)。

這篇文章本來Jerry只在SAP社區(qū)上寫了英文版的，可以通過點擊文末的“閱讀原文”獲得。后來有兩位做Marketing Cloud開發(fā)的德國同事，寫郵件詢問關于文章的更多細節(jié)，聲稱這種方式對他們自己的API性能測試很有用，所以我覺得還是值得用中文再寫一遍。

在SAP官網(wǎng)api.sap.com里有大量發(fā)布的API，方便合作伙伴和客戶自開發(fā)應用同SAP解決方案進行集成。

比如Jerry上個月做的一個項目，就是和國內(nèi)一家專注于提供人臉識別技術解決方案的企業(yè)合作, 用戶通過微信掃碼從而完成人臉識別后，在用戶授權的情況下，會調(diào)用SAP Marketing Cloud的contact API，生成對應的contact數(shù)據(jù)，并且將人臉識別得出的面部特征碼通過Marketing Cloud擴展字段的方式一并存入contact數(shù)據(jù)中。

因為這個項目最后會在2019年6月5日于上海舉行的SAP云大會上展示，所以當時Jerry完成集成工作后心想，還是得提前測試一下咱們的Marketing Cloud在響應并發(fā)請求時的性能, 做到心里有數(shù)。

我們在SAP上海云大會上演示的場景是，將SAP Marketing Cloud的Launchpad通過大屏幕投影出來，參會嘉賓完成人臉識別后，Marketing Cloud contact創(chuàng)建API自動被調(diào)用，在系統(tǒng)生成contact數(shù)據(jù)，并且Launchpad contact tile的計數(shù)器加一。

所以下一步就是如何模擬大量對Marketing Cloud API的并發(fā)請求。

對于程序員來說，最容易想到的方式就是自己動手寫一個程序來發(fā)送大量請求。Jerry選擇的最簡單的編程方式，在Java程序里新建大量線程，每個線程發(fā)送一個請求，當然也可以直接用JDK里提供的線程池庫。我的Java程序源代碼在github上：

https://github.com/i042416/Ja...

除了自己動手編寫代碼外，還可以重用一些API測試工具來達到同樣的目的。Postman是一個API開發(fā)人員常用的接口調(diào)試利器，它也有定義變量和簡易的編程功能：

可以通過稱之為Collection Runner的功能，一鍵運行Collection里的多個請求。

Jerry在這篇SAP社區(qū)博客里詳細介紹過Postman的編程：

Just a single click to test SAP OData Service which needs CSRF token validation
https://blogs.sap.com/2019/06...

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

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

總的思路就是使用jMeter提供的Thread Group(線程組)和控制器這兩個工具。Thread Group幫助工具使用者實現(xiàn)了通過多線程發(fā)送HTTP請求的功能，比如下圖設定的100，意思是通過100個線程同時發(fā)送請求。

而涉及到對系統(tǒng)進行寫操作的SAP API，比如新建，修改或者刪除數(shù)據(jù)的SAP OData服務，在請求的HTTP頭部必須附帶防止跨域請求偽造攻擊的CSRF token(有時又稱XSRF token:Cross-site request forgery). 我們可以將從服務器獲取CSRF token的請求和真正調(diào)用contact API的請求放到同一控制器里，這樣能確保同一線程內(nèi)，拿token和創(chuàng)建contact這兩個請求依次執(zhí)行。

SAP云平臺的官網(wǎng)上有一個幫助文檔，對用戶訪問SAP云平臺上的服務的Authentication流程做了清晰的闡述：

https://cloudplatform.sap.com...

這張圖描述了在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請求發(fā)送到了Marketing Cloud系統(tǒng)，后者可以視為Service Provider。

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

關于什么是SAP ID service，可以查看SAP官方幫助文檔：

https://help.sap.com/viewer/6...

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

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

用Chrome開發(fā)者工具能夠發(fā)現(xiàn)這些隱藏字段：

xsrfProtection
spId
spName
authenticity_token
idpSSOEndpoint

這些字段都是在SAP ID Service的服務器端生成，然后返回給客戶端。

用戶輸入密碼點擊登錄按鈕后，用戶輸入的用戶名和密碼，同第三步介紹的登錄頁面的隱藏字段，會一齊返回給SAP ID Service服務端?？梢栽贑hrome開發(fā)者工具里觀察到這些字段位于HTTP請求頭部。

IdP完成用戶認證，頒發(fā)一個"assertion"響應，值存儲于HTTP響應頭部的SAMLResponse字段里。

這個字段的SAML表明這是一個基于SAML協(xié)議的認證過程，把上圖Chrome開發(fā)者工具里觀察到的SAMLResponse字段值通過BASE64解碼，得到下圖的XML格式的assertion內(nèi)容：

上圖第一處用紅色矩形框高亮的字段是assertion的狀態(tài)，值為success. 因為SAP ID Service和Marketing Cloud系統(tǒng)配置為互相信任，所以這意味著SAP ID Service通知Marketing Cloud，這個用戶的認證已經(jīng)通過了。

SAML協(xié)議規(guī)范的官方文檔：

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

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

我把jMeter項目的工程文件放到我的Github上了，方便大家重用：

https://github.com/i042416/Kn...

在jMeter里，我們按照SAP官網(wǎng)認證架構圖的6個步驟來配置：

使用jMeter提供的正則表達式提取器，將認證流程第3個步驟，IdP返回的登錄頁面的5個隱藏字段的值提取出來，存儲成jMeter變量：

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

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

登錄成功后，收到了服務器端返回的Cookie值：

發(fā)送新的請求給服務器，獲取CSRF token. 這個請求的響應里包含了兩個下圖高亮的Cookie，需要同樣存儲成jMeter變量，以供最后一個請求使用。

最后一個步驟，將前一步獲取到的CSRF token附加到HTTP請求字段中，同時帶上前一步服務器返回的兩個Cookie字段：

至此這個jMeter項目的配置工作就完成了，其優(yōu)于Java編程和Postman之處在于我們不需要編寫一行代碼，我們對API進行并發(fā)測試這個需求的相關功能點全部能夠通過jMeter里的配置完成。

最后簡單測試一下并發(fā)請求的響應時間：

我在使用jMeter調(diào)用contact API創(chuàng)建工作時用到了簡單的隨機數(shù)生成器，在contact的姓后面加上了簡單的隨機數(shù)，這是最后通過jMeter生成的contact在Marketing Cloud里的顯示：

最后一步就是把SAP Marketing Cloud Launchpad里的contact tile的計數(shù)器刷新間隔設置成10秒刷新一次：

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

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