Parameter Validation

 

The main advantage of the parameter validation is that it allows users to ensure that their input text values to write-back queries or stored procedure calls are of the correct type, without having to interpret a complicated database error message.

 

Basically, the user controls this by checking the new “Validate Input Parameters” box, which is situated just below the query text box.

 

This functionality is activated on a per-query basis.If this is turned on for a query, then, regardless of parameter input type, the web service will accept inputs of type string for each of the input parameters.

Then for each input parameter in turn, the compiled web service will attempt to convert the specific text input to the strict type which is configured in the parameter grid.

 

If all the type conversions succeed, then the web service query call will go ahead.

A new sub-tree of values will be present in the web service response XML, under the heading <ValidationResponse> - this will appear as a set of mappable validation values (true or false) in the Xcelsius Data Connection representation of the web service. These validation values can be mapped to display messages or colour changes in the dashboard, to indicate to the user whether their inputs for the data were ok or not.

 

For example, it has been suggested that users may like to build logic inside their dashboard design, to map a true validation response to show a green border on a text box where the value validated successfully, and show a red border where the input text was invalid (i.e. conversion to the required type was unsuccessful)

 

The screenshot below shows the XML from a web service call, where the input parameters validated correctly.

Note that the input parameter names are concatenated into the validation response members.

Validation response can be mapped to a column in the Xcelsius model, allowing user interface control mappings etc.