Versions Compared

Old Version 5

changes.mady.by.user Unknown User (b.de.veer)

Saved on

compared with

New Version 6

changes.mady.by.user Unknown User (m.schadd)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

 TypeScoreDescription
Decision ManagementRule 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.