Queue Processors

Hi Team,

I have created a dedicated Queue Processor and used "Run in background" smart shape to queue an item from my case processing.

But it was not showing my Queue Processor in Admin Studio under Queue Processors landing page. Instead it was showing an error.

Resolved this error by giving my application access group in AsyncProcessor Requestor type & making it as default.

But here my question is :

1. Why it is not considering & switching to Operator's access group who queued that item when it is processing it (Like standard agents ).

2. If I have multiple queue processors in multiple applications under a node, then we need to add multiple access groups in AysncProcessor Requestor type but we can not make both of them as default.

Please suggest me an approach to resolve this problem.

Your help will be highly appreciated.

Thanks in advance.

***Edited by Moderator: Lochan to update platform capability tags***


Keep up to date on this post and subscribe to comments

July 1, 2019 - 3:58pm


queue item is not getting queued for me as well. it would have been better if it takes requestor access group by default.


1.i stopped my queue processor from admin studio

2.Queued one entry using queue-for-processing


but nothing is showing in scheduled list in admin studio

Version: 8.2.1

July 1, 2019 - 4:34pm

Hi Rajendra,

As part of Pega Infinity™, a new AsyncProcessor requestor type was introduced. The access group that is configured in this requestor type is used to resolve queue processors. You need to ensure that the newly created queue processor is resolvable using this context. 

Each Pega Platform operator logs in using unique ID that is associated with a specific access group. This access group provides a context to resolve rules. Because Job Scheduler and Queue Processor rules in the background, no user-based context is available to resolve these rules. The AsyncProcessor requestor type provides the context to resolve Job Scheduler and Queue Processor rules.



July 2, 2019 - 1:35am
Response to Vikash Karn

Hi Vikash,

Thanks for quick reply. As you said, if it is considering the AsyncProcessor Access Group, then

  • what is need of providing "Alternate Access Group" as a parameter to "Run in Background" smart shape?(It is not considering even it is specified)
  • How we can configure multiple Access Groups in AsyncProcessor requestor type?







August 8, 2019 - 1:25pm
Response to RajendraP1578

Adding some thoughts to stir more discussion as it unclear to me what’s best, especially if you try to scale to many apps in a system.

  • I don’t believe you can use multiple Access Groups in an Requestor type (for AsyncProcessor) – as only one is selected when saving the requestor type
  • I suspect the Parameter  “Alternate Access Group” which is set when queueing an item (Run in background or queue for processing method) is used when the queued item is executed, but you first have to have the AsyncProcessor requestor type with an access group that will resolve (aka find) the ruleset of the Queue Process rule in order for the processor to even start, before it can try to execute a queued item.

​Possible multi apps approaches …

  1. Creating an Uber access group put in AsyncProcessor with all the ruleset stacks of all the applications using Queue Processors, or at least with all the rulesets that Queue Processors are defined in, so the Queue Processor rule can be found by the AsyncProcessor’s access group – with expectation the alternate is set per above so correct application stack is used when it run the queued instance.
  2. Using Node Classifications to run Queue Processors on specific custom nodes – but for this to work with defaulting the correct application’s access group for a node, it would mean specific different system names are setup for nodes so the Requestor Type of that system name can set the specific application access group – not sure the latter is recommended.
  3. Use a common layer ruleset for the apps, to have one ruleset to define the queue processors in with a stub activity – so the std AsyncProcessor access group just needs that ruleset, and then the app rulesets override the activity stub, and the queueing methods specify the correct alternate access group for the application.



August 15, 2019 - 6:00pm
Response to bellm

Was able to confirm in the 8.2 series this was an issue and has been addressed in 8.3 with design changes, adding a new feature called System Runtime Context  and deprecating the AsyncProcessor requestor type.  See link to the  8.3 Help Topic on the community for AsyncProcessor which points to the new features ...


July 2, 2019 - 10:09am

Hi Vikash,

Do you have any idea on below?

Previously we used to check instances of system-queue-defaultentry for standard agent queue items. Like this how to check for queue processor queue items?

my problem is i am queueing using queue-for-processing step method and there is no failure in tracer but the queue item is not visible in scheduled instances in admin studio.  i stopped queue processor to make sure it won't process anything so that we can check scheduled instances.

August 7, 2019 - 10:08am
Response to kartheekv


Delayed queue processor items will be instances of "System-Message-QueueProcessor-DelayedItem " and broken ones will be instances of "System-Message-QueueProcessor-BrokenItem"

we cannot delay the queue processor from admin studio, so we are using delay option in Queue processor and passing some future time while queuing so that we can trace and debug.



August 7, 2019 - 6:03pm
Response to kartheekv

Hi Kartheek,


You can check below things:

1. Check if the Data flow is running or is in paused state (Click on the 3 dots at the end of the queue processor name in the admin studio and select view data flow). Here you can also check if the Data Flow is processing the records or not. If it is not processing then check the reason of the failure.

2. Check if you Stream Node is up or not as queue processor uses Stream nodes to run.