Page History
This pattern uses External rules 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.
Characteristics
Implementation
This pattern should be implemented by using a Function within Blueriq. How to use a Function within Blueriq is described in MyBlueriq.
In the table below the implementation charateristics by using a Function is shownan External Rule.
| Type | Score | Description | ||||
|---|---|---|---|---|---|---|
| Knowledge characteristics | Implicit or Explicit call | Implicit call | This is an implicit call that is triggered by the rule engine each time when an input value changes. | |||
| User set or System set | System set | System set. | ||||
| Parameters or complex model | Parameters | Parameters. The complete profile can be used as input, but the Action attributes of the External rules are most likely to be the input parameters. | ||||
| Maintainability characteristics | Internal or External decoupled | Internal | User set vs. System set |  | The values that are set by an external rule are system set. | |
| Automated or User Interaction | ? | |||||
| Implementation complexity |  | An external rule is easy to implement but it alignment with model and code is necessary. | ||||
| Part of Application vs. Separate Deployment | | The decoupled function is partly in the model, and partly in code. You should make sure that the code is deployed together with the project. | ||||
| Internals invisible |  | Internals are visible. | ||||
| Testable | | Hard to test because of strong coupling with code (external rule implementation) and model. | ||||
| Autonomous/decoupled | | Input and Output parameters vs. Complex model | | Implementation of an external rule is seperated from the calling application. However, the implementation (code) of an external rule will create unwanted coupling because it has direct access to the domain model. | The implementation of an external rule has access to the complete profile. It is therefore important to document what values are needed by the external rule. You can set what values should trigger the external rule mechanism. Most likely are those identical to the input values. An external rule can be used as default on an attribute, but in general it could change the value of any attribute. There are no additional attributes required in your domain, keeping it clean. Autonomous/decoupled | |
| Implementation of an external rule is seperated from the calling application. | |||||
| Simple Parameters vs. Complex Instances | Single | The complete profile can be used as input, but the Action attributes of the External rules are most likely to be the input parameters. | ||||
| Internal vs. External | Internal | This type of decoupling is mainly for internal and external use. As the function is in a web service, any party could call it. | ||||
| Maintainability | | This pattern does not clutter your domain with unnecessary attributes, which is an advantage. A disadvantage is that it is not clear to the business engineer what the external rule exactly does. That is all hidden away in the service. For example, you can not use the dependency function in studio to find which external rule might change its value if it is not placed as default value on the attribute. | ||||
| Reusable | | |||||
| Part of Application vs. Separate Deployment | | The decoupled function is partly in the model, and partly in code. You should make sure that the code is deployed together with the project. | ||||
| Reusable | | Because of a strong coupling with code and model it is hard to reuse an external rule. | ||||
| Out of the | Out-of-the- box | | A new external rule that calls a specific web service has to be created by a developer. |
Overview
Content Tools