共计 3488 个字符，预计需要花费 9 分钟才能阅读完成。
在 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 对其产生大量并发申请从而实现并发负载测试的步骤。
