Gatling AJAX Servlet error

Hi Folks, I am trying to us Gatling to do some load testing on IBM Rational Team Concert. A lot of the standard operations can be tested fine e.g. login, view dashboard/plan, create work item etc. However, when I try to update a work item I get an error in the application log file that seems to be AJAX related. I guess my question is, can Gatling test AJAX based applications or should I some other tool?

Extract from SCALA File:

Request 1 and 2 fail:
resources(http(“request_1”)
.get(uri1 + “/web/_style/?include=E~&etag=JabBi412fSo_en_US&_proxyURL=%2Fccm1&ss=Hhhr4”)
.headers(headers_1),
http(“request_2”)
.get(uri1 + “/web/_js/?include=E~&etag=JabBi412fSo_en_US&_proxyURL=%2Fccm1&ss=Hhhr4&locale=en-us”)
.headers(headers_2)))

Application Log error message:

2015-11-16 07:09:42,200 [WebContainer : 10 @@ 11:38 <Initial Page Load@98b20e65-a267-4558-b538-ae61074c71ec> /ccm1/web/projects/XL006_22MY] ERROR net.jazz.ajax.servlets.StyleSheetServlet - GET https://www.xxx.xxx.com/ccm1/web/_style/
?include=E~%CE%B7g=JabBi412fSo_en_US&_proxyURL=%2Fccm1&ss=Hhhr4HEADER: Accept = text/css,/;q=0.1
HEADER: Referer = https://www.xxx.xxx.com/ccm1/web/projects/XL006_22MY
HEADER: Cookie = x-com-ibm-team-scenario=88e4ac1c-f1a2-4cde-bc42-5116e65df4fe%3Bname%3DInitial+Page+Load%3Bextras%3D%2Fccm1%2Fweb%2Fprojects%2FXL006_22MY%2C1447657780709
HEADER: Host = www.xxx.xxx.com
HEADER: $WSXCTCONTEXTID = F90xogroMNcAACn-M8YAAACU
HEADER: $WSCS = TLS_RSA_WITH_AES_128_GCM_SHA256
HEADER: $WSIS = true
HEADER: $WSSC = https
HEADER: $WSPR = HTTP/1.1
HEADER: $WSRA = 10.226.153.170
HEADER: $WSRH = 10.226.153.170
HEADER: $WSSN = www.xxx.xxx.com
HEADER: $WSSP = 443
HEADER: $WSSI = /ykAAHyZvMtf/IZRdEvuRGzEpHBYWFhYNIFJVgAAH4E=
HEADER: Surrogate-Capability = WS-ESI=“ESI/1.0+”
HEADER: _WS_HAPRT_WLMVERSION = -1
Parameter: include = [E~ηg=JabBi412fSo_en_US]
Parameter: _proxyURL = [/ccm1]
Parameter: ss = [Hhhr4]

org.eclipse.core.runtime.AssertionFailedException: null argument:Unknown resource ID: ηg=JabBi412fSo_en_US

In the end, Ajax is just plain HTTP.
There’s a very good chance your application is built in a way that you can’t just replay as is.
The $WSXCTCONTEXTID and $WSSI really look like security tokens that have to be captured in the previous responses and sent back again.

Thanks for the information Stephane. I will do some further investigating.