Hello @EdgarIvanV,

What you use depends a little on your situation. For your alphanumeric requirement, try Property validation. It's simple. Look at Edit Validate rule AlphaNumericValidation. Specify this on the Advanced tab of your property under "Use validate". See AlphaNumericValidation's references for another example how to use it in a Validate rule.

My understanding is this "Use validate" validation will fire as part of the Dictionary validation, which is core and happens all the time. They fire as Java on the server. Some also have OOB Javascript siblings that fire on the browser for fast user feedback. You can also write your own Javascript counterparts when needed.

On the other hand, referencing the Edit Validate in a Validate rule is more flexible than the Property, but you are responsible to fire the Validate somewhere.

For your decimal requirement, my experience suggests this is trickier to interpret the requirement. You'll definitely want to create a Property with Decimal type. Do you really want to (1) restrict the user input to 2 decimals? Alternatively, do you (2) want to end up with a 2 decimal result in the data (as might be the requirement for financial applications)? Or do you (3) want to display the number as a rounded result.

For (1), there isn't a control option to literally stop input at 2 decimal places. I think this would be a custom control.

Option (2) is simpler: If you don't care about if and how it is rounded, on the Property's Advanced tab use a Property Qualifier at the bottom. Select pyDecimalPrecision and specify "2". This will fire on user Submit or submitting section refresh.

More elegantly, create an Edit Input rule (optionally with corresponding Javascript). Reference the Edit Input from the Property's Advanced tab, similar to Edit Validate. For example, I just created one with...

try {
  java.math.MathContext mc = new java.math.MathContext("precision=16 roundingMode=HALF_EVEN");
  theValue = new java.math.BigDecimal(theValue, mc).setScale(2, mc.getRoundingMode()).toPlainString();
} catch (NumberFormatException|ArithmeticException e)
{
  // return theValue;
}

I know there's a lot going on there, but it's necessarily complicated. The user input is always a String, must be converted to a number using the correct numeric type, the type of rounding specified, and format exceptions handled. Without a corresponding Javascript implementation, this will fire when the user submits or you have a submitting section refresh. At that point, whatever the user entered is rounded to 2 decimal places on screen and in memory. If you also implement in Javascript, it's "belt and suspenders". The user gets immediate feedback as their number is rounded as soon as they tab out of the control. If somehow that fails to happen, the server will fix it on Submit.

Option (3) is easiest. The UI Decimal input control only has decimal options for display. In the latest Pega versions it looks and behaves well on the UI. Use this option if it is at all appropriate.

If I can offer more broadly, regarding isAlphaNumeric from your post, explore the Function rules, which are just static Java functions. If that's new to you, have a programmer buddy help you interpret messages like this.

For instance, if you search for Pega Function isAlphaNumeric you'll see it takes a parameter Java char, which is different from String. That's why you received that error message.

If you encounter more complex input validation requirements, regular expressions are my favorite way to validate strings and numbers against pattern matches. For Pega you would refer to the Java flavor of regex.

For instance, I recently created a more complex filename pattern matcher in my function Library on the Static Variable tab:

EXTRACT_NAME_PATTERN  = java.util.regex.Pattern.compile("(?:BIX)(?:_.*_)(?<extract>\\p{Alpha}*)_(?<date>\\d*)_(?<sequence>\\d*)\\.zip")

The advantage of declaring it at the Library level is it compiles only once. Pattern compilation is a bit expensive. In your case, an alphanumeric match might be...

/* See https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html
   for the reference to \p{Alnum}. The backslash is a regex escape, and must
   also be escaped to use in the Java String as a literal. */
ALPHA_NUM_PATTERN = java.util.regex.Pattern.compile("\\p{Alnum}")

Then inside the Pega Function, you have code similar to...

java.util.regex.Matcher extractMatcher = EXTRACT_NAME_PATTERN.matcher(myInputStringToMatch);

if (extractMatcher.matches()) {
  // do whatever you need, e.g.
  return true; // respond that we validated
}

If this is Greek to you, find that buddy. The advantage of "regex" is being able to create very specific, arbitrarily complex matches with very little code.

Lastly, Pega has a couple built-in functions for the "find" capability of regex, but they are so-so. You can't precompile patterns, and they only find, not match the entire input.