Managing the reference data required by a decision is a common challenge for most rule applications. And depending upon your requirements, you have several options for storing that data, such as SQL Endpoints, cloud-based databases, and external service options. But there are a few powerful use cases for storing your reference data in inline tables, where the rule application itself hosts your reference data.
- Stubbing Reference Data: In the early days of a project, you can’t always find a DBA to create your database tables and import data. This holds everyone back. If the data is not too large, using inline tables for a short period keeps the team going until you can refactor it for an external database. Static reference data doesn’t need to be in an external database – especially if it’s reasonably sized and doesn’t change but once a year or more. Moreover, in the heat of early project work, its much faster to just create this data locally and move on—even if you have a DBA working with the team. While the team architect may cringe at the duplication of data, just repeat the mantra, a working system is more valuable than not. Don’t optimize early. In the end, you might just leave the inline tables as you move into production.
- Avoiding Dependencies: If you share rule applications (internal and external to your organization), then you must also share the dependencies. Dependencies kill portability. If you have a dependency on an external database, then every rule author and execution environment must have access. This adds weight to the lifecycle and must be offset by the advantage of the external dependency (access and reuse by other applications).
- Using JavaScript: JavaScript is perhaps the most portable language on the planet. InRule for JavaScript supports inline tables, opening the door to more robust serialized assets that can run just about anywhere with excellent performance.
Using inline tables is surprisingly easy. I imported an XLS file from FannieMae describing loan limits for properties from 1-4 units:
I then created a query and the parameters to drive the lookup criteria for city and state:
Finally, I set values in my entity schema for safekeeping until the rule set is ready to enforce the limit:
While the use cases I provide are valid, all reference data should be reviewed from a lifecycle perspective as you move toward production. Because inline tables are so useful, they have their place in the pantheon of patterns and practices. How are you using inline tables today? We would love to hear your stories. Feel free to share your thoughts below or post in the support forum.
