You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
Learn more about the Blueriq validation types BankAccount, IBAN, Date, Number, Regexp, SofiNumberValidator, StringLength.
Index:
BankAccount
This type checks whether a bank account number is valid. You can use this validation on attributes of base type string. Please see also Validation type IBAN.
Syntax
<type><locale>
Type - The type can be either 'bank' for bank account numbers or 'giro' for giro account numbers, or a combination 'bank/giro'.
Locale - Specify the country code for which you want to validate the bankaccount number, e.g. nl_NL for the Netherlands.
Examples
Assume you have added the validation type BankAccount with parameters <bank><nl_NL> to the attribute Client.BankaccountNr, then
Client.BankaccountNr = “123456789” is valid;
Client.BankaccountNr = “123456780” is invalid.
Assume you have added the validation type BankAccount with parameters <giro><nl_NL> to the attribute Client.BankaccountNr, then
Client.BankaccountNr = “P55555” is valid;
Client.BankaccountNr = “55555” is invalid.
Date
Use this type to construct validations for specific date formats. You can use this validation on attributes that have base type date.
Syntax
<comparedate><comparator><compareday><comparemonth><compareyear>
comparedate - Compare the attribute value to a specific date, the dateformat of this date should be 'yyyy/MM/dd'.
comparator - The type of comparison, this can be 'less', 'equal' and 'greater'.
compareday - There are three options:
a number between 1 and 31; the day part of the attribute value is compared with this value.
'+' followed by a number; the day part of the attribute value is compared with the current day '+' the specified number.
'–' followed by a number; the day part of the attribute value is compared with the current day '–' the specified number.
comparemonth - There are three options:
a number between 1 and 12; the month part of the attribute value is compared with this value.
'+' followed by a number; the month part of the attribute value is compared with the current month '+' the specified number.
'–' followed by a number; the month part of the attribute value is compared with the current month '–' the specified number.
compareyear - There are three options:
a number; the year part of the attribute value is compared with this value.
'+' followed by a number; the year part of the attribute value is compared with the current year '+' the specified number.
'–' followed by a number; the year part of the attribute value is compared with the current year '–' the specified number.
Examples
Suppose that TODAY = 07-10-2004.
| Explanation | Validation rule |
|---|---|
| value = 01-02-2004 | <2004/02/01><equal> |
| value > 1 month from today | <><greater><><+1> |
| value < 1 year ago | <><less><><><-1> |
IBAN
This type validates a string as International Bank Account Number (IBAN) performing a basic mod-97 calculation (ISO 7064) and country specific pattern checks. IBAN has no parameters.
Examples
“TN5910006035183598478831” validates as IBAN.
“TN5910006035183598478830” does not validate as IBAN.
The validator may return true for invalid bank account numbers. No bank specific account restriction checks are performed.
Number
This type checks the boundaries of an attribute with base type number, integer, currency or percentage.
Syntax
<maxIncl><minIncl><maxExcl><minExcl>
maxIncl - The attribute value should be less than or equal to this value.
minIncl - The attribute value should be greater than or equal to this value.
maxExc - The attribute value should be less than this value.
minExcl - The attribute value should be greater than this value.
Examples
| Parameters | Value | Result |
|---|---|---|
| <><0> | 0 | valid |
| <><><><0> | 0 | invalid |
| <><><><0> | 1 | valid |
| <120><><><0> | 120 | valid |
| <><><120><0> | 120 | invalid |
| <><><120><0> | 119 | valid |
| <5.1345><><><1.2345> | 5.1345 | valid |
| <5.1345><><><1.2345> | 1.2345 | invalid |
Regexp
This validation type checks whether a string value is part of a specified set of strings. You can use this type to validate a string as a correct postal code format, telephone number or email address.
Syntax
<posRegExp><negRegExp>
posRegExp - The attribute value should satisfy this regular expression.
negRegExp - The attribute value should not satisfy this regular expression.
The following characters are allowed in these regular expressions:
^[0-9]{4}\s{0,1}(?)[a-zA-Z]{2}$
The regular expressions used in several Blueriq Encore functions are common Java 1.4 expressions. For a complete documentation we refer to the online java documentation.
When writing regular expressions, you should make sure that they do not make the system vulnerable to ReDos attacks. The system can give a denial of service when an evil expression is used, that takes very long to evaluate by the parser.
Examples of evil regular expressions:
- (a+)+
- ([a-zA-Z]+)*
- (a|aa)+
- (a|a?)+
- (.*a){x} | for x > 10
The above are suspectible to aaaaaaaaaaaaaaaaaaaaaaaa!
It is difficult to give general rules that make sure that your expression is not evil, and even recognizing them can be hard. When writing regular expressions, consider Atomic Groups which help to avoid the evil behavior.
Examples
Postal code
<^[0-9]{4}( ?)[a-zA-Z]{2}$>
| Value | Result |
|---|---|
| “1000 AA” | valid |
| “1000AA” | valid |
| “10001AA” | invalid |
Telephone number
<(^\+[0-9]{2}|^\+[0-9]{2}\(0\)|^\(\+[0-9]{2}\)\(0\)|^00[0-9]{2}|^0)([0-9]{9}$|[0-9\-\s]{10}$)>
| Value | Result |
|---|---|
| “010 1234567” | valid |
| “+31(0)10 1234567” | valid |
| “010-1234567” | valid |
| “010 123456789” | invalid |
E-mail address
<^.+@[a-zA-Z0-9\-\.]+\.([a-zA-Z]{2,4})$><(@.*@)|(\.\.)|(@\.)|(\.@)|(^\.)|\s>
| Value | Result |
|---|---|
| “test@email.nl” | valid |
| “test@email.failure” | invalid |
For more examples, you can check this website: http://www.regexlib.com/
SofiNumberValidator
This type checks whether a social security number is valid. You can use this validation on attributes that have base type string.
The validator performs the "Elfproef" (11-check), and checks that the number has exactly 9 digits and does not start with '00'.
Syntax
<locale>
locale - Specify the country code for which you want to validate the social security number, e.g. NL for the Netherlands.
Examples
Assume you have added the validation type SofiNumberValidator with parameter <NL> to the attribute Client.SocialSecurityNr, then
Client.SocialSecurityNr = “123456782” is valid;
Client.SocialSecurityNr = “123456789” is invalid.
StringLength
This type validates the length of a string value.
Syntax
<minLength><maxLength>
minLength - The length of the attribute value should be greater than or equal to this value.
maxLength - The length of the attribute value should be less than or equal to this value.
Examples
| Parameters | Value | Result |
|---|---|---|
| <><5> | “john” | valid |
| <2><> | “a” | invalid |
| <4><8> | “username” | valid |
Overview
Content Tools
8 Comments
Ciarán Lier
I see that Blueriq does not give a validation warning or error when selecting Validation Type StringLength for an integer attribute.
Will it work correctly though?
Unknown User (m.schadd)
Probably not. I would expect a runtime error. You should use the Number validator with an appropriate range.
Ciarán Lier
Confirmed: It causes a runtime error when showing the attribute on screen.
Paul Wouters
Why does IBAN NL00INGB0001239874 pass the IBAN check? (tested at NN in BQ9 and BQ11)
The control number (the 00 in this case) cannot be 00.
The control number is 98 - mod 97 of a large integer. That mod 97 is lower than 97. Therefor the control number is 02 or higher.
For this IBAN 97 would be the correct control number. NL97INGB0001239874 passes the check.
I wonder what the check is doing exactly.
Joost Koehoorn
Blueriq verifies the IBAN only using a mod-97-10 computation of the full input. It does not independently verify the check digits, which is how the 00 is accepted in this case.
Paul Wouters
Does that mean the mod-97-10 computation is insufficient as an IBAN check?
Paul Wouters
According to https://en.wikipedia.org/wiki/International_Bank_Account_Number:
The ECBS document replicates part of the ISO/IEC 7064:2003 standard as a method for generating check digits in the range 02 to 98. Check digits in the ranges 00 to 96, 01 to 97, and 03 to 99 will also provide validation of an IBAN, but the standard is silent as to whether or not these ranges may be used.
Our backend is less silent. SAP says NO!
So the check could be insufficient, depending on the system processing the IBAN. Something to be aware of!
Joost Koehoorn
Based on this example I can only conclude that it is insufficient, indeed. There is already a warning note in the documentation:
the validator may return true for invalid bank account numbers. No bank specific account restriction checks are performed.
Bank account checks vary greatly between countries, e.g. we have 11-mod checks in the Netherlands unless it's a legacy Postbank number, etc; these conventions are not verified by Blueriq. The check digit, though, seems to be unambiguously computed from any IBAN number so it could potentially be verified regardless of country.