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 shown.
| Input and Output parameters vs. Complex Model | | | Decision Management | Rule Engine |  | |
| Truth maintenance | | |
| Implicit vs. Explicit call | | This is an explicit call. The rule engine does not trigger the function. |
| User set vs. System set | | User-set values enter the profile, which are set from the returning message and the subsequent data mapping. |
Implementation properties | | Knowledge characteristics | Input and output parameters vs complex model | Parameters | Only simple input/output parameters could be used with Webservices (BaaS). |
| The input and output parameters are neatly defined in the contract of the web service. You are able to steer what values are set in the data mapping. If you want to fill in the parameters differently for different calls from the same module, an additional data mapping and AQ_WebServiceClient service call needs to be created. |
|
| | Explicit or implicit call | Explicit | Webservices are called explicitly. The rule engine does not call a webservice. |
| | User set vs. System set | User set | User-set values enter the profile, which are set from the returning message and the subsequent data mapping. |
| Maintainability characteristics |
Simple Parameters vs. Complex Instances | | These can be simple and complex, depending on the need. | Internal vs. External decoupled |
| External | This type of decoupling is only for external use. Even though both are Blueriq projects, the communication happens as if it is an external party. |
| | Automated vs. User Interaction |
| ? | This type of decoupling is only for automatic tasks. |
Complexity of the Decoupling pattern vs Gain | | | Implementation complexity |  |
| You get two additional modules in your project, and a second project next to it. As you are in control of the information being send, the structure will be similar to what you use in the application module. Therefore the mapping should be easy (1 to 1). You have to create your own contract for the communication, and keep this updated. |
| | Part of Application vs. Separate Deployment |
| Maintainability | | As the function is in a separate project, and can be maintained there on its own. There is no effect on the application module as long as the contract does not change. |
| Reusability | | |
| ? | The decoupled part is deployed separately. |
| Testability | | |
| Autonomy | | |
|
| | Internals invisible |  | Internals are not visible and/or accessible of a webservice. |
| | Testable | | Webservices are easily testable. |
| | Autonomous/decoupled | | A BaaS implementation could create coupling when a domain model for mapping is reused. |
| | Reusable | | A BaaS implementation is not very reusable because of a lack of parameter support. Hence, for every webservice call a mapping must be defined. |
| |
vs. Custom Code | No custom code required. |
