Recently I am working on a co-innovation project with one local partner in China. They will provide a Face Recognition solution which consists of a set of hardware & software. Once a person is recognized, the partner software will consume SAP S/4HANA contact creation API to create a contact instance in the system.
Since we need to deliver this demo in SAP Cloud Forum site in Shanghai, and it is assumed that there will be lots of guests who would like to try this solution which leads to the possibility that multiple contact creation request would be sent to S/4HANA system simultaneously. As a result as one of demo preparation steps, I would like to generate a large number of concurrent contact creation request using jMeter and measure its performance.
As it’s not a big deal to achieve the contact creation API in Postman, the same idea would be applied in jMeter as well: wrap two HTTP request within a Simple Controller, one request responsible for fetch XSRF token and the other for the real creation call. Once executed the jMeter project, the first call succeeds as my expectation – the token is retrieved successfully and available in HTTP response header field “x-csrf-token”.
This error really confused me as I have already got the correct token from server, why validation still failed?
I searched in Google and found this graph from SAP website: https://cloudplatform.sap.com/scenarios/usecases/authentication.html
It demonstrates the Orchestration among client, service provider and identify provider for the service consumption scenario. Although in the diagram it is SAP Cloud Platform which plays the role of Service provider, not S/4HANA, however the logic is exactly the same.
This picture gives me a hint so I open Chrome development tool to inspect the network roundtrip when I access S/4HANA Fiori Launchpad, and soon I realized it is exactly follows the six steps described in the architecture image above.
Step1：I try to access S/4HANA Fiori Launchpad with Chrome – the access request is sent to S/4HANA as Service provider.
Step2: S/4HANA redirects this request to IDP with a HTTP 302 redirect. In my case there is a mutual trust preconfigured between S/4HANA and SAP ID service(that is, account.sap.com).
They are:
xsrfProtection
spId
spName
authenticity_token
idpSSOEndpoint
All of them are generated by SAP ID service in the server side.
Step4: After users type their user and password and click log in button, the credentials will be sent back to IDP along with the hidden fields introduced in step3. All those fields will be involved in IDP authentication in server side, and could be observed in Chrome network tab.
Step5: IDP finishes the authentication, and issues an assertion back in HTTP response header field “SAMLResponse”.
With this assertion, end user can access the resource from S/4HANA now as the last step in the digram.
With all above learnings in mind, I find the cure for token validation failure soon. The complete jMeter project file (.jmx) could be found from my github:
This time the construction of jMeter project exactly abides by the six steps:
Compared with my original jMeter project, two new steps are added, highlighted with red color above.
(1) Create five seperate Regular Expression Extractor to parse the five parameters necessary for IDP server authentications from hidden fields in HTTP response form body:
(2) use the five hidden fields plus user name & password to submit authentication request to SAP ID service.
(3) Now it’s time to fetch CSRF token. The essential point is here: for the subsequent creation API call, it is NOT enough to only submit CSRF token fetched from this step to S/4HANA, which will ends up with CSRF token validation failure introduced in the beginning of this part. Instead, the two cookies highlighted below MUST also be included within HTTP request as well.
This is the reason why I store the two cookies as jMeter variable here.
In the end I also figured out the first two HTTP requests contained in my jMeter project, that is, “get redirected Form data” and “login”, are actually optional. Only keep in mind to store cookies got from CSRF token fetch step and use them in creation API call, and that’s enough.
You can find the source code of this more simplified version here:https://github.com/i042416/KnowlegeRepository/blob/master/ABAP/C4COData/jMeter/02-contact-creation.jmx
I have configured the refresh interval in contact tile as 10 seconds, so once guests in the Cloud Forum on-site demo passed facial recognition, this number just increases to give all guests a hint about the total number. At that day we have totally 276 guests who tested the solution and expressed their interests with our demo
