can be deployed on physical hardware, or in Virtual Machines.
Virtual Machines can be located either on-premises in a VM cluster (such as VMWare vSphere), or leveraging Virtual Machines hosted by public cloud providers (for example AWS EC2, GCP GCE, Azure VM)
The modular architecture enables cost-efficient mediation solutions.
Test system
One server maintains the execution of all zones – this represents a local server on which the mediation processes are configured and validated, for later export to production servers.
Single production server
Multiple access zone clients access a single server (or cluster) that manages the execution of control zone as well as execution zone logic.
Multiple production servers
Multiple access zone clients access a single server (or cluster) that manages the control zone. Workflows are distributed to any number of execution zone servers based on data volumes and specific deployment requirements.
New functionality, customizations and business processes can be dynamically implemented, and there is no downtime on an executing system when the changes are made.
In the case of patches or enhancements to the executable, the changes are introduced to the code server that will automatically propagate the change to all parts of an installation (i.e. clients, Execution Contexts etc.).
In the case of changes to the business processes, the changes can be made on a running workflow and will not lead to any downtime of the processing, it will become active the next time the workflow is started.
To ease the rollout of new configurations, multiple configuration spaces can be used in production to keep the running configurations separated from configurations that are being staged for production. This means that production servers can be updated with new configurations while the running configurations stay unchanged.
When the new configuration is ready to be taken into production, only a minimal downtime will be needed even for extensive changes.
Configuration spaces can also be used for handling backups, to enable rollback of old configurations.
Workflow Mapping to Execution Contexts
Workflows can be mapped to Execution Contexts in several ways. The distribution can be up to the Platform to decide, in which case it can be configured to base it on load or number of workflows already running. A workflow - or a configured group of workflows - can be pre set to execute on particular Execution Contexts. Also, there is the possibility to map one or several Workflow Templates, including how many of each Template's instances that shall be started on a ECs with a particular name pattern. This way, the cluster can be easily scaled up and down. Please see section Execution Elasticity for more information.