I’m working on understanding the Java code used in the Pega activity pzProcessDelayedQPItems. Here’s the relevant snippet:
com.pega.platform.executor.queueprocessor.internal.QueueProcessorDelayedMessageService service =
((com.pega.pegarules.priv.context.PegaNode) tools.getRequestor().getNode()).getDelayedQueueProcessor();
if (service != null) {
service.processMessages();
}
This code comes from the default Pega Rule activity pzProcessDelayedQPItems, and I’d like to understand what the processMessages method is doing in the background. Unfortunately, I cannot find documentation or implementation details for this method in the public API (available under Resources > Engine API).
Does Pega provide a way to inspect non-public APIs like this, or are they deliberately hidden from view?
Any insights or guidance on how to explore or work with this would be greatly appreciated!
To access non-public APIs like the processMessages method in QueueProcessorDelayedMessageService, you can use Java reflection to inspect the class and its methods. Reflection allows you to list all available methods and analyze their parameters and return types at runtime. Another approach is debugging—set breakpoints in the Pega activity pzProcessDelayedQPItems to observe the behavior of processMessages and the data it processes. You can also enable detailed logging for the relevant classes to capture additional insights in the logs. If allowed by your organization, you may explore the implementation by decompiling the relevant Pega JARs using tools like JD-GUI, though this requires caution as it might violate licensing agreements. Alternatively, reviewing how Pega queue processors work via public APIs or configuring them in the Admin Studio can help. You can even open a Pega SR on the same. thanks
@MichaelY9263 You can certainly use the suggestions from Sairohith to inspect the code, but I just want to caution against any attempt to use these private methods directly. Since they are Pega private, there are no guarantees of backward compatibility from release to release. Any code you write against them or assumptions on how they operate may (and probably will!) break in the future.