How to validate your bind variables
Select the Data Resource you want to add. Click "Add". After that, one of the first choices you will need to make is when to evaluate the data resource. You can choose to have the data resource evaluated immediately on page load (eager) or whenever one of the bind variables is updated (explicit).
If you choose the default option, "immediately on page load", then there will be no opportunity to validate your bind variables before execution of the Data Resource. If your Data Resource executes and your bind variable has not been set, instead of fieldName=<valueYouMeantToBind> the query will execute with the condition fieldName=null. If there are 10 million records with fieldName=null, then this could cause a really slow query and annoy your users. So, if you want to do validation, you should select "explicit".
Next, you need to define an event handler that will trigger the Data Resource execution by updating your bind variable. One way would be to define a Client Script that handles the "body" component's "Page ready" event. In the script you would validate that the data you want is available and only update your bind variable if all the data is present. See Creating An Event Mapping [Official ServiceNow Dev].
Note that the "Only when invoked" option is a little confusing. You might think this means you will need to trigger your Data Resource through a function call somewhere, but that is not the case. The way that your Data Resource will be invoked is whenever the bind variables in the conditions are updated. Take a moment to consider what that means. If you are using bind variable(s) that are frequently updated, your Data Resource will get invoked many times. This could be unwanted and cause performance issues. So you need to figure out a way to only change the bind variables when you want your Data Resource to be updated. See the following community question that discusses this dilemma:
In summary, if you are writing a custom Next Experience page, consider if you should add validation for some of your bind variables. Given the added overhead of writing the extra Client Scripts and Event Mappings, you might find that this process is too time consuming to do every time. If you are already hitting performance issues due to missing validation then adding validation is an obvious solution, but sometimes adding validation before you hit an issue would be a good use of time. For example, if you know that the bind variable you are using could potentially be blank or undefined at runtime, you should probably add some type of validation. Also, if you are writing your page against a very large table (1 million rows or more) this makes it more likely that you could hit a slow query when one of your bind variables is invalid. The solutions above are not necessary for every situation, but we wanted to explain this pattern because we have observed it causing issues for many customers.
| < Previous Article | Next Article > | |
| Link to a previous article | Link to the next article |
