In Adeptia Connect, the runtime microservice processes the data coming from multiple channels, called Tenants. This data is processed by executing Transactions/Process Flows on runtime service. You may need to regulate and isolate the execution of these Transactions/Process Flows to avoid any performance impact of one Tenant on another. An effective solution to this is to have a logical boundary around these Tenants, called Tenant Boundary.
A Tenant can be a Partner(s), Project(s), or the Company itself whose Transactions/Process Flows are executed by the runtime. You can set up a logical boundary between the executions of Transactions/Process Flows of two Tenants by providing them their own dedicated runtime service (deployment). This helps you isolate performance impact and meet SLA compliance requirements. Such a logical boundary between the two dedicated runtime services is referred to as Tenant boundary in Adeptia Connect.
| Info |
|---|
| The dedicated runtime service for a Tenant can be autoscaled and sized as per need. |
The illustration below gives you an idea how the Tenant Boundary is used to manage the executions of three types of Tenant's Transactions/Process Flows.
Tenant Boundary regulates, manages, and expedites the execution by:
...
The following example illustrates a dedicated and a shared (default) runtime service (deployment) as well.
As the figure depicts:
...
| Anchor | ||||
|---|---|---|---|---|
|
The following sections guide you on:
Table of Contents
Setting up a Tenant Boundary
Typically, the data to be processed by Transactions and Process Flows first go into the queue from where the runtime, based on its concurrency level, takes them up for processing. By default, in Adeptia Connect, the data from all the Tenants go via a shared queue to the shared (default) runtime service for processing. However, you can choose to pass the data of a specific Tenant via a dedicated queue and execute them on a dedicated runtime service (Deployment) associated with the Queue – This helps you address the need for segregating the processing of data based on their origin (Tenant). As you create a dedicated deployment and subscribe it to a dedicated queue, you happen to set up a Tenant Boundary in the application.
To summarize the steps for setting up a Tenant Boundary,
Scaling the Deployments
...
Field | Description |
|---|---|
CPU Request | The minimum CPU cores you want to allocate to a pod in the deployment. |
CPU Limit | The maximum CPU cores a pod in the deployment can use. |
Memory Request | The minimum memory you want to allocate to a pod in the deployment. |
Memory Limit | The maximum memory a pod in the deployment can use. |
Migrating the Deployments
While migrating objects from one environment to another, you may also want to migrate the dedicated Deployments that you may have created. Based on your requirement, select Service Type as Deployment for any of the two export criteria – Service Type, and Individual Activities – on the Select Activities page of Solution Promotion wizard. For more information, refer to the page Creating Export XML.
| Warning | ||
|---|---|---|
| ||
|
Turning a Deployment on or off
A Deployment can process the messages of a Queue only when the deployment is active. You can turn a Deployment on or off by following the instructions given on this page.