JMessenger

I've seen this happen a few times in different scenarios - I'm not sure what triggers this issue. - When the profile is initially recorded: HTTP Header Content-Type is set to application/json; charset=UTF-8 - I am able to execute the test many times without having an issue. During these executions Content-Type remains set to application/json; charset=UTF-8 - At some point test executions start sending messages with Content-Type set to text/plain; charset=UTF-8 -- this causes 415 Unsupported Media type errors. Content Type is not null and disabled in Profile -> Properties -> HTTP Headers so to fix this issue I add another Content-Type header set to application/json; charset=UTF-8, checking the Overwrite box for each message with the issue. I recently saw this issue occur in the following scenario but I think it has occurred in other scenarios as well: 1. Laptop execution (this was successfully executed many times): Content-Type: application/json; charset=UTF-8 2.Terminal Server execution (execution failed with 415 errors): Content-Type: text/plain; charset=UTF-8 3. Retried Laptop execution after terminal server execution (executions continue to fail): Content-Type: text/plain; charset=UTF-8

Using WAPT Pro 4.0 and JSON Module. Is there a way to turn off recording of JSONAutoVars? I want to maintain the ability to view responses in JSON format and to create my own JPATH variables but the JSONAutoVars are not always created correctly for my application under test (it is RESTful). For example, the auto-variable is based on Element[1] instead of Element[id=test] - this is a problem because I can not rely upon the the items in an element always being in the same order for every user. Hence while the variables populate correctly for the initial recorded user these variables may fail to populate for other users.

Using WAPT Pro 4.0 with Build Date = September 08, 2015. If a Profile includes Tasks, after a find and replace is performed, the page names in the Profile tree are replaced by the Task Names. Page names remain correct in the page Properties section. Re-opening the scenario is a workaround to resolve the issue.

Using WAPT Pro 4.0 with Build Date = September 08, 2015. The test does not stop as expected if a Stop Session is included and the following configuration is used: 'Stop Session Properties' -> 'Mark the stopped test as failed for the error report' is checked. Profile Setting -> 'Break user session on errors' is NOT checked.

I am currently seeing this same issue with WAPT Pro 4.0