The Boomi Flow runtime is the globally-distributed platform infrastructure that runs your apps. The Flow runtime now supports multiple regions. This means, requests to the runtime API endpoints on the platform will now be routed towards the region closest to you geographically.
With multi-region support, you can expect to see a marked decrease in latency when running flows. Flow will be literally closer to you!
You will also have more granular control over how and where your runtime data is processed and stored. For example, you can add a restriction to your flow that let’s it be accessed from only a particular city.
Currently, the runtime has instances in the following regions:
- AU: Australia (Sydney, AU)
- GB: Europe (London, GB)
- US: North America (Virginia, US)
Runtime data is automatically and asynchronously replicated across these regions.
Combining a multi-region runtime with an External Storage API implementation gives you complete control over where your runtime data is transmitted, stored and accessed; thus giving you even better compliance and data residency support.
A multi-region runtime also enables performance improvements, especially if you are running services that are local to a region.
Runtime data is data that is generated and used when flows are executed inside the platform. Anything stored inside values, entered into pages, or any information collected as part of a running flow is defined as “runtime data”.
With a multi-region platform, all the data we store is replicated globally, to all regions, in order to simplify operations and increase performance for most customers. This includes all build-time data (flow and element metadata), and any runtime data stored by Flow.
The Flow platform also supports storage of data in an external location, through the External Storage API. You can link your tenant to a storage location of your choice, yes, even on-prem, to store your runtime data.
Once an external store is configured, the Flow platform does not store the things that are selected for the store to handle, and only when replication is disabled. If you enable states on a store, and disable replication, the Flow platform will still store every other part of runtime data, just not states.
If you are wondering what parts of the Flow platform are handled by regional instances, any API call that falls under the following endpoints will be executed in the closest region to your request:
- Run API
All requests to any other API endpoints will be routed to the US instance, via your local region.
Flow end-users will be routed to their nearest instance, determined first by country, and then by continent. If an user’s broad location cannot be determined, she will be routed to the US instance.
- If a user accesses a flow from UK, her request will be routed to the GB instance.
- If a user accesses a flow from France, her request will be routed to the GB instance.
- If a user accesses a flow from New Zealand, her request will be routed to the AU instance.
- If a user accesses a flow from South America, her request will be routed to the US instance.
- If a user accesses the Flow drawing tool, the Draw API, or any Flow API endpoint that is not covered (see the previous section on API coverage), the request will be routed to the US instance.
You can determine the regional instance you are using, by checking the response headers to any API call. Values will be given for
X-ManyWho-Region-Backend (the Flow Engine instance) and
X-ManyWho-Region-Frontend (the load balancer).
You can add restrictions to the apps you build with Flow, which allow you to limit both where apps are executed, and where they are accessed from.
Access restrictions are used to limit access to an app from users in specific countries or continents. For example, you may want to limit a smart-gov app for the Sultanate of Kinakuta to its residents only.
Execution restrictions are used to limit which Flow Engine instances are able to process your flows and state data. They can be useful if, for example, you wish to restrict transmission of your state data to a limited number of locations. Execution restrictions aren’t much use unless they are paired with an external store, as data stored by the platform is already in all regions!
For example, say, a government agency located in Italy is using a Flow app to process sensitive citizen data, linked with an external storage endpoint, and wishes their state data to never be transmitted outside of Europe. They would add an execution restriction for the EU continent; which would limit data transmission to instances located in Europe only (which currently would be only the GB instance). Trying to access the app via any other instance would display an error to the end-user.
Execution restrictions restrict the platform instances that can load and process a state, and not the locations where an end-user can access the app. A user from India can still access the app even though she is not in Italy; she would also be using an instance in Europe, however the state data would stay within the continent, on the instance itself – only the runtime metadata would be transmitted to the user in India.