This container will replace the AQ_Dashboard_FlowWidget and AQ_Dashboard_ProjectWidget.
See also external flow [editor] for detailed information.
Architecture
The architecture of the EFC looks like the following:
Elements
To be able to use this functionality a new container type is to be used: the AQ_ExternalFlow and a new type of flow , see External Flow Type
Also the concept of a contract is needed: see Contract module.
Considerations
This new functionality is great, but it should be used as intended. Here some pros and pitfalls are stated to keep in mind when choosing this functionality.
Pros
The pros of this functionality are:
- It is possible to split up large applications into some smaller, autonomous parts.
- This autonomous way causes deploying only sub-parts.
- Additionally this can make release cycles short
- The target host (where a part of the application is running) can be scaled as needed.
Cons
There are however also some pitfalls which you should avoid.
- This construction should not be used as a purpose on its own. Don't use this for neatness reasons for example. This way has an impact on feedback to the user (network communication).
- There is a chance of circular reasoning. It is possible to use this functionality in a way that the target host is also calling the source host. This should be prevented in any way.
- There is a possibility that sessions will break. You are using different runtimes which are called at another point in time. So you should be aware that this may happen.
- This mechanism uses a contract with data mappings. This is OK, but it brings extra complexity in the application (it is also not part of the business domain). Keep this in mind.
Limitations
- Running the external flow using host and target runtimes with different major and minor versions is not supported.
Configuration
For configuring this functionality see External Flow.
Overview
Content Tools