Tasks added to a concurrent task queue can be assigned to any number of M-Files servers in the Multi-Server Mode configuration, may be processed concurrently, and without regard for the order in which they were added to the queue.
Task queues are uniquely identified by a Queue ID. This ID can be used to interact with the queue from other applications, through the M-Files COM API object model.
Each queue can process one or more task types, with each task type being processed by a specified processing method; this way a queue could contain a task to create an object, a task to update an object, and a task to delete an object, all at once.
Creating the task queue, and processing items
Creating the task queue within the VAF is broken down into three main steps:
Creating the configuration options.
Implement IUsesTaskQueue, and override the StartOperations method to register and enable your queue(s).
Create the AppTaskBatchProcessor, providing suitable AppTaskBatchProcessorSettings. This includes providing a collection of task type IDs and their associated processing methods.
Implement the task processing method(s), reporting data on the job processing back to the task processor.
Creating the configuration options
It is good practice to expose configurable values to customize the processing of a task queue. Below are the options used within this sample application.
Registering and enabling the task queue
Within this step we will define a CancellationTokenSource for cancellations of ongoing job processing, and declare our AppTaskBatchProcessor, set up our queue ID and task type (we will use one task type here, but multiple could be defined), and ensure that our task queue registration method (RegisterTaskQueues) is called.
The task queue registration method (RegisterTaskQueues) will be populated in the next step.
Remember that it is important that the queue ID is unique to your application.
Create the sequential task processor
Implement the task processing method
Using custom directives
Each task within the queue can be provided with additional data that can be used during the processing of the job. These objects typically inherit from TaskQueueDirective, and can be parsed out of the job by calling TaskQueueDirective.Parse<T>, as shown in the previous code sample.
Custom directive classes can also be used to provide additional data to the method processing the job. In the example below, a custom directive class is used to allow details about a specific object version to be passed to the job:
This data can then be retrieved within the task processing method:
The custom directive class must be serializable by Newtonsoft.JSON, as it will be converted to a JSON representation then stored as a byte array against the job.
Adding items to the queue
Items can be added to the queue from elsewhere within the Vault Application Framework application. In the example below, a task is added to the task queue, but no custom directive is used.
Providing data to the task via a directive
If a task requires additional data then a custom directive can be provided when the object is created. Note that the directive must be provided as a byte array.