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:
- Called from an API
- Used within a Workflow
- To Trigger an Action
- 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.
