Queues - System queue

System Queue is a specialized fail safe queue. You insert records into stbl_System_Queue and in turn SystemCallProcessor job will handle the message by calling static .net methods. Since This table is a regular queue table it does not have any views or triggers, so final users will never have access to this table directly. SystemCallProcessor is a regular queue processor, it must be configured properly in order for it to run.


record required in stbl_System_QueueProcessor

record required in stbl_System_Jobs

If you believe thar SQL is the ultimate UI you could also insted run a query to set it up:

declare @_ids table (
    id int not null 

insert into dbo.stbl_System_QueueProcessor
    (Name, QueueTableName)
output inserted.ID into @_ids
select 'SystemCallProcessor', 'stbl_System_Queue';

insert into dbo.stbl_System_Jobs
    (Type, Description, Frequency, StartDate, QueueProcessor_ID, Job_ID)
select 'QueueProcessor', 'Processes items from [stbl_System_Queue]', 'every 10 second', getutcdate(), id, (select max(Job_ID) + 1 from dbo.stbl_System_Jobs with (nolock))
    from @_ids;

This setup should be already in place for all Appframe365 descendant solutions. Most probably you do not need to perform any additional configuration.

Static method

When setup is in place you can start developing code modules to handle queue messages. The method must be public static, it should return Task (asynchronous method) and it should have 2 arguments string and  CancellationToken. Empty implementation below:

using System;
using System.Threading;
using System.Threading.Tasks;

namespace Testing {
    public static class SystemCallExample {
        public static async Task Execute(string args, CancellationToken ct) {            
            await Task.Factory.StartNew(() => false, ct);
            throw new NotImplementedException();

When code module is in place you can start inserting records into stbl_System_Queue  from your triggers:

insert into dbo.stbl_System_Queue
    (TypeName, MethodName, Args)
select 'Testing.SystemCallExample', 'Execute', 'any nvarchar';

Fail safe

Plain queues behave in a way that could potentially block execution flow, when errors are encountered messages are not consumed, blocking other messages. System queue messages on the other hand are transferred to stbl_System_QueueErrors table when errors are encountered. you can view all errors in developer-portal app errors tab:

If you need to retry consuming all messages you can run sstp_System_QueueErrorsReload.


Triggers writing to stbl_System_Queue:

  • stbl_Bundle_ProjectsVersions_ITrig
  • stbl_WebSiteCMS_ModulesVersions_ITrig
  • stbl_System_ReferenceIdentity_ITrig

Code modules with static methods:

  • Code.RecomputeCodeModuleRefs
  • Code.Analyzer


There are 2 benefits of using system queue processor instead of creating your own:

  • It is already configured and no need to create additional tables.
  • It is fail safe.

Related articles

Placeholder "LocalizeWeb2016" failed