SAP官网api.sap.com上发布了大量的RestfulAPI，方便合作伙伴和客户将自研应用与SAP解决方案。比如笔者最近在做一个与国内一家专注于提供人脸识别技术解决方案的公司合作的项目。用户通过微信扫码完成人脸识别后，在用户授权后，调用SAPMarketingCloud。联系人API生成对应的联系人数据，将人脸识别得到的面部特征码通过营销云扩展字段存储到联系人数据中。因为这个项目最终要在上海的SAPCloud大会上展示，所以笔者在完成集成工作后想到，我们应该提前测试一下我们MarketingCloud在响应并发请求方面的性能，这样我们就可以对它有一个很好的了解。我们在SAP上海云大会上演示的场景是将SAPMarketingCloud的Launchpad投射到大屏幕上。参与者完成人脸识别后，自动调用MarketingCloud联系人创建API，在系统中生成联系人数据，Launchpad将联系人磁贴的计数器加一。那么接下来就是如何模拟对MarketingCloudAPI的大量并发请求。对于程序员来说，最容易想到的就是自己写一个程序发送大量的请求。笔者选择的最简单的编程方式是在Java程序中创建大量的线程，每个线程发送一个请求。当然也可以直接使用JDK中提供的线程池库。除了自己编写代码，您还可以复用一些API测试工具来达到同样的目的。Postman是API开发者常用的接口调试工具。它还具有变量定义和简单的编程功能：通过称为CollectionRunner的功能，可以一键运行Collection中的多个请求。作者在这篇SAP社区博客中详细介绍了Postman编程：JustasingleclicktotestSAPODataServicewhichneedsCSRFtokenvalidation我在成都C4C开发组的时候，组里的同事告诉我jMeter是另一个功能A强大的基于Java的API压力测试工具。所以在本文中，我选择使用jMeter对API进行压力测试。下面介绍的内容需要你对jMeter的使用有最基本的了解。如果不熟悉，可以先查阅jMeter官方文档。大致的思路是利用jMeter提供的两个工具，ThreadGroup（线程组）和controller。ThreadGroup帮助工具使用者实现通过多线程发送HTTP请求的功能，比如下图中设置100，表示同时通过100个线程发送请求。对于涉及写入系统的SAPAPI，例如创建、修改或删除数据的SAPOData服务，请求的HTTP标头必须附有CSRF令牌（有时也称为XSRF令牌：跨站请求伪造）.我们可以把从服务端获取CSRFtoken的请求和真正调用联系人API的请求放在同一个controller中，从而保证获取token和创建联系人这两个请求在同一个线程中顺序执行.SAP云平台官网有帮助文档，里面很清楚的解释了用户访问SAP云平台服务的Authentication流程：这张图描述了Authentication场景下的几个名词User（有时也叫Client），交互ServiceProvider和IdentityProvider（简称IdP）之间的关系。虽然在本文描述的场景中，我使用jMeter消费的是MarketingCloud上的服务，而不是SAP云平台上，但是这些服务对应的Idp是SAPID服务，即accounts.sap.com，所以Authentication原理还是一样的。我们牢记这张图中的步骤，因为当我们使用jMeter来消费MarketingCloudAPI时，我们也必须遵循这个身份验证流程。我们先使用Chrome访问SAPMarketingCloudFioriLaunchpad，深入了解图中描述的Authentication流程。(1)浏览器打开SAPMarketingCloudFioriLaunchpad链接，向MarketingCloud系统发送HTTP请求，可以看作是一个ServiceProvider。(2)MarketingCloud通过HTTP302将请求重定向到其预先配置的IdP，即SAPID服务（即account.sap.com）。关于什么是SAPID服务，可以查看SAP官方帮助文档：（3）IdP的职责是完成实际的用户认证工作。它向用户返回登录页面并要求其输入用户名和密码。上图为SAPIDService的登录页面。UI虽然简单，但是这个页面的源代码中隐藏了很多字段。这些隐藏字段可以用Chrome开发者工具找到：xsrfProtectionspIdspNameauthenticity_tokenidpSSOEndpoint这些字段在SAPID服务的服务器端生成，然后返回给客户端。(4)用户输入密码并点击登录按钮后，用户输入的用户名和密码连同第三步介绍的登录页面的隐藏字段一起返回给SAPIDService服务器。这些字段可以在HTTP请求标头中的Chrome开发者工具中观察到。(5)IdP完成用户认证并发出“断言”响应，其值存储在HTTP响应头的SAMLResponse字段中。该字段中的SAML表示这是一个基于SAML协议的认证过程。上图中在Chrome开发者工具中观察到的SAMLResponse字段值经过BASE64解码得到XML格式的断言内容如下图：box是断言的状态，值为success。因为SAPID服务和MarketingCloud系统配置为相互信任，这意味着SAPID服务通知MarketingCloud用户的身份验证已通过。SAML协议规范官方文档：http://saml.xml.org/saml-spec...有了上面的理论基础，配置jMeter项目的思路就清晰了。在jMeter中，我们按照SAP官网认证架构图的六个步骤进行配置：(1)使用jMeter提供的正则表达式提取器提取第三步IdP返回的登录页面的五个隐藏字段authenticationprocess提取值并存储为jMeter变量：下图为成功提取这些隐藏字段的值并存储为jMeter变量：（2）提取并存储的五个字段的值在第一步的jMeter变量中（下图红色的值），加上用户手动输入的用户名和密码（下图蓝色），作为请求的header字段，提交给SAPID服务一起：登录成功后，收到服务器返回的cookie值：(3)向服务器发送新的请求，获取CSRFtoken。本次请求的响应中包含下图高亮显示的两个cookies，上一次请求需要将其存储为jMeter变量。(4)最后一步，将上一步获取的CSRFtoken附加到HTTP请求字段中，同时带上上一步服务器返回的两个Cookie字段：至此jMeter项目的配置就完成了，这比Java编程和Postman的区别是我们一行代码都不需要写，我们并发测试API的所有相关功能都可以通过jMeter中的配置来完成。最后简单测试一下并发请求的响应时间：我在使用jMeter调用联系人API创建job时使用了一个简单的随机数生成器，在联系人的姓氏后面添加了一个简单的随机数。ThisisthelastcontactgeneratedinjMeterDisplayinMarketingCloud：最后一步是设置SAPMarketingCloudLaunchpad中联系人磁贴的计数器刷新间隔为每10秒刷新一次：最后系统显示一共276个上海SAP云大会演示现场展台瓷砖嘉宾通过人脸识别完成MarketingCloud联系人注册流程。总结本文首先介绍了UserAuthentication场景下Client、ServiceProvider和IdentityProvider的相互划分和交互原理，然后以SAPMarketingCloudContact创建这个RestfulAPI为例，详细分享了jMeter的使用产生大量的并发请求来实现它。并发负载测试的步骤。
