Examples

Rule authors often have a need to work with data that is not available in a rule applications entity structure. For example:

• An airline might want to run a promotion that the first 500 frequent flyers that buy tickets for travel in June will be entered in a drawing for a free trip to Hawaii.
• When a frequent flyer purchases a ticket the rule engine will need to evaluate if the person is a frequent flyer and if the flight is in June before going to a database to see if any of the 500 spots are still available.
• If the flyer does meet the criteria and the lookup reveals that there are still drawing spots available, then the database should be updated so that the customer is added to the drawing list.

This is a fairly simple example but it becomes clear there is often a need to combine frequently changing business logic with database access. The purpose of this article is to expose you to some of the various ways that can be accomplished in irAuthor with actual examples and references to the relevant help-file articles.

About Accessing Data

InRule allows you to access data in a variety of ways over-and-above what’s available simply by passing data into the rule engine from a calling application. This functionality was specifically designed to let you:

• Access database data conditionally based on rules for use in calculations or other rules
• Load data into entities and collections
• Control data in the same place you author rules within a spreadsheet-like grid
• Add, delete or update data directly from rules

Like much of the functionality in irAuthor, the data access functionality is intended to be setup by technical users and integrated into rules by business analysts.

It should be noted that InRule does an excellent job of storing table information for codes, IDs, or other information commonly tied to business logic. Because inline tables and value lists are stored, managed, and version enabled in InRule, users have less of a need to interact with database administrators to create tables, change columns, or version data against effective dates. This is especially apparent in larger organizations.

The following sections cover in detail some of the scenarios in which users would access data.

• Getting Data Using a Table Lookup
• Getting Data Using a SQL Query
• Using A List of Valid Values in Rules and Field Validations
• Working With Data Through a Web Service
• Working With Data Through a .NET Method

xx