Tenant Boundary

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. 

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:

• Allowing you to line up the Transactions/Process Flows based on where they're coming from - a specific partner, a project, or the company itself.
• Managing the number of pods automatically based on the minimum and maximum number defined while creating a Deployment.
• Allowing you to allocate the memory and CPU to be used by a pod.

The following example illustrates a dedicated and a shared (default) runtime service (deployment) as well.

As the figure depicts:

• The data of Tenant 1 are getting routed via a dedicated queue "Tenant1 Queue" to the dedicated runtime service "Runtime Deployment (Tenant 1)".
• The data of other tenants are getting routed via a shared queue "Shared Queue" to the shared runtime service "Runtime Deployment (Shared)". 

The following sections guide you on:

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, 

• Create a dedicated Queue
• Create a dedicated Deployment 
• Subscribe the Deployment to the Queue 

Scaling the Deployments 

Once a Deployment is created, the number of runtime pods within that scale up and down based on how you have configured the relevant parameters in the global values.yaml file. For more information on the parameters and their configuration, refer to the page Configuring Horizontal Pod Autoscaling.

Assigning resources to a pod in a Deployment

While creating a Deployment, you can allocate minimum and maximum CPU cores and memory that a pod can use. To do this, you need to provide the values for the fields mentioned in the table below.

A runtime pod is allowed to use more of the resources than specified in the CPU Request, and Memory Request fields. However, it cannot use more than what is specified in the CPU Limit, and Memory Limit fields.

For example, if you set a memory request to 3072Mi, and the available memory is 6144Mi, the pod can try to use more memory. Nevertheless, if you have set a memory limit to 5120Mi, the system will prevent the pod from using more memory than defined in the resource limit.

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. 

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.