After some investigation I have found a solution.
The default WmTestSuite comparator uses JXPath to specify the XPath expressions of the pipeline variables to extract and compare. JXPath allows us to call Java functions - most usefully here: java.lang.String functions.
Given a pipeline variable called (say) “responsePayload”, I can use the JXPath expression “replaceAll(/responsePayload,’\r’,’’)”. This expression, which is applied both to the pipeline and to the “expected” IData file value, removes any carriage returns from the expected and actual strings prior to comparing them. Given this, any variation in newline style (CRLF versus LF) will be ignored when comparing the expected and actual values.
There are two drawbacks to this approach, which are really due to the use of XPath rather than anything to do with the Java functions:
Once you have one XPath expression, every other value you want to test must also be explcitly specified as an XPath expression, or it will be ignored. So if you have 20 fields to test, but only one has this newline issue (or otherwise needs to be referenced via XPath), it’s easier to split that out into a separate test.
If a value does not match its expected value, the resulting test error message will list ALL tested XPath values, including all the fields that DID pass the comparison, so you will need to go digging through the output to identify the mismatched value.