‘Decisions’ includes a set of visual rule designers allowing rules to be configured in different formats. The different formats are to allow rules to be designed in the same way they would be drawn on a whiteboard or typed in an email.
The structure of rules is easily built and read and understood by the business and the technical people within an organization.
Rules can be used in a number of different ways. These include:
Rules take in data elements and produce a result. The data elements fed to a rule can be either simple values (like text or numbers) or complex data (like a policy, a medical record or person).
Rules evaluation can be one of the following types.
Rules are commonly thought to make decisions – True/False. However… rules can be built to return data values – either simple decisions (logical result) or any other data type or data value. For instance, a rule could return a percentage of a loan or validation issues after evaluating a data structure.
Rules can also be used to trigger actions. Actions (using the flow designer) can be triggered by either a true or false evaluation of a rule. For instance, when a rule evaluates a true, you could send an email or even write a value to a database. When combined with workflow.com – user interactions and assignments can be automated.
Rules need to be called by an application or a workflow in order to run. These applications will generally use the result of the rule as a guide to performing additional functionality. There are a number of different mechanisms where rules can be accessed by application functionality.
Any rule can be called using a SOAP or REST (XML or JSON) service interface. This can be done through a generic rule execution service or a specific service endpoint can be generated for each rule or rule set. Each rule has an integration page that shows all of the different service interface options and provides sample data structures and/or code for the integration.
Rules can also be triggered by configuring rules to be run as a result of a message across an infrastructure like RabbitMQ, MSMQ or IBM MQ Series. High performance or high throughput environments often benefit from a messaging infrastructure for guaranteed message deliveries with retries, load distribution, and work prioritization.
Rules can be run on a schedule – where data is looked up in a database, FTP server, email inbox, or another mechanism. This data can then be processed through a rule or a ruleset triggering actions or having results passed out to other systems or databases.
Large batches of data can be fed into a rule engine by flows. These flows can also handle the result of the rules execution. ‘Decisions’ has the management of both flat files (csv, excel) or structured files (json/XML) as well as stored data prebuilt.