In this pattern a custom service is used as a function. It receives the complete profile as input data, and places new information in the profile as a result. Based on this new information, a split node can decide how to continue.
Characteristics
| Type | Score | Description | |
|---|---|---|---|
| Knowledge characteristics | User set or System set | User set | Any value set in code becomes user set, and is not overwritten by the rule engine. |
| Parameters or complex model | Complex model | The custom service has the complete profile available as input. There can be well defined output variables as service parameters. | |
| Enhanced by Blueriq Functionality |  | There is a dependency to the custom service call and model validations on its parameters. There is no support on any business knowledge that is hard coded in the service. As important decisions are done in the Blueriq flow, more decision support can be given compared to Decoupling Pattern 4: Custom decision service.
| |
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Focus on Internal or External Use | Internal | The custom code is only called by Blueriq |
| Low Implementation complexity | | You get a new service call which you can simply place in your flow. | |
| Internals invisible (encapsulation) | | Internals are not visible and/or accessible from Studio. All Studio internals are however fully visible from code. | |
| Autonomous | | The business rules are executed separately, but side-effects are possible as there are no clear output parameters. In code you could theoretically change all profile values, but a best-practice is that only well defined output parameters are changed. Even with this best practice, the score is low as there is no support from the platform for adhering to it. Therefore, an unwanted coupling between code and model becomes likely. | |
| 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 | | Custom code required. | |
Deployment characteristics | Part of Application or Separate Deployment (=deployment) | Part of application | The code is packed and published together with the model in practice. |
Overview
Content Tools