Task Processor

Provides unattended task processing in a worker thread for the Activity Processing service.

Remarks

Overview

The Task Processor manages the execution of unattended Processing Tasks in a dedicated background thread. It is used by Grooper's Activity Processing to automate batch processing steps, such as extraction, recognition, or export, without user intervention.

The processor retrieves tasks from a configurable Task Filter, executes the associated Code Activity for each task, and manages error handling, statistics, and connection state. It is designed for robust, high-throughput operation in production environments, supporting features such as operating hours, critical stop events, and dynamic throttling.

How Task Processing Works

1. Initialization:
   The processor is constructed with a database connection, an Unattended Task Filter specifying which tasks to process, a thread priority, and optional operating hours and idle sleep settings.

2. Processing Loop:

   • A worker thread starts and enters a continuous processing loop.
   • The loop checks for tasks matching the filter, respecting configured operating hours and throughput delays.
   • If no tasks are available, the processor enters an idle state and sleeps for a configurable interval.

3. Task Execution:

   • For each Processing Task, the processor loads the associated Batch and Batch Object, then retrieves the correct Code Activity.
   • The activity is invoked to perform the work.
   • Task status is updated based on the result (completed, error, or critical stop).
   • Batch and job status are managed to ensure correct workflow progression.

4. Error Handling and Critical Stops:

   • Errors during task execution are logged and counted.
   • If the number of consecutive errors exceeds the configured maximum, or if a database connection is lost, a critical stop event is raised.
   • The processor can be canceled, allowing for safe shutdown of the service.

5. Statistics and Logging:

   • The processor tracks statistics for completed tasks, errors, and session details.
   • Statistics are flushed to the database at the end of each session or when the job changes.
   • All significant events, errors, and state changes are logged for auditing and diagnostics.

Hosting in the Activity Processing Service

The Activity Processing service works by hosting a configurable number of Task Processor threads. The thread count is controlled using using the 'Number of Threads' property.

The following configurable properties of Activity Processing affect how each Task Processor thread operates:

• Queue Name:
  Determines which Processing Queue the service instance monitors for tasks. Each Task Processor is assigned a filter targeting this queue, ensuring that only tasks from the specified queue are processed. Using different queue names allows for targeted load balancing and resource segmentation across multiple service instances or servers.

• Number of Threads:
  Controls how many parallel Task Processor threads are created by the service. Each thread runs independently, processing tasks in parallel to maximize throughput. Increasing the thread count allows more tasks to be processed simultaneously, but excessive threads may lead to resource contention. Some queues may restrict the number of allowed threads based on their concurrency mode.

• Idle Sleep Time:
  Sets the interval (in seconds) that each Task Processor waits between polling cycles when no tasks are available. Lower values make the processor more responsive to new work, while higher values reduce database and queue polling load. This value is passed to each Task Processor and directly controls its idle wait behavior.

• Hours of Operation:
  Specifies the time ranges during which task processing is permitted. Each Task Processor receives these operating hours and will only process tasks during the allowed windows. Outside these hours, processors remain idle and do not execute tasks, supporting business or maintenance scheduling.

Summary:
The Activity Processing service acts as the orchestrator for unattended task execution, with each Task Processor thread inheriting its configuration. Adjusting these properties allows administrators to control task routing, parallelism, responsiveness, and scheduling for all automated batch processing in Grooper.

Best Practices

• Use operating hours to align processing with business or system availability.
• Monitor error counts and critical stop events to ensure reliable operation.
• Adjust throughput and idle sleep settings to optimize performance and resource usage.
• Regularly review logs and statistics for troubleshooting and process improvement.

Notes

• All errors, connection issues, and critical stops are logged to the Grooper event log and database.
• Session statistics are saved for each processing run, supporting reporting and analysis.
• The processor can be safely canceled or killed in the event of a system shutdown or emergency.

For more information, see the documentation for Processing Task, Unattended Task Filter, Code Activity, and the Activity Processing service.