在 SAP 官网 api.sap.com 里有大量公布的 Restful API，不便合作伙伴和客户自开发利用同SAP解决方案进行集成。

比方笔者最近做的一个我的项目，就是和国内一家专一于提供人脸识别技术解决方案的企业单干, 用户通过微信扫码从而实现人脸识别后，在用户受权的状况下，会调用SAP Marketing Cloud的contact API，生成对应的contact数据，并且将人脸识别得出的面部特色码通过Marketing Cloud扩大字段的形式一并存入contact数据中。

因为这个我的项目最初会在上海举办的 SAP 云大会上展现，所以过后笔者实现集成工作后心想，还是得提前测试一下咱们的 Marketing Cloud 在响应并发申请时的性能, 做到心里有数。

咱们在 SAP 上海云大会上演示的场景是，将 SAP Marketing Cloud的 Launchpad 通过大屏幕投影进去，参会嘉宾实现人脸识别后，Marketing Cloud contact创立API主动被调用，在系统生成contact数据，并且Launchpad contact tile的计数器加一。


所以下一步就是如何模仿大量对Marketing Cloud API的并发申请。

对于程序员来说，最容易想到的形式就是本人入手写一个程序来发送大量申请。笔者抉择的最简略的编程形式，在Java程序里新建大量线程，每个线程发送一个申请，当然也能够间接用JDK里提供的线程池库。

除了本人入手编写代码外，还能够重用一些API测试工具来达到同样的目标。Postman是一个API开发人员罕用的接口调试利器，它也有定义变量和繁难的编程性能：

能够通过称之为Collection Runner的性能，一键运行Collection里的多个申请。

笔者在这篇 SAP 社区博客里具体介绍过 Postman 的编程：

Just a single click to test SAP OData Service which needs CSRF token validation

笔者在 成都 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流程做了清晰的论述：

这张图形容了在Authentication场景下，几个名词User(有时称为Client), Service Provider和Identity Provider(途中简写成IdP)的相互作用关系。

尽管笔者本文介绍的场景，我用jMeter生产的是Marketing Cloud上的服务，而非SAP云平台上的服务，不过这些服务对应的Idp都是SAP ID service，即accounts.sap.com, 因而Authentication原理依然雷同。

咱们牢牢记住这张图的几个步骤，因为咱们接下来用jMeter生产Marketing Cloud API时，同样要遵循这种Authentication流。

咱们先用Chrome拜访SAP Marketing Cloud Fiori Launchpad，来深刻了解图中介绍的Authentication流程。

(1) 浏览器关上SAP Marketing Cloud Fiori Launchpad链接，HTTP申请发送到了Marketing Cloud零碎，后者能够视为Service Provider。

(2) Marketing Cloud把申请通过HTTP 302重定向了它事后配置好的IdP下来，即SAP ID service(也就是account.sap.com).

对于什么是SAP ID service，能够查看SAP 官网帮忙文档：

(3) IdP的职责是实现理论的用户认证工作，它给用户返回一个登录页面，要求其输出用户名和明码。

上图显示的是SAP ID Service的登录页面，UI尽管简略，然而这个页面的源代码里存在很多暗藏字段。

用Chrome开发者工具可能发现这些暗藏字段：

  • xsrfProtection
  • spId
  • spName
  • authenticity_token
  • idpSSOEndpoint

这些字段都是在SAP ID Service的服务器端生成，而后返回给客户端。

(4) 用户输出明码点击登录按钮后，用户输出的用户名和明码，同第三步介绍的登录页面的暗藏字段，会一齐返回给SAP ID Service服务端。能够在Chrome开发者工具里察看到这些字段位于HTTP申请头部。

(5) 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-spec...

有了上述的实践根底后，进行jMeter我的项目的配置工作思路也就分明了。

在jMeter里，咱们依照SAP官网认证架构图的6个步骤来配置：

(1) 应用jMeter提供的正则表达式提取器，将认证流程第3个步骤，IdP返回的登录页面的5个暗藏字段的值提取进去，存储成jMeter变量：

下图显示了这些暗藏字段的值被胜利提取进去并存储成jMeter变量：

(2) 把第一步提取出并存储在jMeter变量中的五个字段的值(下图红色)的值，再加上用户手动输出的用户名和明码(下图蓝色), 作为申请的头部字段，一齐提交给SAP ID service：

登录胜利后，收到了服务器端返回的Cookie值：

(3) 发送新的申请给服务器，获取CSRF token. 这个申请的响应里蕴含了两个下图高亮的Cookie，须要同样存储成jMeter变量，以供最初一个申请应用。

(4) 最初一个步骤，将前一步获取到的CSRF token附加到HTTP申请字段中，同时带上前一步服务器返回的两个Cookie字段：

至此这个jMeter我的项目的配置工作就实现了，其优于Java编程和Postman之处在于咱们不须要编写一行代码，咱们对API进行并发测试这个需要的相干性能点全副可能通过jMeter里的配置实现。

最初简略测试一下并发申请的响应工夫：

我在应用jMeter调用contact API创立工作时用到了简略的随机数生成器，在contact的姓前面加上了简略的随机数，这是最初通过jMeter生成的contact在Marketing Cloud里的显示：

最初一步就是把SAP Marketing Cloud Launchpad里的contact tile的计数器刷新距离设置成10秒刷新一次：

最初零碎显示，在上海 SAP 云大会这个演示场景的展台上，一共有 276 个嘉宾实现了人脸识别后的Marketing Cloud contact注册流程。

总结

本文首先介绍了 Client，Service Provider 和 Identity Provider 在 User Authentication 场景中的相互分工和交互原理，接着以 SAP Marketing Cloud Contact 创立这个 Restful API 为例，具体分享了应用 jMeter 对其产生大量并发申请从而实现并发负载测试的步骤。