After we have a rule and it has been tested, unit tested, and is being managed and versioned – there are 4 primary ways in which a rule can be used:   

1. Called from an API
2. Used within a Workflow
3. To Trigger an Action
4. Used in a Monitoring Context

Business Rules and API

If there is an existing application that needs to be made more flexible and configurable, the Decisions no-code platform offers a simple set of API’s that allow rules to be called and consumed within an existing or custom application. These rules could even be consumed by legacy workflow systems like BizTalk or Pega.

The API’s offered by The Decisions Platform are

• REST (both JSON and XML)
• Simple HTTP Post/Get
• WCF
• Webservices

To integrate, there is an action on the rule that describes the service calls and how to configure them.

Web service details from another example:

Business Rules Consumed in a Workflow

Rules are also useful to separate out logic from within a workflow. While a workflow has the ability to run rules by configuration of paths, separating out into specific and discreet rules allows a break between ‘what is being done’ and ‘decisions that are made within that context’. Another benefit is rules are often more targeted to spots that the business logic owners are happy to work with.
To integrate a rule into a flow, simply find the rule and drag it into the flow, hook it the the right spot of the flow and configure its inputs. 

And the easy to use mapping editor to help define relationships.

Triggering an Action with Business Rules

While consuming rules output within an external application or workflow makes sense, often rules might be expected to ‘trigger an action’.

This is a pattern that most people typically think of when they think of rules.

if [conditions] do [action]

Decisions supports this pattern both on a rule evaluating true or false.

The power of the workflow engine makes this really interesting. Rather than picking from a small list of granular actions (run command line, call service, send email, etc) the full power of the workflow engine including all of the integration capabilities can be used to form up new ‘actions’ to be used as results of rules.

Given the fact that the actions are ‘linked’ to the rule, they can also be configured to be reusable. So, if the action you want to take is as simple as calling a service or as complex as starting an approval or fulfillment workflow these are easily done as actions resulting from rules.

Business Rules Engine Used in Monitoring an External System or Listening for Events

Rules also can be used interestingly integrated into the event mechanism of the platform. Rules can decide what events are interesting and which events should be ignored.

Events can be scheduled to a time period and configured as to what is being listened to. Using the rule engine to figure out what events are interesting and where to send them allows a very flexible and high performance filtering and routing.

Okay, more than 4…

The above list represents obvious ways to consume rules, but here are some more:

Routing to figure out what workflows to run

Providing data validation on an object

Deciding on data mapping between two systems

Calculations

Providing form validation

Integrated with security do decide access rights

…. and much more…