使用CDS view開發SAP Marketing contact的facet追溯工具

這篇SAP社區博客里，我的一位同事介紹了SAP Marketing里contact facet數據模型的存儲表：

https://blogs.sap.com/2016/07/01/how-does-sap-hybris-marketing-build-the-golden-record-of-an-interaction-contact/

主要是這兩張表：

CUAND_CE_IC_ROOT

CUAND_CE_IC_FCET

現在我的需求是：對系統里Contact的Origin Data數據來源渠道個數從高到低的順序進行排序：

解決方案：開發兩個CDS View

zcontact_origin

@AbapCatalog.sqlViewName: 'SQL_VIEW_NAME' @AbapCatalog.compiler.compareFilter: true @AbapCatalog.preserveKey: true @AccessControl.authorizationCheck: #CHECK @EndUserText.label: 'Contact Origin tool' define view zcontact_origin as select from cuand_ce_ic_root as a inner join cuand_ce_ic_fcet as b on a.db_key = b.parent_key { key a.db_key, a.name_text, a.smtp_addr, b.db_key as children_key, b.id_origin }

zcontact_count

@AbapCatalog.sqlViewName: 'ZCONCOUNT' @AbapCatalog.compiler.compareFilter: true @AbapCatalog.preserveKey: true @AccessControl.authorizationCheck: #CHECK @EndUserText.label: 'count aggregation' define view ZCONTACT_COUNT as select from zcontact_origin { key zcontact_origin.db_key, zcontact_origin.smtp_addr, count(*) as facet_count } group by db_key, smtp_addr

最后的效果：

這篇文章本來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請求頭部。

IdP完成用戶認證，頒發一個"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個步驟來配置：

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

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

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

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

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

最后一個步驟，將前一步獲取到的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注冊流程。

ABAP ERP HTTP JavaScript 移動APP

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。