Page History
This pattern uses a web service to communicate with a project that is located somewhere else. This can be a SOAP or a REST web service. These two projects are completely separate and can be deployed separately.
Characteristics
| Type | Description |
|---|---|
| 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. |
| Input and Output parameters vs. Complex Model | 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. |
| Simple Parameters vs. Complex Instances | These can be simple and complex, depending on the need. |
| Internal vs. 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 | 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. |
| Out-of-the-box vs. Custom Code | No custom code required. |
| Part of Application vs. Separate Deployment | The decoupled part is deployed separately. |
| 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. |
Overview
Content Tools