Versions Compared

Old Version 3

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

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

A custom service which waits for the updated information is likely more suitable

Such a workaround also worsens the characteristics of this pattern.

Characteristics

TypeDescriptionImplicit vs. Explicit callThis 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.

Input and Output parameters vs. Complex ModelThe 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 InstancesThe input are simple key-value pairs. Output can be complex.Internal vs. ExternalThis type of decoupling is only for internal use.Automated vs. User InteractionThis type of decoupling is only for automatic tasks.Complexity of the Decoupling pattern vs GainThe 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.Out-of-the-box vs. Custom CodeThe 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.Part of Application vs. Separate DeploymentThe decoupled part is deployed separately.MaintainabilityThis 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.

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