I am trying to do Data Type validation using web methods. I have an attribute, I need to validate the attribute with respect to data type. For ex. I have attribute Currency Coded which is String, If I enter number, it should validate and say invalid entry. Please suggest how I can achieve this using webMethods.
This can be done in two ways
– Have a variable isValid as output and use the branch step to check for regex expression having only 3 letters string eg. USD, INR if the value does not match the expression make isValid=false and throw exception
– Else you can have the regex on the input string itself and check the validate input and validate output options on developer/designer
Check the developer or designer guide for more details.
1 Like
Can you provide link to designer guide where regex has been handled in webMethods
Page #1146 from 9-10_Service_Development_Help guide.
For better understanding you can refer the link:
http://wm.idn-xchange.com/blogs/90-webmethods-regular-expressions.html
1 Like
May I know how does the validate input and Validate output works, does it validate the datatypes recived againt the input document datatypes.
I think it should try a simple poc else feel free to use “pub.schema:validate”
According to the docs:
Validate Input - Whether or not you want the server to validate the input to the service against the service input signature
As for the validation, there are several ways in which you can do it:
- Using the Validate Input/Validate Output checkboxes
- As M@he$s said, using pub.schema:validate
- Your own custom validation
I personally like option 2 because, on one hand, it gives me control over the actions that are done if the validation fails and, on the other hand, it is easy to use and no extra work goes into it.
The advice given so far is good.
I’d offer another option: don’t do validation “in the middle.” More often than not, it gets in the way rather than helps. For example, I’ve run into instances where Integration Server dutifully validated fields, and flagged content as invalid. When the participating app teams were contacted about it, they said “change middleware to allow it through.” This was after they had indicated, during initial implementation, that middleware should block “invalid” content.
There are times when middleware should validate. But my rule of thumb is – don’t validate in the middle. Rely on the end-points to do so. E.g. when you call the target, and it doesn’t like the value, it will return a failure, which is what you want. Validate in the middle only if absolutely necessary and demonstrably useful to do so.