search string side menu

BRIX On-Premises > Administering BRIX Enterprise / Dedicated worker pools for script processing

Dedicated worker pools for script processing

In BRIX, the worker service is responsible for the validation, compilation, and execution of server scripts. To improve its performance, you can allocate dedicated execution pools:  

  • For system structures where scripts are initiated. For example, for widget scripts or a specific business process.
  • For specific types of script processing requests. For example, for their compilation or execution.  

начало внимание

The configuration of dedicated worker pools is available for BRIX On‑Premises Enterprise starting from version 2025.6.  

конец внимание

This article describes how the system:  

Script processing algorithm in the worker service

The following tools are used to distribute the load on the worker service:  

  • Kubernetes. Ensures the scaling of service replicas where scripts are executed.
  • RabbitMQ. Acts as a router, distributing script execution requests among available worker replicas.  

With the default worker configuration, script processing requests are sent to RabbitMQ and distributed within a shared queue. This increases the load on the service and slows down script execution.  

Configuring dedicated pools for specific types of scripts helps optimize this load distribution. After such configuration:  

  • In Kubernetes, data is transmitted to deploy the pools.  
  • In RabbitMQ, a separate queue is automatically added for each configured pool.  

Let’s take a closer look at how script request routing works:  

  1. Routing key determination.
     
    When a script is launched, a request containing its parameters is automatically generated: company name, script compilation or execution, the system structure from which the script was initiated, etc. Based on this data, a routing key is determined:  
  1. Request distribution.
     
    Requests with assigned keys are sent to RabbitMQ, where they are routed:  
  • If you have specified dedicated worker pools for certain scripts, RabbitMQ automatically creates queues for these pools. Requests are distributed to these queues based on the assigned key.
  • Requests with the default key are placed in the shared script.default queue.
  1. Request processing.
     
    Requests are distributed from the queues to worker replicas:  
  • From dedicated queues, script processing requests are sent to the configured worker pools.
  • From the script.default queue, requests are distributed among shared worker replicas.  

Configure worker pools

The configuration of worker pools consists of two steps:  

  1. Define the worker pool configuration.  
  2. Apply the configured settings.  

Step 1: Define the worker pool configuration

To create a dedicated worker pool for specific scripts, specify its configuration in the values-elma365.yaml file. Define the script selection criteria, autoscaling parameters for pool replicas, and script execution timeout settings.  

To do this:  

  1. Create a backup of the values-elma365.yaml file filled during BRIX installation. This is necessary before editing, as incorrect parameter settings may cause BRIX application failures.  
  2. In the values-elma365.yaml configuration file, go to the global block and fill in the parameters in the workerPoolCfg section.  

начало примечание

Example of parameter configuration in the workerPoolCfg section

global:
  workerPoolCfg:
    pools:
      namespacepool: # The pool name is specified in free form using lowercase Latin letters and numbers, up to 20 characters long
        sources: # Filters for selecting scripts to be distributed to the pool
        - company: head
          operation: execute
          type: process
          namespace: crm
          code: createlead
        autoscaling: # Autoscaling parameters for the pool
          enabled: true
          type: "hpa"
          minReplicas: 1
          maxReplicas: 9
        options: # Additional pool options — timeouts
          defaultScriptTimeoutSeconds: 180
          maxScriptTimeoutSeconds: 1200

конец примечание

For this, specify:  

  1. Pool identifier (pools). The name of the worker pool. Assign a custom name to the pool using lowercase Latin letters and numbers, up to 20 characters long.  
  2. Sources of script processing requests (sources).
     
    When a script is launched in the system, a request for its processing is automatically generated. This request includes the script parameters. Specify which parameters to use for selecting scripts for the configured pool:  
  • сompany. The company name in the cluster.  
  • operation. The request type: script compilation or execution. Add one of the available values: сompile or execute. For example, to process only script compilation, specify the configuration:  

workerPoolCfg:
  pools:
    publishpool:
      sources:
      - operation: compile

  • type. The system structure from which the script processing request was initiated. Specify one of the available values:  
    • process. Business process.  
    • customactivity. Business process action in the module.  
    • widget. Widget.  
    • eventhandler. Event handler.  
    • apihandler. API method handler.
  • namespace. The namespace of the system structure from which the script processing request was initiated. For example, for a workspace, this is its code.  
  • code. The code of the system structure from which the script processing request was initiated. For example, the business process code, the code of the business process action in the module, etc.  

