The client I work for is a bit late in the Pega 8 game and we're only looking at upgrading to Pega 8.3 in coming months. We use agents extensively so I'm furiously trying to learn about queue processors.
I have tried to configure a delayed queue processor. I created a queue class that inherits from System-Queue- (as I would when creating dedicated concrete queue classes for Pega 7 agents to scale) and used a page of this context to queue to the queue processor. When I queued items I noticed that instead of saving the queue instance to my class, it saved it to System-Message-QueueProcessor-DelayedItem instead.
My questions are...
Can queue processors save tasks to custom queue classes?
Is this still best practice to create custom queue concrete classes for large volume background tasks?
Queue Processors make it unnecessary to create custom queue classes that extend System-Queue.
The only class you need is the applies-to class of the persisted step page at the time Queue-For-Processing is called. Typically the persisted step page would be a case.
When the step page is restored to the Clipboard later, an Activity is run in the context of that restored "bootstrap" step page. You are asking whether it is best practice to persist an instance of a "custom queue class" to contain the "bootstrap" data
You do not need a class that inherits from System-Queue-. Queue Processors use the Access Group associated to the ASYNCPROCESSOR Requestor Type as shown on the rule form. Certain properties in System-Queue- would not be used most likely.
You could, instead, persist an instance of Data- class, then use that as your step page. It would be your responsibility to remove those instances when no longer needed.
Thanks PEDEL, that makes sense. However I mentioned testing delayed queuing which still seems to store instances to a System-Message- class. Will it be a concern if we've got a ton of delayed instances in this class?