Versions Compared

Old Version 4

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

Saved on

compared with

New Version Current

changes.mady.by.user Tijmen Daatselaar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrate text box

This pattern uses the Service call type: AQ_StartProject service in  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.

Image Removed

Image Removed

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.

Note

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.

Image Added

Image Added

Characteristics

Include Page
BKB:Decoupling Pattern 7: AQ_StartProject service Score [Internal]
BKB:Decoupling Pattern 7: AQ_StartProject service Score [Internal]

Characteristics

 TypeScoreDescriptionDecision 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.