Functional Worker in Matrix42 ESM

Last updated
Save as PDF

Overview

This document provides a detailed description of the Functional Worker, a new execution engine introduced in Matrix42 ESM version 26.1. The Functional Worker consolidates and modernizes background processing across the platform, offering a unified, secure, and cross-platform runtime for asynchronous tasks and custom workloads. It functions as a key component of the ongoing ESM Platform modernization aligned with the Cloud Your Way strategy, supporting operation on both Windows and Linux, in virtual machines, servers, and containerized environments.

The following sections describe the purpose, architecture, operating modes, deployment models, and principles of assembly loading, sandboxing, and performance optimization implemented in the Functional Worker.

Purpose

The Functional Worker was introduced to support the full modernization of the ESM Platform and to ensure compatibility with heterogeneous deployment models. Its implementation enables the platform to operate seamlessly whether deployed on-premises, in private or public cloud environments, or in container-based infrastructures.

Unification and Simplification of Background Processing

The Functional Worker consolidates multiple legacy components previously responsible for asynchronous and distributed workload processing. The following processes are fully replaced:

Host Common
Host Scheduler
Matrix42 Worker, Matrix42 Remote Worker

This unification results in a streamlined architecture and removes historical fragmentation in background task execution.

.NET Platform Modernization

For many years, the platform relied on .NET Framework, which is no longer actively developed by Microsoft and remains in maintenance mode.
The Functional Worker is implemented from scratch on Microsoft .NET (currently .NET 8), utilizing continuous improvements in performance, security, and cross-platform capabilities.

Multi-Runtime Support

The Functional Worker dynamically selects an execution runtime depending on deployment model and task requirements:

.NET Core on Linux
Used in all Linux-based container deployments (public cloud or private cloud), where the majority of tasks are executed.
.NET Core on Windows
The default runtime for on-premise ESM installations. In cloud deployments, it executes tasks that rely on Windows-specific functionality not available on Linux.
.NET Framework 4.8
Available only during the transition period from .NET Framework to .NET Core.
Currently used primarily for the Workflow Engine, which depends on Windows Workflow Foundation components that exist only on .NET Framework.

Custom Code Execution in Sandboxes

The ESM platform has historically allowed execution of custom .NET assemblies or PowerShell scripts deployed directly into the web application process (w3wp / m42services). This model introduced several issues:

Application restarts during deployment of custom logic
Downtime risks
Security exposure due to unrestricted access to server infrastructure

The Functional Worker introduces a fully isolated sandboxed execution model:

A dedicated sandbox process is created on demand
Custom logic executes with minimal permissions
No impact on the Web Application process
No application restarts required
Server infrastructure exposure is significantly reduced

Smart Resolution of Assembly Versioning Conflicts

Previously, installing two extensions that deployed the same assembly in different versions resulted in immediate conflicts and could corrupt one of the extensions.

The Functional Worker resolves this automatically by:

Detecting version conflicts during assembly loading
Spawning additional isolated processes to load and execute each conflicting assembly version separately

This ensures system stability and compatibility of independently developed extensions.

Automatic Self-Recovery

The Functional Worker starts a new process for each single task or batch of tasks. This approach ensures:

Continuous renewal of the execution environment
Prevention of memory accumulation issues
Automatic adoption of updated assemblies when new versions are deployed

This contributes to improved stability and reduced operational risks.

Horizontal Scaling and Workload Distribution

The Functional Worker is designed to handle moments of increased system load. It can automatically create additional execution processes to accommodate peak workloads. In container-based installations, autoscaling mechanisms can be used to spawn additional Functional Worker container instances to improve throughput and performance.

Architecture

The Functional Worker architecture consists of a continuously running main process and a set of short-lived executor processes.

Dispatcher

The Matrix42 Functional Worker Dispatcher is the always-running root process responsible for:

Polling tasks from the message queue
Determining required execution context
Spawning or reusing the appropriate AsyncExecutor subprocess

Loading Assemblies

Before execution, the Dispatcher determines which assemblies are required by a task. If assemblies are missing from the local Functional Worker application directories, they are automatically discovered, downloaded, and cached from the following sources:

Web Application Server
All core ESM assemblies are available on the application server and can be obtained either via web service or directly (if running on the same host).
InstalledPackages Folder
For on-premise installations, custom assemblies delivered with extensions are stored under:
<ApplicationFolder>\InstalledPackages\Assemblies
Extensions Blob Storage
In cloud container deployments, custom assemblies are stored either in Azure Storage Account (Public Cloud) or S3-compatible storage (Private Cloud)

All assemblies delivered by extensions are registered in the table DWPExtensionAssemblyClass, enabling correct identification and version selection during assembly discovery.

Deployment Models

On-Premise Deployment

When the product is installed on a Windows Server or VM, the Functional Worker is deployed as a Windows Service named Matrix42 Functional Worker Dispatcher