The more conditions specified, the more precise the script selection for the pool. If a parameter is not filled in, it is not considered.  

Examples of script selection configurations

 
Let’s see pool configuration options demonstrating different levels of script selection:  

  1. Broadest coverage. All scripts in the CRM workspace are published and executed on a dedicated worker pool:  

   workerPoolCfg:
     pools:
       namespacepool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long
         sources:
         - company: head # Company name
           namespace: crm # Workspace code

  1. Moderate selection. Only scripts from business processes in the CRM workspace are executed on a dedicated worker pool:  

   workerPoolCfg:
     pools:
       namespacepool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long
         sources:
         - company: head # Company name
           namespace: crm # Workspace code
           operation: execute # Operation type — script execution
           type: process # Only scripts from business processes are selected

  1. More precise selection. Scripts from business processes associated with the app with the clientapp code in the CRM workspace are executed on a dedicated worker pool:  

  workerPoolCfg:
    pools:
      applicationpool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long
        sources:
        - company: head # Company name
          namespace: crm.clientapp # `{workspace code}.{app code}`
          operation: execute # Operation type — script execution
          type: process # Only scripts from business processes are selected

  1. Most precise selection. Only scripts from the Create lead business process are executed on a dedicated worker pool:  

  workerPoolCfg:
    pools:
      processpool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long
        sources:
        - company: head # Company name
          namespace: crm.clientapp # `{workspace code}.{app code}`
          operation: execute # Operation type — script execution
          type: process # Only scripts from the business process are selected
          code: createlead # The business process code from which scripts are selected
  1. Autoscaling pool parameters (autoscaling ).
     
    Depending on the load on the worker pool, configure settings for its automatic scaling. Based on these settings, the specified number of worker replicas will be created in the Kubernetes orchestrator. To do this, fill in the parameters in the autoscaling block:  
  • enabled. The true value enables autoscaling.  
  • type. The autoscaling method selection. Specify which tool to use. Available values:  
    • "hpa". Horizontal Pod Autoscaler. Used by default. No additional configuration is required.  
    • "keda". Kubernetes event-driven autoscaling. Used if the additional KEDA component is configured.
  • minReplicas. The minimum number of replicas in the pool.  
  • maxReplicas. The maximum number of replicas in the pool.  
  1. Additional pool options (options).
     
    For server scripts, there is an execution timeout. If a script does not complete within this time, it is terminated. This prevents the pool from being blocked due to long script execution. To set timeouts, fill in the parameters in the options section:  
  • defaultScriptTimeoutSeconds. The standard script execution timeout in seconds. After this time is up, script execution is terminated.  
  • maxScriptTimeoutSeconds. The maximum script execution timeout in seconds. After this time is up, script execution is terminated.  

 

Step 2: Apply the configured worker pool settings

Once you have configured the script selection and autoscaling parameters for worker pools in the values-elma365.yaml file, apply the updated settings.  

 

Use case: Configuring a dedicated pool for business process script processing

 

Suppose we have configured a dedicated worker pool in the values-elma365.yaml file for the Create lead business process in the CRM workspace:  

workerPoolCfg:
  pools:
    processpool: # The pool identifier is specified in free form using lowercase Latin letters and numbers, up to 20 characters long
      sources:
      - company: head # Company name
        namespace: crm # Workspace code where the business process is created
        operation: execute # Operation type — script execution
        type: process # Only scripts from the business process are selected
        code: createlead # Only scripts with the Create lead business process code are selected
      autoscaling:
        enabled: true
        type: "hpa"
        minReplicas: 1
        maxReplicas: 9

 

After applying these settings, the following are automatically created:  

  • A worker pool in Kubernetes.  
  • A separate queue in RabbitMQ for this pool to distribute script processing requests for the Create lead business process.  

When the Create lead process is launched in the system, a script processing request is automatically generated. This request includes the following data:  

  • Company: head.  
  • Operation: execute.  
  • System structure type: process.  
  • System structure namespace: crm.  
  • System structure code: createlead.  

Since we specified this data in the dedicated worker pool settings, the request is automatically placed in this pool’s queue and executed within it.  

Delete a configured worker pool

To delete a configured worker pool, remove the previously specified parameters from the values-elma365.yaml file and apply them. After this, in RabbitMQ, all unprocessed script processing requests from its queue will be redirected to the script.default queue. From there, they will be distributed among shared worker replicas.

autoscaling-service-enterprise.html enable-monitoring-enterprise.html