I recommend that you don’t do validations and let the “backend” worry about it.
Have wM IS pass the data to the JavaEE components and then return whatever they respond with – data response or errors.
But I suspect you feel the JavaEE components need to be “protected” for whatever reason, so the next best thing would be, yes, just keep the validation messages as they are. It is unlikely that mapping them to other values is a meaningful improvement.
Hmm. Is the code I shared earlier insufficient? It will read any string, byte array, stream or file that contain properties (as defined/supported by java.util.Properties) and return a document containing fields that are named exactly as they exist in the properties file. This is a general purpose way of getting config/properties into an IS document. Other services can call it passing whatever they have (usually a filename) and get back an IS doc that has all the settings. The IS doc can be described by an IS document type - the caller of the service would map the output document to a new var that is a doc reference to the doc type (think of this as type casting) so they can easily use the config fields and values. It is not necessary for the caller to pass the field/properties names. The service I shared gets them all.
Here again, the steps shared earlier do this.
Get headers – good.
Get Authorization field - good (though you should research to see if built-in components can interpret/manage this for you so you don’t have to do anything explicit.
Get JSON request - not so good. You cannot get the HTTP body from there. And you don’t need to. It is already in the pipeline. Also, you can get the raw URL string from there (http/requestUrl) but you don’t need to. The HTTP body (if present) and the URL parameters will already be in the pipeline when your service runs. IS content handlers do the work for you.
For the HTTP body, the variable that is present will depend upon the Content-Type. For JSON, application/json, IS will place a var the name of which depends on the setting of watt.server.http.jsonFormat in IS Administrator | Extended Settings.
When Content-Type=application/json the variable in the pipeline is controlled by two things:
* watt.server.http.jsonFormat setting
* the jsonFormat parameter in the URL (typically will not use this though)
- when jsonFormat is:
* parsed: document with a name matching the name in the JSON – e.g. JSON converted into an IS document
* stream: jsonStream
* bytes: jsonBytes
I recommend setting watt.server.http.jsonFormat to stream so that any integration that may need to handle large JSON payloads can potentially do so. If set to other values, it makes it more difficult to support when a service needs the data in a stream (and not all in memory at once). The var is usable in your service right away. Just define it on the Input tab. At runtime, IS will populate it. Then you can do whatever you need with it – convert it to a JSON string, parse to an IS document, pass it on to something else, etc.
While this covers JSON, the same approach can be used for other types like XML and delimited files. IS can be configured to “help” as much as you want to hand the data to your service.
For the URL parameters, IS parses those and places each in the pipeline. All you need to do is declare them on the input tab of your service so that the FLOW steps “know” what to vars to expect and handle them as desired.
Using getTransportInfo has the drawback of making debugging more difficult. When debugging, it will not return the same elements that are returned when the service is invoked via HTTP. There are techniques to deal with that, but we’ll leave that for another time.
Another side trip – security folks are likely to object to storing passwords in any text file (XML, JSON, properties). You can leverage the services in pub.security.outboundPasswords to store passwords used to access other systems in a secure manner. If you’re really ambitious, you can create an IS Adminsitrator-based facility to allow developers to manage passwords stored there. Then services would use pub.security.outboundPasswords services to get them when needed. Including, possibly, your general-purpose “getProperties” service.
HTH.
#EntireX#Mainframe-Integration#webMethods-io-Integration#Flow-and-Java-services#Integration-Server-and-ESB#webMethods