Category: Data Validation

Input Extensions – Input Validation

Input Extensions – Input Validation

Following on from the recent posts about Errors and Input Extensions, this week we’re going to look at input validation and error handling. Not, you will understand, error handling in the JavaScript sense (writing try…catch and so forth) but how to handle errors that the user makes when entering data in your Input Extension.

Let’s set the scene with some simple examples. You have created an Input Extension in the form of an INPUT tag that displays an attribute for the user to enter. You intend to use the validate handler to do the work of testing the user’s data entry and flagging it to the user if they have made a mistake.

So you begin by understanding that the validation handler is ultimately a three way trigger : you can return true (in which case there is no error, and the data entered passes validation) or false (you wish to signal to the user there is an error, without an error message) or better still  a text string which means yes there is an error, and furthermore here is a text string to tell you what it is. For our little example, we will therefore be looking to handle true  and text string.

Basic Validation

var currentValue = document.getElementById("xInput").value;
var bBanana = document.getElementById("xInput").value === 'BANANA';

In the above example, we retrieve the current value of the INPUT and compare it to the text string “BANANA”. If you have entered “BANANA” then you have passed our validation (true) and if not (false).

return "JavaScript Validation Error";

Great. The case is solved, to paraphrase a famous detective. But then, one day, your Input Extension stops working. It mysteriously refuses to validate your user’s data entry, even when the data entry is correct. It simply refuses to let the user go forward, but there is no error message. So where is the problem coming from?

You take a look at the attribute you are supposed to be validating and notice that the rule designer has added something since you last looked:

Input Validation 1

So the rule designer has added a Regular Expression to the attribute. And what you are entering, perhaps, is not matching the RegEx. But how on earth are you supposed to check for that / handle that in an Input Extension? There is no documented process / property set for this, but if you dig down deep enough, you can find the following properties:

Input Validation – RegEx

control._source.config.inputRestriction.regularExpression (the RegEx)

control._source.config.inputRestriction.rawErrorMessage (the message)

The above properties give you access to the rule designer’s RegEx and associated error message. They do NOT, however, test the value of your input against the RegEx. So don’t forget to actually include the RegEx in your validate handler. At a simple level it might be something like this:

var regExpression = new RegExp(control._source.config.inputRestriction.regularExpression); 
var bTestInput = regExpression.test(currentValue);

Again, we will have a boolean variable which will tell us if the text entered has passed the RegEx validation or not. So now you can include this in your standard validation, to be able to present the user with reasonably decent message:

Input Validation - 3

OPA Hub Website Supporters can download an example project from the OPA Hub Shop. You’ll find the official reference online.

Data Validation in Oracle Policy Automation

Data Validation in Oracle Policy Automation

Some people assume that the only answer to a problem with my other favourite software (Oracle Siebel CRM) is to write some script. These days they mean JavaScript, jQuery, Web Services or anything else they can lay their hands on.

The same thing might happen one day with Oracle Policy Automation (and indeed, appears to be happening on an increasing basis). Let’s add some JavaScript! After all it’s just JavaScript, so what can go wrong? All JavaScript can do is pop up warnings and make text blink, right? Wrong. Before you know it you have altered (or at least attempted to interfere with ) the user experience beyond recognition, spent a lot of time and money and probably broken a few Oracle Policy Automation golden rules along the way.

So what has that rant got to do with Data Validation. Well, the other day a colleague and friend (thanks M!) came to me with a question and she was eager not to use JavaScript at all. She is learning some of the features of Oracle Policy Automation and she has the good reflex : think outside Scripting.

The question was, how to validate a data entry. The user must be able to enter between 1 and 100 characters in a Control, and the control can accept tabs, spaces, as well as certain accented characters (the language of data entry was not English). So what options does she have?

Error and Warning Rules for Data ValidationOPA 12 - Data Validation

Our rule designer could create rules that assist the user in at least understanding what they are doing wrong. They could also (assuming they are using at least a reasonably modern version, choose to have those error messages when the user navigates away from the Screen, or from the Control (Show Errors > Immediately or  On Navigate from the Interview tab Ribbon).

Attribute Type Specific Options for Data Validation

For attributes that are not textual – numbers, time of day, dates and so on, then there are a variety of further options that can be applied to the Attribute in the Modeller interface, on the Data tab.

OPA 12 - Data Validation 2

But our intrepid rule designer still didn’t get the level of fine detail she was looking for , in respect of her Text attribute. How to limit the  data input to only that specific set of characters?

RegEx in Data Validation

The most powerful form of Data Validation, and the one that benefits from a huge community of helpers, is Regular Expressions. They can be applied to Text Attributes and as such, can provide a high level of control. For the sake of your sanity, do check that the RegEx you are trying to use is compatible with the Oracle Policy Automation engines (Java and JavaScript – so as the official documentation says

“Be sure to only use regular expression syntax that is supported by both languages, and by all browsers. This is basically POSIX ERE regular expressions, with Perl/Tcl character classes. For more information, including examples on crafting regular expressions, see the Wikipedia article on Regular expressions.”

In the specific case mentioned above, our rule designer was able to use the Unicode values to create the range of characters for our character class. And she used our favorite site to build and test the expression, that looked a little like this


All this proves that Oracle Policy Automation has a whole bundle of things you can achieve in Data Validation without going near JavaScript or jQuery.

Logo by Southpaw Projects LLC