This service creates short-running subprocesses when tasks are executed. Depending on task requirements, these subprocesses may run on:

.NET Core (Windows)
.NET Framework (for non-migrated tasks)

Cloud / Container Deployments

In cloud environments, Functional Worker operates within dedicated containers:

Linux Functional Worker Container
Executes the .NET Linux runtime and handles most tasks.
Windows Functional Worker Container
Hosts tasks incompatible with Linux.
It runs only in Isolated mode and remains idle most of the time with only the Dispatcher active, consuming minimal system resources.

Remote Deployment

Functional Worker may also be installed outside the main application server or cluster and can act as a Data Gateway, supporting distributed task execution.

Execution Sub-Processes

The Dispatcher polls tasks from the queue and assigns them to Async Executor Worker processes. Depending on the type of task and configuration, the Dispatcher either creates a new AsyncExecutor exclusively for the task, or reuses an existing one

Async Executor Worker Modes

1. Real-Time Worker

A multithreaded executor optimized for lightweight tasks requiring fast response times.

Characteristics:

A single Real-Time Worker can handle multiple tasks
Stays alive until all tasks are processed and no additional tasks appear within the defined idle time (5 minutes)
Under load or in case of assembly conflicts, additional Real-Time Workers are automatically created and later terminated

Configuration parameters:

MaxParallelism – number of concurrent execution threads
Data Layer Initialization Mode – Real-Time Worker loads the full schema and has no Data Layer limitations

Examples of task types executed in Real-Time Worker:

Custom Web Services
Custom CRUD Behaviours
Email Engine (sending emails)
Configured Business Engines (non-heavy workloads), like Compliance Rules, Service Management Escalation Manager

2. Isolated Worker

A dedicated process created for a single long-running task. Used when tasks require significant resources or extended execution time.

Task types executed in Isolated Worker:

Workflows
GDIE
Configured Business Engines requiring heavy computational resources (e.g., History Consolidation)

3. Singleton Worker

Single cluster-wide instance for continuous or long-running tasks.

Examples: Engine Activation Scheduler, Workflow Delay Processor

AsyncExecutor Process Initialization

To maintain high system performance, it is crucial that AsyncExecutor processes initialize quickly and consume minimal memory. The Functional Worker framework optimizes process initialization by smartly loading only the Data Layer schema and dependency components required for the specific task.

Data Layer Initialization

To reduce overhead and accelerate task execution, the Functional Worker supports several Data Layer initialization modes:

None
No schema loaded; for tasks not requiring database access
(e.g., data collection, PDF generation)
Minimal
Loads only essential schema elements. Additional items are loaded on demand.
Predefined
Similar to Minimal mode, but with a predefined list of schema items to be loaded immediately.
Full
Loads the complete schema at startup. Used sparingly for tasks requiring extensive schema access (e.g., History Consolidation).
GDIE
Used exclusively for GDIE processing and loads only schema elements required for the specific import definition.

Profiling Schema Loading

For Business Engines and Workflow tasks executed in Isolated Worker with “Minimal” or “Predefined” modes, the Functional Worker analyzes which schema items were loaded during execution.
This profile is stored in the table SchemaPreLoadOptimization.

During subsequent executions, the Data Layer initializes using Predefined mode populated with these profiled schema items, reducing initialization time.

Dependency Container Components Initialization

The Functional Worker includes a new hosting model for business components. Assemblies can define dependencies through a *.dll.host.config file.
When detected, the Functional Worker dynamically loads the required modules into the process.

Example configuration:

Imagoverum.FleetManagement.Services.dll.host.config

<?xml version="1.0" encoding="utf-8" ?> 
<host xmlns="urn:m42/host.config"> 
   <modules> 
      <module assembly="Matrix42.DataLayer.Persistence" /> 
      <module assembly="Matrix42.Blob.BizLogic" /> 
   </modules>
 </host>

Sandboxed Extensions

Beginning with version 26.1, the platform introduces a new extension model—Sandboxed Extensions—which dramatically improves product security, maintainability, and deployment reliability. Custom assemblies or scripts no longer execute inside the Web Application but always run inside isolated processes managed by the Functional Worker.

From version 26.2 ESM Platform support only Sandboxed Extensions. Updating to 26.2 version will be blocked when at least one Non-sandboxed extension installed

Key Capabilities

Universal Deployment

Extensions implemented on .NET Core or .NET Standard include their own runtime assemblies, allowing them to run across all supported deployment models without modification.

Zero-Downtime Installation

Sandboxed Extensions have no impact on the Web Application or other active processes. Deployment does not require application restarts and does not cause downtime.

Automatic Assembly Version Isolation

The Functional Worker automatically detects third-party assembly version conflicts between extensions. In case of conflict, it spawns a dedicated process that loads the correct version, ensuring isolated and safe execution.

Secure and Isolated Execution

All custom logic runs in a controlled sandbox environment, preventing unintended side effects on the core product and improving overall platform security.