This pattern uses the Service call type: AQ_StartProject in 'Start without user interface' mode to call a flow in a project that can be located in a completely different repository. The call of the flow is straightforward, whereas receiving the answer is more difficult. The AQ_StartProject service does not set any output itself, as it just starts a function in a different repository. It is therefore an appropriate decoupling pattern if no output is needed from the other flow.
Although no output is given, the application module which calls the AQ_StartProject service still has to wait until the flow inside the AQ_StartProject is finished before it continues. Keep this in mind when using this pattern: for example when modelling a BAAS which has to respond in a certain time, the handling time of the called AQ_StartProjectFlow also counts towards the total.
It is not adviced to use this pattern when an answer is needed. Solutions such as the Service call type: AQ_Aggregate_Read are difficult to make resilient. One problem is that the execution is in parallel, you can not be sure that the information is already up-to-date. Such a workaround also worsens the characteristics of this pattern.
Characteristics
| Type | Score | Description | |
|---|---|---|---|
| Knowledge characteristics | User set or System set | - | This pattern has no output |
| Parameters or complex model | Parameters | The parameters of the service are well defined. | |
| Enhanced by Blueriq Functionality |  | Dependencies to the service are possible, and support is given for the shortcut definitions. | |
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 external flow is only used by Blueriq. |
| Low Implementation complexity | | Defining the flow and using the parameters is simple. Managing the shortcuts is a bit trickier. For making that part easier, see dynamic shortcuts. | |
| Internals invisible (encapsulation) | | From the calling party all internals are not visible. | |
| Autonomous | | The external function has its own profile and can only use the defined parameters. | |
| Highly Testable | | As it is a separate flow and only relies on several simple parameters, it can be tested autonomously. | |
| Highly Reusable | | Any application can use the defined shortcut and the service definition to call the functionality. | |
| Out of the Box | | No custom code required. | |
Deployment characteristics | Part of Application or Separate Deployment (=deployment) | Both | It is your choice whether the external function is part of the same repository, or has its own repository. |
Overview
Content Tools