Page History
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. |
Such a workaround also worsens the characteristics of this pattern. |
Characteristics
| Include Page | ||||
|---|---|---|---|---|
|
Overview
Content Tools