Actually, the Content-Type header must be specified every time. The jsonFormat URL parameter can be used by clients to override the watt.server.http.jsonFormat setting for a given call. Example: https://myserver.abc.com/rest/MyEndpoint/foo?jsonFormat=bytes will cause wM IS to place a byte array named jsonBytes var in the pipeline regardless of the watt.server.http.jsonFormat setting. Whether or not your service supports that is up to you. The Content-Type: application/json header is critical – without it, wM IS won’t provide the JSON vars to your service. (It will provide something else, but that’s a different topic for a different time.)
For the code that loads properties into an IS document: The forEach loop is iterating over all the keys in the properties object, getting the value of each and then using the properties key and value to place in the IS document. Consider this properties example:
website = https://en.wikipedia.org/
language = English
message = Welcome to \
Wikipedia!
This can be loaded from a file, put into a hard-coded string, etc. Pass any of those to the propertiesToDocument() method I shared earlier and the result will be this in the pipeline (using dots to note they are child elements of document):
document
…website
…language
…message
Then the caller can refer to and use any of those 3 variables in the document directly. Use in a MAP step, pass to a sevice in INVOKE, etc. You can define a document type that has the fields/structure that matches the fields in the properties file.
Why? The steps have converted it to an IS document. You can reference any/all of the fields from the XML in that document. There is no need to use Java to retrieve a particular value. The whole point of converting the XML to an IS document is to be able to easily access those fields. Here are some more details for what to do:
First, an example XML file to use for config.
<?xml version="1.0"?>
<properties>
<ignoreCredentials>false</ignoreCredentials>
<skipVerifySCID>000000</skipVerifySCID>
<issuerCertAliasList>
<alias>some-issuer</alias>
<alias>other-issuer_old</alias>
</issuerCertAliasList>
<trustStoreAlias>DEVTrustStore</trustStoreAlias>
<updateIdExpansionPrefix>zOS/RSU/</updateIdExpansionPrefix>
<updateOrderURITemplate>https://myHost/abcd/UpdateOrder?orderid=%/orderId%</updateOrderURITemplate>
<orderidPattern>R[A-Z0-9]{9}</orderidPattern>
</properties>
Based upon that, we have defined a document type:
With these 2 items, we call the common service we have to load the file the contents of which are now in a document variable. The “getPropertiesEx” is our service that does the getFile, xmlStringToXMLNode, etc. steps.
Later in that service, we simply map the fields that are needed for the processing we want to do:
There are no Java services in any of that. Not needed.
You’d do a similar thing if you want to use a properties file (or JSON) instead of XML. Though for properties you’d use the Java code shared to do the conversion from the properties object to the IS document.
That’s an interesting perception since properties have been around a bit longer than XML. 
XML has a variety of things that make it less desirable, but I don’t think age is one of them.
You could also use .ini files if the notion of sections would be useful. The Java code to parse and convert those to an IS document is a bit different but readily doable.
Don’t expect perfect data. The main point I was trying to make is that the J2EE components that you’re passing the data to should already be checking for bad/malicious data – and if they are, you don’t need to do so again.
