Jerry originally wrote this article in English only on the SAP community, which can be obtained by clicking “Read the original article” at the bottom of the article. Later, two German colleagues in Marketing Cloud development emailed to ask for more details about the article, claiming it was useful for their own API performance tests, so I thought it was worth writing it again in Chinese.
A number of published apis are available at APi.sap.com, making it easy for partners and customers to integrate their own applications with SAP solutions.
For example, Jerry did a project last month, which was to cooperate with a domestic enterprise focusing on providing face recognition technology solutions. After completing face recognition by scanning codes through wechat, contact API of SAP Marketing Cloud would be called with the user’s authorization. Generate the corresponding contact data, and store the facial feature code obtained by face recognition into the contact data through the Marketing Cloud extension field.
Since the project would finally be presented at SAP Cloud Conference in Shanghai on June 5, 2019, Jerry thought after completing the integration work that he would better test the performance of our Marketing Cloud in responding to concurrent requests.
The scene we demonstrated at SAP Shanghai Cloud Conference was that the Launchpad of SAP Marketing Cloud was projected on the big screen. After the participants completed face recognition, the API for creating Marketing Cloud contact was automatically called and contact data was generated in the system. And the Launchpad Contact tile counter is increased by one.
So the next step is how to simulate a large number of concurrent requests to the Marketing Cloud API.
The easiest way for a programmer to think about it is to write a program that sends a lot of requests. The simplest approach Jerry chose was to create a large number of threads in the Java program, each thread sending a request, or use the thread pool library provided in the JDK. My Java program source code is on Github:
Github.com/i042416/Jav…
In addition to writing your own code, you can reuse some API testing tools for the same purpose. Postman is a popular interface debugger for API developers. It also has variable definition and easy programming capabilities:
You can run multiple requests in a Collection with one click through a feature called Collection Runner.
Jerry goes into detail about Postman programming in this SAP community blog post:
Just a single click to test the SAP OData Service which needs CSRF token validation blogs.sap.com/2019/06/10/…
When Jerry was on the Chengdu C4C development team, his colleagues told me that jMeter was another powerful Java-based API stress testing tool. So THIS time I chose jMeter to stress test the API.
If you are not familiar with jMeter, please check out the official documentation.
The idea is to use the Thread Group and controller tools provided by jMeter. Thread Group enables users to send HTTP requests through multiple threads, such as 100, which means 100 threads are sent simultaneously.
And SAP APIS that involve writing to the system, such as SAP OData services that create, modify, or delete data, A CSRF token(sometimes called XSRF Token :Cross-site Request Forgery) must be attached to the HTTP header of the request to prevent cross-domain request forgery. We can put the CSRF token request from the server in the same controller as the contact API call. This ensures that the token request and contact creation are executed in the same thread.
There is a help document on the official website of SAP Cloud platform, which clearly describes the Authentication process for users to access services on SAP cloud platform:
Cloudplatform.sap.com/scenarios/u…
This diagram describes the interaction of the terms User(sometimes called Client), Service Provider, and Identity Provider(abbreviated IdP en route) in the Authentication scenario.
Although in the scenario Jerry introduced in this paper, I use jMeter to consume services on Marketing Cloud rather than SAP Cloud platform, the CORRESPONDING IDPS of these services are SAP ID services. Accounts.sap.com, so the Authentication principle remains the same.
A few steps from this diagram are in our heads because we will follow the same Authentication flow as we consume the Marketing Cloud API with jMeter.
Let’s start by accessing SAP Marketing Cloud Fiori Launchpad with Chrome to further understand the Authentication process described in the figure.
- The browser opens the SAP Marketing Cloud Fiori Launchpad link, and the HTTP request is sent to the Marketing Cloud system, which can be considered a Service Provider.
- Marketing Cloud redirects requests over HTTP 302 to its pre-configured IdP, the SAP ID Service (aka Account.sap.com).
For more information about the SAP ID service, see the SAP help documentation:
Help.sap.com/viewer/65de…
- The IdP, which does the actual user authentication, returns a login page to the user and asks for a username and password.
The figure above shows the login page of SAP ID Service. Although the UI is simple, there are many hidden fields in the source code of this page.
Using Chrome Developer Tools you can find these hidden fields:
xsrfProtection
spId
spName
authenticity_token
idpSSOEndpoint
These fields are generated on the server side of the SAP ID Service and then returned to the client.
- After clicking the login button, the user name and password entered by the user, together with the hidden field of the login page described in step 3, will be returned to the SAP ID Service server. You can observe these fields in the HTTP request header in Chrome Developer Tools.
- The IdP completes user authentication, issues an “Assertion” response, and stores the value in the SAMLResponse field in the HTTP response header.
Assertion this assertion is an ASSERTION based on the SAML protocol. Here is an ASSERTION based on the SAMLResponse field in Chrome developer tools.
The first field highlighted in red is an assertion with a value of SUCCESS. Because the SAP ID Service and the Marketing Cloud system are configured to trust each other, this means that the SAP ID Service notifies the Marketing Cloud that the user has been authenticated.
Official documentation of the SAML protocol specification:
Saml.xml.org/saml-specif…
With the above theoretical basis, the configuration of the jMeter project is clear.
I have put the jMeter project files on Github for easy reuse:
Github.com/i042416/Kno…
In jMeter, we follow the 6 steps of the SAP official website certification architecture diagram to configure:
- Use the regular expression extractor provided by jMeter to extract the values of the 5 hidden fields of the login page returned by IdP, the third step of the authentication process, and store them as jMeter variables:
The following figure shows that the values of these hidden fields were successfully extracted and stored as jMeter variables:
- The values of the five fields extracted in the first step and stored in the jMeter variable (red below), along with the user’s manually entered username and password (blue below), are submitted to the SAP ID Service as the header fields of the request:
After successful login, the Cookie value returned by the server is received:
- Send a new request to the server to obtain the CSRF token. The response to this request contains two cookies highlighted below, which need to be stored as jMeter variables for the last request.
- In the last step, attach the CSRF token obtained in the previous step to the HTTP request field, along with the two Cookie fields returned by the server in the previous step:
This completes the configuration of the jMeter project. The advantage over Java programming and Postman is that we don’t need to write a single line of code, and all the functional points we need to test the API concurrently can be configured in jMeter.
Finally, let’s briefly test the response time for concurrent requests:
I used a simple random number generator when CALLING contact API with jMeter to create work, and added a simple random number after the last name of contact. This is the final display of contact generated by jMeter in Marketing Cloud:
The final step is to set the counter refresh interval for contact tiles in SAP Marketing Cloud Launchpad to 10 seconds:
The system shows that a total of 276 guests have completed the registration process of Marketing Cloud contact after face recognition at the booth of the demo scene of SAP Cloud Conference in Shanghai on June 5, 2019.
For more of Jerry’s original articles, please follow the public account “Wang Zixi “:
