I read this requirement somewhere few days ago. The solutions given for these were quite lengthy and inefficient. For example
- Using string.indexOf to check for presence of @ and dot(.)
- Loop for all the characters and verify if @ an dot sign is present or not.
I thought that there must be a better way to do it. I did find two ways to do it.
- Without Scripting
- With Scripting
Before we go for solution let’s define our requirement properly
Requirement:
A person should not be able to enter an invalid email address in the field.
Solution without Scripting:
A simple expression in Validation column of the field can do the trick. The expression is as following
*@*?.?* (This expression was provided to me by Jeevan Singh a friend of mine)
But this solution is not full proof and has the following limitations
- The error message displayed is not user friendly.
- Not all the validations can be done. For example it fails if a user is going to enter @@dfjkd.com as email id as we cannot check if the character before @ is a valid character or not.
Solution with Scripting:
function given below will return 1 the email id provided is valid and return 0 if the email id is invalid
function ValidateEmail(emailid)
{
var pat = /(^[\w\.\+\-=]+@[\w\.\-]+\.[\w\-]+$)/g;
var valid = emailid.replace(pat,”Y”);
if(valid == “Y”)
return(1);
else
return(0);
}


(5 votes, average: 3.8 out of 5)
12 Comments at "Validating an Email Address in Siebel"
Hi neel,
just for information, i used to use a little more complex regular expression to check email consistency :
^[0-9a-z]([-_.]?[0-9a-z])*@[0-9a-z]([-.]?[0-9a-z])*\.[a-z]{2,4}$
thanks anyway for you blog.
humm, BTW, after further researches, it appeared that the RFC defining email addresses standard is really much more complicated than that, and neither your RegExp nor mine are correct.
I’m digging a bit more and tell you latter about that (even though I’m going a bit off topic here)…
Hi neel,
so here is my investigation. It is based on the RFC 2822 (http://) and so respect the standard, even though some valid addresses may be deprecated.
function validateEmail(str) {
var rx_local_strict = /^[a-zA-Z0-9\!\#\$\%\*\/\?\|\^\{\}\`\~\&\'\+\-\=\_\.]{1,64}@[^\@]+$/;
var rx_local_quotes = /^\”.{1,62}\”@[^\@]+$/;
var rx_domain_named = /@[a-zA-Z0-9\-\.]{1,255}$/;
var rx_domain_addr = /@\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\]$/;
var rx_wrong1 = /(\.\.)|(^\.)|(\.@)|(@\.)/;
var rx_wrong2 = /^[^\"].*@+.*[^\"]@[^\@]*$/;
if ((rx_local_strict.test(str) || rx_local_quotes.test(str)) &&
(rx_domain_named.test(str) || rx_domain_addr.test(str)) &&
!rx_wrong1.test(str) &&
!rx_wrong2.test(str)) {
return true;
}
else {
return false;
}
}
typo. the URL for the RFC is : http://tools.ietf.org/html/rfc2822
Hi Neel & toxcct,
The expressions you guys have mentioned seem to be too complicated to understand could either of you please help us newbie understand the stratergy that you have adapted because email address is one of the most commonly used fields…
could you pls confirm if u would be writting this code in SetFieldValue Event Handler
I’m currently writing an article to explain in details what i’m doing in my validation function.
you could still read this series of articles about RegExp and Javascript : http://www.webreference.com/js/column5/index.html
For Email Fields Validation in Siebel, I’d better place this code in a BusComp_PreSetFieldValue() handler, or in a BusComp_PreWriteRecord() (Pre- because we want to validate BEFORE the data is actually commited).
I’ll link back my article when it’s done.
Thanks a lot for the clarification & the article reference…
toxcct,
thanks for you such informative inputs.
Hi,
I think that putting *?@*?.??* into the field validation on BC would be sufficient for most of the implementations.
Truth, it’s not 100% “bullet-proof”, but then again, you are checking only the format, so if someone wanted to “fake” the entry, they can always enter something like “asdf@asdf.tv” which would pass as valid format, but probably is not really existing email address.
As regards the message - actually in Siebel 8.0 you can set custom field validation message, so I think the biggest “con” (”unnice” message) is then out, favoring this simple configuration to more complicated scripting.
Futhermore, if script was used, I think it’s better to place the code/call on BC PreWriteRecord. If it is on PreSetFieldValue, it is triggered EVERY time a value in ANY field is set, creating overhead that is probably unnecessary.
Michal
Michal,
you’re partly right.
if a user still want to enforce a validation system, he will always pass. Here, we’re validating an email format, not an actually existing address. So, with my “more complicated” script, of course it’s a bit more comsuming, but it has to be done like that, or not done at all (because you’re validating wrong stuff with your regexp - which is not valid BTW).
also, i agree that the script should be places in the PreWriteRecord, but not because of the server load. it will be executed every time, ONLY IF the field is set to Immediate Post Changes.
Please read the following blog entries:
1. The absolute bare minimum every programmer should know about regular expressions
URL: http://immike.net/blog/2007/04/06/the-absolute-bare-minimum-every-programmer-should-know-about-regular-expressions/
2. 5 Regular Expressions Every Web Programmer Should Know
http://immike.net/blog/2007/04/06/5-regular-expressions-every-web-programmer-should-know/
3. Extreme regex foo: what you need to know to become a regular expression pro
http://immike.net/blog/2007/06/21/extreme-regex-foo-what-you-need-to-know-to-become-a-regular-expression-pro/
The second article has the 5 most common situation including email address where regular expressions are used.
Comment Now!