This pattern uses the AQ_StartProject service 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. The result of the flow has to be retrieved to the profile using some other service. A solution for this could be by loading it with an AQ_Aggregate_Read service. As the execution is in parallel, you can not be sure that the information is already up-to-date. A custom service which waits for the updated information is likely more suitable. It is therefore an appropriate decoupling pattern if no output is needed from the other flow (fire & forget).
Characteristics
| Type | Score | Description | |
|---|---|---|---|
| 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 | The information entering the profile is user set if an AQ_Aggregate_Read service is used, but can be system set with a custom service. | ||
| Implementation properties | Input and Output parameters vs. Complex Model | The input parameters are set on the AQ_StartProject. What key-value pairs are needed for the successful execution should be documented in the function project. Your model stays clean of any internals of the function. | |
| Simple Parameters vs. Complex Instances | The input are simple key-value pairs. Output can be complex. | ||
| Internal vs. External | This type of decoupling is only for internal use. | ||
| Automated vs. User Interaction | This type of decoupling is only for automatic tasks. | ||
| Complexity of the Decoupling pattern vs Gain | The output parameters are loaded by the AQ_Aggregate_Read or a custom service. This means that you can only see how an attribute receives its value by checking if it is included in an aggregate, and that aggregate is loaded within a flow. You can not see this in the model if custom code is used. | ||
| Part of Application vs. Separate Deployment | The decoupled part is deployed separately. | ||
| Testability | |||
| Autonomy | |||
| Maintainability | This pattern does not clutter your domain with unnecessary attributes, which is an advantage. It is fairly clear to the business engineer what the service exactly does. A disadvantage is that the loading of output information is difficult, and a Decision Requirements Graph (DRG) in Studio can not be used. | ||
| Reusability | |||
| Out-of-the-box vs. Custom Code | The AQ_StartProject is standard functionality, as well as the AQ_Aggregate_Read service. A custom service that waits for the started flow to end is a custom service. |
Overview
Content Tools