Supercharge your RTP Validations with Groovy

Learn how to use validateRtp

So you create RTPs to get user inputs for your script, but if the inputs are wrong/illogical you would then just error out from the script using @RETURN to let them know something went wrong and why.

From a user experience perspective, this can be annoying when the users have to relaunch the business rule and fill in all the prompts (only to find out they messed up again!)

So here is how you can supercharge your RTP validation with Groovy. To do that, you need to get acquainted with validateRtp.

validateRtp

There are two ways you can use this

• Validate the RTP using logic

• Validate the RTP using a RegEx pattern

So basically you declare your RTPs

/*RTPS: {rtpScenario}, {rtpStartDate}, {rtpEndDate} */

and then you can validate each (or not) by using validateRtp. Here’s how you call it

validateRtp(RTP, VALIDATION, MBL, MBL_RESOURCE_KEY, PARAMS)

• RTP: the RTP you want to validate. E.g. rtps.rtpDate

• VALIDATION: The logic as closure, or a RegEx String

• MBL: The message bundle

• MBL_RESOURCE_KEY: The resource key in the message bundle to get the relevant error message

• PARAMS: Any number of other parameters that you want to pass to the error display

Example 1: Check the Date

Let’s say we create rtpStartDate and rtpEndDate to prompt the user to share a range. Before we begin our business logic, let’s just check if they entered an end date that is AFTER the start date.

/*RTPS: {rtpStartDate}, {rtpEndDate}*/

// Create the message bundle
def mbUs = messageBundle (  ["DATE.EndDateBeforeStartDate":"End date must be after start date. Please recheck dates and try again."] )
def mbl = messageBundleLoader(["en" : mbUs])

// validate rtpEndData
validateRtp(rtps.rtpEndDate, {it.Date.compareTo(rtps.rtpStartDate.Date) >= 0}, mbl, "DATE.EndDateBeforeStartDate")

Let’s see what it looks like in action

I’ve picked Nov 1st as the end date, while the start date is November 24th

When you click launch, it processes immediately

The error message is shown to the user, but the prompts are right there. The user can close the error window, fix the error and launch it again

One other benefit to doing the validations up front is that you won’t have to worry about wrong inputs when you are defining the business logic.

There are many other complex validations you can do, and I’ll explore some more validations that I’ve used in subsequent posts. Oh, and we’ll get to a RegEx example as well.