This pattern uses External rule to call a web service that is defined in another project. The great thing of this pattern is that it is triggered by the rule engine and not the flow.
Business rules should be implemented in Blueriq and not in code. Exceptions could be made because of performance reasons to implement business rules in code. Initially all business rules are implemented in Blueriq. Code is usually used for integration purposes.
Characteristics
In the table below the implementation charateristics by using an External Rule.
| Type | Score | Description | |
|---|---|---|---|
| Knowledge characteristics | User set or System set | System | An external rule is part of the truth maintenance mechanism and any result is system-set. |
| Parameters or complex model | Complex Model | On the external rule parameters can be defined which trigger the truth maintenance. In code you however access to the complete profile, and can use any attribute during the calculation. Although it is best practice only to use the truth maintenance parameters, we classify this as complex model. | |
| Enhanced by Blueriq Functionality |
/
| External rules are part of truth maintenance mechanism. However, there are dependencies for the truth maintenance parameters, but there is no way of knowing what happens in the external rule or what attributes are actually needed. In these cases it is not possible to rely on truth maintenace mechanism. | |
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Focus on Internal or External Use | Internal | External rules are only used by Blueriq. |
| Low Implementation complexity |  | There is a simple hook, and the code that needs to be written is simple. The difficulty lies with keeping the code in line with the model, as the external rule reads attribute values in a hard coded manner. | |
| Internals invisible (encapsulation) |
/ | The internal code is not visible from the model. From the code however, you can view the entire model. | |
| Autonomous | | As the complete profile can be input to the external rule, changes in it may lead to side effects during the execution of the external rule. In addition, code and models are highly coupled so it is difficult to test the model autonomously. There is always a strong dependency with code. | |
| Highly Testable | | Unit tests can be written in code. the difficulty lies in the hard link to the defined model. When the model changes, the code might break as it is hard-coded what attributes are needed. | |
| Highly Reusable | | Once you have the external rule defined, then you can distribute the definition in a library and use it simply on any desired attribute.The domain needs however be very similar, as the code reads the values of certain attributes in a hard coded manner. When different attributes are needed for another application, then the code needs to be changed. | |
| Out of the Box | | An external rule requires writing of code. | |
Deployment characteristics | Part of Application or Separate Deployment (=deployment) | Part of Application | The code has its own life-cycle and is deployed separately. It is however strongly coupled with the domain of an application. This leads to the code moslty only be used by one application. Therefore, we regard it as part of the corresponding application. |
Overview
Content Tools