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

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

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

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

因為這個項目最后會在2019年6月5日于上海舉行的SAP云大會上展示，所以當時Jerry完成集成工作后心想，還是得提前測試一下咱們的Marketing Cloud在響應(yīng)并發(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請求的功能，比如下圖設(shè)定的100，意思是通過100個線程同時發(fā)送請求。

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

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

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

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

雖然Jerry本文介紹的場景，我用jMeter消費的是Marketing Cloud上的服務(wù)，而非SAP云平臺上的服務(wù)，不過這些服務(wù)對應(yīng)的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重定向了它預(yù)先配置好的IdP上去，即SAP ID service(也就是account.sap.com).

關(guān)于什么是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的服務(wù)器端生成，然后返回給客戶端。

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

IdP完成用戶認證，頒發(fā)一個"assertion"響應(yīng)，值存儲于HTTP響應(yīng)頭部的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...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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