Supported InRule Features

Not all InRule features are available to InRule for JavaScript. Here is a list of the features that are included.

Rule Sets

The following Rule Set types are supported:

• Explicit Rule Sets
• Auto Single-Pass Sequential Rule Sets

Note: Auto Optimized Rule Sets and Auto Sequential Rule Sets are NOT supported.

Rule Constructs

The following rule constructs are supported:

• If Then
• If Then Else
• For Each
• While
• Decision Table
• Language Rule

Versions

The following rule constructs and actions do NOT support versions:

• If Then
• If Then Else
• While
• Decision Table
• Language Rule
• Set Value Action
• While Rule
• Calculation Field

Note: Inline Tables do support versions

Rule Actions 

Below are the rule actions and their corresponding support in the JavaScript rules engine.

Note: The "Deep copy" option for the Add Collection Member and Copy Collection actions are NOT supported in the JavaScript rules engine.

Data Access

• Inline Tables are supported.
• SQL Queries are supported, but only against Inline Tables and SQL Queries that target Inline Tables.
• Execute SQL Query Actions do not support "auto-mapping" of fields. There must be explicit field mappings in the "Settings..." menu.
• Inline Value Lists are supported, but fields bound to Inline Value Lists are not supported.

Functions 

Below are the functions and their corresponding support in the JavaScript rules engine.

Decimals

The precision of Decimals in JavaScript rule engine is different than in the .NET rule engine. The .NET rule engine uses System.Decimal data types, whereas the JavaScript rule engine uses JavaScript's Number data type. The JavaScript Number data type conforms to the IEEE 754 floating point standard, which is equivalent to the Double data type in .NET.

Decimal arithmetic calculations within the JavaScript rule engine that encounter a NaN, Positive Infinity, or Negative Infinity will result in a runtime error.

Complex math functions such as Sqrt, Exp, and Power use the JavaScript Math object with the native Number data type, which is equivalent to the System.Math object used by these functions in the .NET rule engine.

The Round and BankRound functions only support precision up to 15 digits.

The Mod function uses the IEEE modulus algorithm. Since some decimal numbers cannot be represented exactly in binary form, some calculations involving decimal values will give slightly different results in JavaScript.

Integers

InRule Integers are also represented by JavaScript’s Number data type.

The Number data type cannot represent every contiguous integer value between the range of .NET’s Int64.MinValue to Int64.MaxValue due to the precision limitations of the floating point algorithm, however it may represent some values outside this range.

This means that large positive or negative numbers (above approximately 2^53) may not be represented as a contiguous set of numbers.

For example:

9007199254740992 + 1 == 9007199254740992

9007199254740992 + 2 == 9007199254740994

9007199254740992 + 3 == 9007199254740996

The Random function will return random integer values larger than 2147483647 without producing the same overflow error that would occur in .NET.

NOTE: Although JavaScript supports much larger integer values than .NET, the Random function argument range has been restricted between -999999999999999 and 999999999999999 to circumvent potential precision issues as a result of how numbers are stored in JavaScript.

Dates / DateTimes

InRule Dates and DateTimes are represented by JavaScript’s Date object.

In the .NET rule engine, the origin value for Dates and DateTimes (from numeric 0, boolean false, empty string, or null) is 1/2/0001; in JavaScript we are using the UNIX epoch 1/1/1970 in the local timezone.

Parsing Dates and DateTimes only supports the following formats.

• ISO 8601                     (e.g. 2016-03-24T21:33:55.123)
  • Milliseconds time component may only be 1 to 3 digits in length, and is optional (e.g. 2016- 03-24T21:33:55.1, 2016-03-24T21:33:55)
  • Seconds time component is optional (e.g. 2016-03-24T21:33)
  • Supports date-only (e.g. 2016-03-24)
  • All Dates are parsed in the local timezone
  • DateTimes are parsed in the local timezone unless an optional timezone suffix is provided:
    • 2016-03-24T21:33:00                      -> parsed in local timezone
    • 2016-03-24T21:33:00+01:00           -> parsed in the timezone specified (and converted to the local timezone)
    • 2016-03-24T21:33:00Z                   -> parsed in UTC (and converted to the local timezone)

• RFC 2822                   (e.g. Thu, 24 Mar 2016 21:33:55)
  • Milliseconds time component is not supported
  • Seconds time component is optional (e.g. Thu, 24 Mar 2016 21:33)
  • Supports date-only (e.g. Thu, 24 Mar 2016)
  • Comma after the day name is optional (e.g. Thu 24 Mar 2016)
  • Day name is options (e.g. 24 Mar 2016)
  • All Dates are parsed in the local timezone
  • DateTimes are parsed in the local timezone unless an optional timezone suffix is provided: 
    • 24 Mar 2016 21:33                             -> parsed in local timezone
    • 24 Mar 2016 21:33 -0500                   -> parsed in the timezone specified (and converted to the local timezone)

• en-US short date-time          (e.g. 3/24/2016 9:33:55 PM)
  • Milliseconds time component is not supported
  • Seconds time component is optional (e.g. 3/24/2016 9:33 PM)
  • 12-hour format time period suffix may be lower case (e.g. 3/24/2016 9:33 pm)
  • Supports 24-hour format (e.g. 3/24/2016 21:33)
  • Supports date-only (e.g. 3/24/2016)
  • All Dates and DateTimes are parsed in the local timezone
  • No timezone suffix is valid

The valid range for the years component for all formats is 0001 to 9999.

Parsing an invalid Date or DateTime will result in throwing an error through the SDK, or causing a runtime error to occur during rule execution.

Formatting a Date or DateTime will always output using the en-US short date or short date time format. This may be round-tripped by parsing the output, however since no timezone information will be formatted, the Date / DateTime must be assumed to be in the same local timezone.

Strings

InRule Strings are represented by JavaScript’s String data type.

JavaScript strings are Unicode as are .NET’s System.String, therefore they should be able to represent the same characters.

JavaScript string comparison behaves differently than .NET’s string comparison due to the limited and inconsistent Internationalization (i18n) functionality.

Most modern web browsers and node.js now include support for the ECMA-402 Internationalization API which exposes the Intl.Collator object.

Unfortunately not all web browsers support this object (Apple’s Safari browser does not support it at the time of writing) and those that do, do not support it consistently. Microsoft’s Internet Explorer and Edge browsers will produce different comparison results than Firefox and Chrome without adjusting the Collator’s options.

String comparisons involving less than or greater than operators in InRule syntax expressions are possible but not particularly useful (e.g. “Apple” < “Banana”). It becomes more useful when used with the Sort Collection action to sort a collection on a text Field to provide alphabetical sorting.

Due to the inconsistency in comparison functionality, Strings are compared using their ordinal Unicode value, as opposed to any culture/locale comparison rules.

Booleans

InRule Booleans are represented by JavaScript’s Boolean data type.

Boolean functionality should be identical to the .NET rule engine’s Booleans.