Requestor types in Pega
In this blog article, we will see about different requestor types in Pega.
This article is implemented using Pega Infinity '24 version.
First, let’s start with understanding the term – Requestor.
What is a requestor?
From the name, we can say that it can be any people or object which requests for a service.
From the Pega application stand-point, the requestor can be developers, users, or other applications that can request Pega applications for a service.
Simple examples – When you try to login Pega, you act as a requestor who tries to get serviced by a Pega application. When a Java application tries to access Pega data via API call, they act as a requestor.
Because there are different types of requestors who can access or get served by Pega application, Pega use a Data instances called Requestor type to support the low-code configuration.
Before jumping into detail about requestor types, let’s also understand some authentication and authorization layers in between requestors and Pega applications.
Let’s break down the above picture.
Step 1: There are different types of requestors trying to access Pega application.
Let’s consider you as a user trying to access the claims application.
Step 2: As soon as you hit Pega URL a session object is created, which in turn creates a requestor object in Pega.
Here you are a requestor but still you are not authenticated, but the Pega application should display the login screens and does other unauthenticated processing right?
We also know that to execute any pega rules, definitely an app context should be established. This can be the default PegaRULES context or it can be an unauthenticated app context. In the picture, you can already see a default ruleset list setup.
Step 3: App context- Now when you provide your user name and password, then based on your access group and application context, the right context or ruleset list is established to access the application rules.
Step 4: With the right app context, you can now access your Pega application or data.
Just remember the second step – establishing the default context. Let’s move on to the requestor types.
As of Pega Infinity ’23, ’24, there are five requestor types in Pega system. (Out of which one is deprecated already, so only 4 active requestor types are applicable)
- Browser (H)
- Batch (B)
- Application (A)
- Portal (P)
- AsyncProcessor.
You see there are two system names and totally 10 requestor types, 5 for each system.
By default with every Pega installation, you get two system names – pega, prpc.
The default system name will be Pega, unless you change it.
Note: In any production system, you should always create your own system name. This is the very first step in setting up and installing Pega in any customer engagements.
All Requestors accessing Pega platform must fall under a Requestor type.
Each Requestor can be identified uniquely by Requestor ID.
How to create Requestor types in Pega?
You should not be creating a requestor type manually!! As soon as Pega platform is installed, 5 requestor types of current system name (pega) get automatically created. In addition, 5 requestor types of system prpc is created (this is reserved).
Records -> SysAdmin -> Requestor types
Also note that, when you create a new system name and restart your server, new requestor types will be automatically created for the new system name.
What are the configurations in Requestor type instances?
Click and open any of the requestor type.
You see two main tabs.
- Definition
- Activities
Definition tab
Define this requestor type using two options as shown below.
This configuration helps with establishing the default context as we saw in the introduction.
We all know this hierarchy already
So you can establish the default context either by specifying the application based access group or directly specifying the list of rulesets and roles.
a) When using, Application based access group, just specify only the access group
You can input a list of access group names but always enable a default access group.
b) When using List of Rulesets and Roles, you can specify the rulesets in the right order of priority
Note: 99% of the time, we will be using the Application-based access group. I haven’t seen an implementation where ruleset list option was used! (Scarcely used for AsyncProcessor requestor type, which we will cover shortly)
Activities tab
You can also configure an activity to execute once the session/requestor is created and default context is established.
If you can open the default pega browser requestor type, you can find the OOTB activity
Code-.Web-Start. You can also open the activity and find that the activity is responsible to present the login screen for the browser requestor type.
Note: you will never create a requestor type on your own, but you will be updating the request type access groups for your system!
Okay, now let’s dive deep into different requestor types.
1. What is Browser Requestor type?
Normally developers or end users access Pega platform using a browser (IE, Chrome). So as soon as we hit the Pega URL, a requestor of type ‘browser’ is created.
Every browser requestor starts with ‘H’ and must belong to a Pega application.
How does Pega determine which application the ‘Browser requestor’ is associated with?
Requestor creation – As we saw in the introduction, when an user tries to login, a browser requestor is created.
Initial Context – Then Pega uses the unauthenticated access group specified in the browser requestor type instance to establish the default initial context and display the login screen.
Application Context – After successful login, based on the Operator configuration, the right context is established using the access group specified in the Operator record.
There are a lot of Unauthenticated access groups comes OOTB. You can also filter on the Unauthenticated access groups to find the existing instances in the system.
As a best practice, for any Pega implementation it is suggested to create a system-specific unauthenticated access group – Unauthenticated application, that holds the custom login screen and processing.
Most about Unauthenticated access in a separate post 😉
In most of the scenarios, you will be updating the browser requestor type to point to the right Unauthenticated access group.
2. What is Application Requestor Type?
All types of service processing – file listeners, REST and other services are processed by a application requestor.
Every App requestor starts with ‘A’.
How does Pega determine which application the ‘Application requestor’ is associated with?
Requestor creation – Say a Java application needs to access a Pega REST API resource. As soon as it hits the URL, a App requestor is created.
Initial Context – Then Pega uses the access group specified in the App requestor type instance to establish the default initial context and tries to find the service package instance.
Application Context – As a final step, Pega uses the access group specified in the service package instance and establishes the right application context to execute the service activity or process the service request.
3. What is Batch Requestor Type?
All internal background process (Agents, jobs, queue processors) comes under Batch requestors.
You can visit the below link to know more about background processing in Pega
https://myknowtech.com/tag/background-processing
Every batch requestor starts with ‘B’.
Let’s first talk about Agents.
How does Pega determine the requestor context for Agents?
Let’s start with basics. There are two types of Agent.
- Standard
- Advanced
Note: To know about standard and advanced agents please check my below article.
We also know that activity rule (that will be executed as agent processing) is the main configuration in the Agent rule form and to execute the activity we need the right app context.
In the Agent Rule, we can configure the Access group in the security tab.
Does it mean, the agent processing always uses the access group specified in the agent rule form? – The answers in No. It works differently for standard agents and advanced agents.
Requestor creation – Pega internal mechanism takes care of requestor creation when a background processing need to be executed.
Application Context –
For Standard agent:
Standard agent completely ignores the access group field configured in the agent rule form. It uses the access group of the Operator, who queues an entry to the Standard agent and the context is established based on the application context of the operator. With this context the agent activity is located and executed.
For Advanced agent:
a) Pega uses the access group specified in the Security tab, to determine the application and locate the agent activity rule.
b) If Access group in security tab is empty, then Pega uses the access group specified in the batch requestor type to determine the application and locate the agent activity rule.
Okay before going into the next requestor type, I will open up with a question!
Let’s say a Pega client system (database) hosts around 12+ applications and each application has its own agent rules (rulesets). When the system starts up, all the agent rules will be rule-resolved and eligible for execution..
What if you don’t want to start/execute the agents packaged under two specific applications?! – Of course, you can always manage these using agent schedule instances! But what about Job schedulers and queue processors?!
4. What is AsyncProcessor Requestor Type?
The sole purpose of this AsyncProcessor requestor type is support and rule resolve the Job Scheduler and Queue Processor.
Pega Introduced this requestor type in Pega 8.1 version and it got deprecated in 8.3 version (that was quick ) and replaced with system runtime context
You can find more information in a separate article
All AsyncProcessor requestor type starts with ‘B’ same as batch requestor type.
Why Pega introduced this AsyncProcessor requestor type in the first place?
A short story –
Pega Introduced the background processing rules – Job Schedulers and Queue processors in Pega 8.1 versions to replace the Agent rule background processing.
Jobs and QPs need to be rule-resolved (identifying the Jobs and queue processors in the system) and also need an access group context to execute the activities.
Let’s concentrate only on the first part.
So how this rule-resolve varies between Agents processing Vs Job, queue processor is – Pega don’t use any agent schedules for Job and queues and just don’t want to rule-resolve all existing Jobs and queue processors available in the system.
It wants to use a system-wide run time context to rule resolve the Jobs and queue processors.
That is where the AsyncProcessor requestor type comes in. We need to specify an access group in the AsyncProcessor requestor type that helps with rule resolving the Jobs and Queue processors.
By this way, only the Jobs and Queue Processors that are part of access group or ruleset lists specified in the AsyncProcessor requestor type wake up and gets executed!
Then why Pega Deprecated this AsyncProcessor requestor type?
As you know we can have only one default application in the AsyncProcessor requestor type and also managing all the individual rulesets started to add more maintenance overhead.
That is the reason Pega introduced System runtime context in 8.3 version and deprecated the AsyncProcessor requestor type.
You can use this navigation Configure -> System -> General -> System Runtime Context to view the landing page.
There you can list down multiple applications and pega uses the application order priority and rule-resolve the Jobs and queue processors.
For example – let’s say you are building a new application and created a new Job scheduler. If you don’t include the new application in the system runtime context (from 8.3 version), the Job will never be rule resolved and you cannot find it in admin studio also Job will never wake up and run. So this is a very critical configuration that replaces the AsyncProcessor requestor type.
5. What is Portal Requestor Type?
This is the least used requestor type!! I have never heard of its use cases.
Portlet is a web-based component and can be defined using service Portlet rules (which is not available in later version). For HTTP/browser access Pega creates the Portal requestors.
Pega use the access group specified in the Portlet Service package to determine the application.
Every Portal requestor starts with ‘P’.
Always remember there are some rules/features you will never come across in 90% of project implementations 😉 Do not worry about those, but just know it exists!! This Portal requestor type is one such example!
Okay, a final question
How to debug various requestors types/ requestors in Pega?
Admin studio is the right place where you can perform different actions on the requestors.
Switch to your admin studio -> Resources -> Requestors
There you can find all the requestors.
Note: Currently I am logging in into Pega community edition with 1 node / 1 server in the cluster. In real-time, you may have multiple servers/nodes and so you will get an option to find the requestors per node or for the entire cluster.
In this list you can filter out the requestor type or the application columns to short-list the right requestors.
You can use the three dots, to perform different operations
Some notable operations are
Trace – To remote trace any requestor available in the cluster. This can come very handy when you want to trace any browser session.
View clipboard – Another debugging option which you can use remotely on any requestor session
Terminate – You can also kill the requestors if needed. If a particular session is orphaned or throwing errors, you can forcefully terminate the requestor using this option.
You can also easily understand the other operator from the name itself!
Hope you are clear with the available five requestor types in Pega
