Troubleshooting Business Rules

As you become more familiar with the many different functions you can use with business rules, you will also become aware of many ways that you can combine/nest these rules together. When you make a rule that uses multiple functions, the likelihood of a mistake occurring increases. For this reason, you’ll want to have a strong understanding of how to troubleshoot your rules. This blog will give you some advice that may make dissecting and correcting your rules easier.

In the business rule editor, in many situations, if something is out of place or incorrect, an error message will display in the preview screen. Here are some of the common error messages:

Error: Field ‘test’ Incorrect number of function inputs. Check for invalid number of arguments or missing closed parenthesis.

Error: Field ‘test’ Found an unexpected value ‘)’. Are you missing a closing quotation mark?

Error: Field ‘test’ Found unexpected value ‘false’. Are you missing a comma?

Receiving one of these errors will typically point to an error of syntax.

Error: Field ‘test’ Found an unexpected value ‘)’. Are you missing a closing quotation mark?

Finding the error can be like finding a needle in a haystack.

If the error in this rule just jumps out at you, you deserve a pat on the back — I would guess you had a childhood of fame as you were always the first to find Waldo. However, if the error isn’t easy for you to find, a couple of simple ideas can help you easily break this rule down to find out what is missing.

The first and best practice you can execute is to write clean and readable code. In the business rule editor you aren’t forced to write one long string of characters and functions. Instead, you can write your rules in a way that makes organized sense and that are easy to read, like:

The code here is the same, but the altered code is much easier to digest. When writing rules you are free to include line breaks or spacing in places that make sense for you and the readability of your code.

If the error still isn’t jumping out at you — and it may not be with this change — you are free to paste your rule into an editor like Notepad++, which is a great free tool for checking the syntax of code for many programming languages. If you view the code in Notepad++ through the lens of a particular language (most do — I usually use C#), you’ll notice that the parentheses are highlighted so that you can see that they have a match. Things between quotations are greyed out. You may also notice that the last part of the code is different than the rest, as the last two parentheses look a little different. This is due to the fact that one closing quotation mark was missed in the last line, following $someimage1.

Some business rule savants may wonder why the function JOINNB wasn’t used in the example above. The code used keeps certain images tied to certain image placements when populated. For example, the user will always have a front image in the ITEMIMAGEURL1 placement and a back image in the ITEMIMAGEURL4 placement. On the other hand, a JOINNB function would blindly create a list of images that would populate the next available image field. Business rules usually offer a number of ways to do the same thing, but it will ultimately be up to the writer’s discretion to use the logic that makes the most sense to them.

In addition to the errors listed earlier, you may also receive a message in the preview that says “NaN.” The important thing to know when receiving this message is that NaN stands for Not a Number. When this occurs, the business rule editor was expecting a number to be returned but instead received a string. Often, as rules grow in complication, one may intentionally introduce some criteria that may never be met, as shown in the example below.

If a user has three weights they always expect (1.0, 2.0, or 3.0) and want to trigger a price change based on the weight, a rule like this may be written:

FORMATCURRENCY(

$itemprice*(SELECTCASE(

$itemweight = 1.0, 2,

$itemweight = 2.0,2.4,

$itemweight = 3.0,2.75 “false”)))

Because the weight is always expected to be a constant, the user left themselves open to receiving the NaN error message. If the weight is ever anything outside of the three possibilities or is blank, the value “false” will be returned and multiplied by the $itemprice. Therefore, the editor will return NaN, as a number is expected but cannot be returned.

If a blank value is returned in a situation in which a number is expected, you will also receive a NaN output. For this reason using a function like IFBLANK will be very helpful to ensure you always receive an integer value where one is expected.

The above examples give you an idea of how to troubleshoot an error returned in the business rule preview window. You won’t always be so fortunate to receive an error message that lets you know you have an error in your syntax or logic. Sometimes you’ll only know that your rule isn’t working from the output returned in the preview window. This type of troubleshooting can take much longer. There is, however, one tried and true method that will get you to the root of your unexpected returns. Take the below business rule as an example.

In this rule, if a title contains either Fully Automated, Reader, Read Write, or All Sizes, we would like to change those specific words from the title to FA, R, RW, or AS (in that order). If none of those words occur in the title, we would like to return the title as it is.

If we were to test this rule in the business rule editor with a SKU that has a $title value that is “Samsung automatic reader”, we’d want to change this title to read as “Samsung Automatic R.” This rule won’t function in the way we want it to. Why? There’s one simple way to test this rule: step-by-step logic.

First, we know that $title will return “Samsung Automatic Reader” in the preview window. That much of the rule works, so we can increase the rule to include the next step.

We write CONTAINS($title, “Reader”) in the business rule editor. We may expect this statement to return “True,” however, it doesn’t. Because the word “Reader” isn’t capitalized in the text found in the title, this check will return “False” because the exact phrase isn’t contained in the title. To correct this and account for every instance of this text string, you can use a modifier function like TOLOWER to make all letters of the title lowercased before checking for a match. If you use the function TOLOWER, the search term in the CONTAINS function should also be changed to lowercase:

Trying the individual components instead of tinkering with the rule as a whole will make it much easier to identify the part of your rule that may not be working correctly. You can pick and use a specific SKU in the editor so you know exactly what output you would expect for each of the conditions, and then you can finally start to combine your rule piece by piece to ensure the functions are nested correctly.

In conclusion, these are only a few methods that may be useful when you begin to troubleshoot your business rules. Many other ways to troubleshoot are not outlined here, but hopefully, the examples presented will help you uncover any issues that cause a business rule to fail.