Decoupling Pattern 7: AQ_StartProject service

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

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

	Type	Score	Description
Knowledge characteristics	User set or System set	-	This pattern has no output
	Parameters or complex model	Parameters	The parameters of the service are well defined.
	Enhanced by Blueriq Functionality		Dependencies to the service are possible, and support is given for the shortcut definitions.
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality.	Focus on Internal or External Use	Internal	The external flow is only used by Blueriq.
	Low Implementation complexity		Defining the flow and using the parameters is simple. Managing the shortcuts is a bit trickier. For making that part easier, see dynamic shortcuts.
	Internals invisible (encapsulation)		From the calling party all internals are not visible.
	Autonomous		The external function has its own profile and can only use the defined parameters.
	Highly Testable		As it is a separate flow and only relies on several simple parameters, it can be tested autonomously.
	Highly Reusable		Any application can use the defined shortcut and the service definition to call the functionality.
	Out of the Box		No custom code required.
Deployment characteristics	Part of Application or Separate Deployment (=deployment)	Both	It is your choice whether the external function is part of the same repository, or has its own repository.