How Queue Processors/Job Schedulers work in Pega Constellation?
Queue Processors are used for asynchronous message processing. This is replacement of legacy standard agent.
Please refer the below article for more info - Queue processors and job schedulers | Pega Academy
In Pega, background jobs (like Queue Processors and Job Schedulers) are indeed UI-agnostic. They function at the server/engine level, meaning the core logic remains consistent whether your application uses UI Kit, Theme Cosmos, or the modern Constellation architecture
so to configure them for a case type how will we invoke them? as now we are dealing with views in pega constellation? Basically we have to use Dev studio here but still if i can get a step by step guidance to run on a case type that uses constellation architecture would really help.
Constellation is Pega’s modern UI architecture, but all background processing continues to operate at the platform level. This means Queue Processors (QPs) and Job Schedulers (JSs) behave the same in both Theme Cosmos and Constellation. The main difference is that Constellation applications depend more heavily on server-side asynchronous execution, since their UI is lightweight, event-driven, and designed to remain highly responsive. As a result, work that could slow down user interactions is pushed to background processors.
Queue Processors -
Queue Processors handle event-driven asynchronous processing.
When a case, flow action, or system event triggers work that should ru in the background, Pega uses Queue-For-Processing to create a queue item. This ensures that the UI is not blocked.
All QP messages are stored in Kafka topics managed by Pega’s Stream service. Each queue processor has its own topic, divided into multiple partitions, enabling parallel consumption. Pega reduced the default partition count from 20 to 6 in later versions, but it can be customized to increase throughput.
Processing is performed by Data Flow consumers, which pick up messages from Kafka and execute the associated activity or logic. The platform supports multi-node parallelism, allowing multiple threads to process messages at the same time across the cluster.
If a queued item fails or is intentionally delayed, Pega persists it in dedicated database tables (pr_sys_msg_qp_brokenitems and pr_sys_delayed_queue) for monitoring and recovery.
Job Schedulers -
Job Schedulers support time-based recurring processing. From Pega 8.4 onward, they run under a System Runtime Context or ASYNCPROCESSOR requestor, which activates them at configured intervals.
A JS executes an activity or data transform and can be configured to run on specific nodes—commonly background nodes—to avoid contention with UI processing. After execution, it becomes idle until the next scheduled run.
There is no difference in the way Queue Processor and Job Scheduler work. Constellation is related to UI architecture changes introduced by Pega. Queue Processor and Job Scheduler are used to process data in the system and execute logic in the back end. The way data is stored in the back end does not change between traditional applications and Constellation applications.
Please refer some related articles
Queue Processor - its Configuration, Usage & Execution - OneStopPega
Job Scheduler - its Configuration, Usage & Execution - OneStopPega
2 Likes
Agree on this. agents behave same way irrespective of UI architectures.