The Boomi Flow runtime is the globally-distributed platform that runs your flows. Any requests to the one of the runtime API endpoints on the platform will now be routed towards one of our regions - normally your closest one geographically.
Currently, the runtime has instances in the following regions:
- AU: Australia (Sydney, AU)
- GB: Europe (London, GB)
- US: North America (Virginia, US)
The list of regions may be extended in the future, if there is sufficient demand.
Note: There are no independent regional platforms. Any data stored by one region is stored by all the others too!
Multi-region support was added to the platform in order to give customers better control over how and where their runtime data is processed and stored. Combining the multi-region runtime with an External Storage API implementation will give customers complete control over where their runtime data (states) are transmitted, stored and accessed, allowing greater compliance and data residency support.
It also enables potential performance improvements for customers running services that are local to a region. Most customers should see a decrease in latency when running flows, as they will now be using an instance closer to their location.
Runtime data is the data that is generated and used when flows are executed inside the platform. Most of that data is contained in the state, and a small part is inside a running user's authentication token. Anything stored inside values, entered into pages, or any information collected as part of a running flow is defined as "runtime data".
An integral part of the multi-region platform is the fact that 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 we store.
The platform does support storage of data in an external location, through a feature called the External Storage API. Using this, customers can link their tenant to a storage location they control, and use it to store their sensitive runtime data. After configuring an external store in a tenant, from that point forward, absolutely no runtime data is permanently stored by the Boomi Flow platform - only build-time data is stored and replicated globally.
If you're wondering what parts of the 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
/api/file/api/run/api/social/api/service/1/data/api/service/1/file
All requests to any other API endpoints will be routed to the US instance, via your local region.
Runtime users will be routed to their nearest instance, determined first by country, then by continent, and if the user's broad location cannot be determined, they will be routed to the US instance.
- If a user is located in the UK and accesses a flow, their request will be routed to the GB instance
- If a user is located in France and accesses a flow, their request will be routed to the GB instance
- If a user is located in New Zealand and accesses a flow, their request will be routed to the AU instance
- If a user is located in South America and accesses a flow, their request will be routed to the US instance
- If a user in any location accesses the Draw API (or any API that isn't covered), their request will be routed to the US instance
Note: 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 Engine instance) andX-ManyWho-Region-Frontend(the load balancer).
You are now able to add restrictions to your flows, which allow you to limit both where flows are executed, and where they are accessed from.
Access restrictions are used to limit access to a flow from users in specific countries or continents. They would be useful in the case that a flow should not be able to be used at all from certain locations.
A survey for cyclists in Swaziland needs to be only accessible by users in that country, and no others.
An access restriction for the country SZ would need to be added, limiting access to that country only. Any users in other locations would be displayed an error.
Execution restrictions are used to limit which 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!
A government agency located in Italy is using a flow 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 only instances located in Europe (which currently would be only the GB instance). Trying to access the flow via any other instance would display an error to the user.
Note: This only restricts the platform instances that can load and process a state, and not the locations where a user can access the flow. In this example, a user from India can still access the flow, as they would also be using an instance in Europe, but the state data would stay within the continent, on the instance itself - only the runtime metadata would be transmitted to the user in India.
If you're having problems accessing flows, or you feel the platform has gotten slower since multi-region support was added, please contact us at support@manywho.com with your location and tenant ID/name and we'll help you figure out the problem.