Skip to main content
Version: 10.3

View BEP Worker framework

BEP Worker framework​

The BEP Worker framework does the following:

  • Runs multiple executor types within a single Worker application.

  • Instantiates and configures executors.

  • Sends notifications on events, such as tasks taken or processed by Workers, a process failed, and so on

BEP Worker framework design​

The figure below illustrates the design of the Worker framework.

Within the framework, the following elements function as described below:

  • Executors Registry contains a list of all executors in a given Worker app, instantiates, and configures them as required upon requests from Task Router.

  • Task Router receives messages, converts them into request objects, asks Worker Registry for Workers to instantiate, and routes requests to corresponding Workers (call method).

  • The Worker-to-client event subsystem is used by Workers to send event info (not the results) back to a client app. For example, in CT, events are displayed on the user interface.

    Each event includes:

    • Event data: an object containing the event payload.
    • Event timestamp: the time when the event was created within a Worker process.
    • Original task metadata: metadata used by the event handler in a client app, for example, to correlate the event with the original task.

Task-Worker relations​

There are several schemes of task-Worker relations in different applications:

  • Control Tower. Multiple task channels (one per step) per multiple task Workers (one standard and multiple tasks based on Bot Config Bundles (BCB)).

  • AutoML Training. Multiple task channels (one per train process) and a single pool per AutoML version.

  • AutoML Execution. Multiple task channels (one per EGID or model) and multiple Worker pools (one per EGID or model)

Queues​

The following types of queues exist within the Worker framework:

  • Task queues are created when a client opens a channel for submitting tasks.

  • Worker queues are created by the Task Broker as soon as it detects any task queue with a non-conforming Worker, which is defined by the queue's metadata. One queue per Worker type is created.

  • Result queue is created when a client subscribes for results. The operation is to be completed before sending any task.

The figure below illustrates how the RabbitMQ service manages different types of queues.

The framework also comprises a worker-to-client event sending subsystem used by Workers if they need to send event info other than results to a client app. These events form event queues separated from the ones with task results.