If we provide an access group in queue processor does it override the system runtime context,and if not then why do we specify alt access group then?
No, providing an alternate access group in the Queue Processor rule does not override the System Runtime Context (SRC). They serve entirely different purposes at different stages of the application lifecycle.
1. System Runtime Context (SRC) — Startup & Initialization
During platform startup, the SRC is used exclusively to discover and initialize available queue processor rule instances.
-
How it works: The system scans the applications listed in the SRC, constructs a structured application tree, and flattens it into a prioritized list of rulesets.
-
Rule Resolution: The platform iterates through this list to open and instantiate each queue processor. If it encounters a queue processor name that has already been initialized from a higher ruleset, it skips it. This ordered sequence is what allows a queue processor in a higher application layer to override one in a lower layer.
2. Alternate Access Group — Runtime Execution
The Alternate Access Group has nothing to do with SRC or the initialization of the rule itself. Instead, it provides the authorization and processing context while the queued message is actively being executed.
-
With an Alternate Access Group: At runtime, the rule resolution, data page access, and security policies for processing the queued item happen based on the context of this specified access group.
-
Without an Alternate Access Group: If left blank, the queue processor defaults to the context of the message producer (the specific user or system session that queued the object in the first place).
-
Use SRC to make sure system knows your Queue Processor exists and respects your application’s ruleset hierarchy during startup.
-
Use the Alternate Access Group to ensure that when the background process runs, it executes with the correct application context, regardless of who queued the item.
Source : Pegasystems Documentation
Queue Processor does not override the system runtime context; instead, the alternate access group only defines which application rules, roles, and security permissions are used during processing, while the actual execution continues to run under the system-defined runtime context.
Hi @RameshSangili and @VVNagaSaiN here I am still not clear if we already use the system runtime context and it provides the context in which QP will run so why do we still configure an access group ,as the system runtime context already provides in which application the QP has to run?
Hi @VVNagaSaiN as you stated "Use the Alternate Access Group to ensure that when the background process runs, it executes with the correct application context, regardless of who queued the item."-here already system runtime context will provide the orrect application context to the qp right?so why do we even need an access group if it cant override the system runtime context?
System runtime context will not provide the context in which the QP will run.
If there are two queue processors with in a server in two different applications AppA and AppB, if we only mention AppA in SRC and AppB is not in SRC, then it just indicates that AppA’s queue processors needs to be run in the application. For AppB, even though there are queue processors present in it, you will not have them running because you don’t mention it in SRC. This is the purpose of SRC - to identify which all queue processors and job schedulers are available in a server to run. It is not its job to tell the queue processor in which context it needs to run.
Whereas, the access group provided while triggering gives it the actual context in which it needs to run. (Your SRC cannot give context because you have multiple applications and rulesets present in it. We cannot expect the system to magically know which application to pick from SRC if there is no access group context provided while triggering.)
Hi @VVNagaSaiN thanks a lot for this clear explainiation.