Requestor & Requestor Types in Pega

What is a System?

Each Pega environment will be owned by a client or customer and it becomes their system. Pega maintains this identity of each environment using a data instance known as System (Data–Admin–System).

• Each Pega environment will have two default systems that get created during the initial installation (pega, prpc).

• When configuring an environment specific to a client, Pega creates a new system instance specific to that client. For example, when configuring a Pega environment for OSP organization, Pega creates a system as osp-dt1, osp-stg1, osp-prod based on the environment type.
• A single environment can have multiple System names, but only one can be active. For personal edition, we have two systems (pega and prpc) out of which pega will always be active.

What is Requestor?

• In general terms, the requestor is someone requesting something.

• In the same way, when someone [not necessarily a person] wants to perform something in the system and sends a request, Pega considers that as a Requestor.

• Each requestor in Pega can be identified using a unique identifier called Requestor ID.

What is Requestor Type?

• Requestor types in Pega are instances of class Data-Admin-Requestor.
• Requestor type defines the context for the initial connection of the requestor and checks if required privileges exist before allowing the actual execution.

Let’s take a common scenario to understand the usage of the requestor type. When we try to login inside Pega, we hit the URL in the browser and enter the user name and password. Application context is established using the access group of the operator and the respective portals are shown. But the initial login screen is also from Pega. Now, which context Pega uses to display the login screen? 🧐

During each system configuration, Pega creates requestor types specific to that system. The requestor types tagged to the system (which is currently active) in the environment will be used for initial execution. In our scenario, prpc and pega are two available systems, but then requestor type tagged to pega will be used since Pega is the active system.

Requestor type Configuration

We should not create requestor types manually in Pega. Whenever a new system is configured in an environment, Pega automatically creates the required requestor types and tag it to the system name. We should only add/update information of the created requestor types in the environment.

Definition tab

We can set-up initial context in two ways,

• Application-based Access Group [Recommended]
• list of RuleSets and Roles

Application-based Access Group

• With this option selected, we can mention an access group to provide the initial context for the starting connection. By default PRPC: Unauthenticated Access Group will be used.
• It is recommended to use our enterprise application access group with minimal access for the starting connection.
• We can even have more than one access group but only one can be active at any given time.

List of RuleSets and Roles

• We can use this option if we want to selectively configure rulesets and the required roles for the starting connection.

• It is mandatory to mention the above rulesets in the mentioned order when this option is selected in the requestor type. Application-specific rulesets need to be added on top of these.

Activities tab

• We can configure an activity to run once the requestor type is invoked and the initial context gets established.
• For Example, Pega runs activity Code-.Web-Start in the BROWSER requestor type because of which we see the Pega login screen whenever a URL is hit in the browser.

Requestor types in Pega

Requestors in Pega can be created in different ways under different circumstances. Based on the way requestor is created, Pega has broadly classified it into 5 different types,

• BROWSER (H)
• PORTAL (P)
• APP (A)
• BATCH (B)
• ASYNCPROCESSOR (B)

BROWSER

• When we access Pega through web browsers, Pega creates them as a requestor of type BROWSER.
• Requestor ID for these types of requestors starts with the letter H.
• Typical examples could be a developer/end-user logging into the application, mash-up that renders in an external web-page, etc.
• BROWSER requestor uses HTTP or HTTPS to access PRPC and hence these kinds of requestors get created only in the WEB nodes.

PORTAL

We found a lot of interesting facts when we started analyzing portlet application in Pega. We will publish a separate article to demonstrate the end-to-end implementation of the Portlet application in Pega.

• A portlet is a Web–based component that will process requests and generate dynamic content. Similar to web mashup in Pega, we can develop portlet web application and use Portlet services (Rule-Service-Portlet) to render them on a portal container in a web browser.
• Similar to IACAuthentication, Pega has provided a PRPortletService OOTB authentication service rule to handle portlet requests.
• When a request is made to display the Portlet applications in the web browser, then Pega creates them as a requestor of type PORTAL.
• Requestor ID for these types of requestors starts with the letter P.
• The PORTAL requestor uses HTTP to access PRPC and hence these kinds of requestors get created only in the WEB nodes.

Building a Portlet application is similar to our normal application development, but rules that we create must be portlet compliant.

APP

• When an external system accesses PRPC to get the required information, Pega creates them as a requestor of type APP.
• Requestor ID for these types of requestors starts with the letter A.
• Typical examples could be a service call made from an external system to Pega, Queue method in an activity rule, etc.
• APP requestor uses HTTP or HTTPS to access PRPC and hence these kinds of requestors get created only in the WEB nodes.

BATCH

• When Pega creates a request by itself on a specific event to execute a set of pre-defined tasks, Pega creates them as a requestor of type BATCH.
• Requestor ID for these types of requestors starts with letter B.
• Typical examples could be Agents, Listeners configured in Pega, etc.
• BATCH requestors are not restricted to WEB nodes. It depends on the configuration in the rule form of Agents, Listeners, etc. It is recommended not to make BATCH requestors run on WEB nodes for a proper load balancing.

ASYNCPROCESSOR

The agent rule is replaced with the Job scheduler (Advanced Agent) and Queue Processor (Standard Agent) starting from version 8. Hence a new requestor type ASYNCPROCESSOR is introduced starting from v8 to identify the configured Job scheduler and Queue processor.

• Similar to Batch requestors, Pega internally creates an ASYNCPROCESSOR type requestor to handle the execution of the Job scheduler and Queue Processor.
• Requestor ID for these types of requestors starts with the letter B. Even though its a different requestor type, it shares the same prefix as the BATCH requestor.
• ASYNCPROCESSOR requestors are not restricted to WEB nodes. It depends on the configuration in the rule form of a Job scheduler and Queue processor. It is recommended not to make ASYNCPROCESSOR requestors run on WEB nodes for a proper load balancing.

Unlike Advanced agents, Job schedulers won’t create agent schedules to handle its execution. When the Job scheduler & Queue processor wakes up, it directly executes the rule. Hence it is mandatory to have the Job scheduler & Queue processor rules in the context of the access group tagged in the ASYNCPROCESSOR requestor type.

This limitation in the product restricts the usage of a Job scheduler and Queue processor in a system with multiple applications. Hence starting from v 8.3, Pega deprecated ASYNCPROCESSOR and introduced System Runtime Context as a new way to identify the Job scheduler and Queue processor.

System Runtime Context replaces ASYNCPROCESSOR starting from version 8.3

System Runtime Context

System Runtime Context will be used as the initial context by the system when its executes a Job scheduler or Queue processor.

• Open the application rule that has the ruleset context in which the Job scheduler and Queue processor is created.
• On the Definition tab, in the Advanced section, select the Include in the background processing checkbox.

• To ensure that the application was added to the System Runtime Context, perform the following steps: 
  • Select Configure > System > General > System Runtime Context.
  •  Verify that the application appears in the Applications list.
  • Clicking on Resolved rulesets button displays the list of rulesets available for rule resolution.

Analyzing and Debugging Requestors

Now that we have discussed about requestor types, let’s see how we can view the list of requestors in an environment and how to debug them in case of issues.

Starting from v 8, SMA is totally replaced with the Admin studio in Pega. So it’s required to have pxAdminStudio as a secondary portal in your access group to get access to the admin studio and explore more.

View the list of requestors in system

• The requestor information can be found under Resources-> Requestors in the Admin studio. This landing page shows the list of requestors in the environment irrespective of the requestor types.

Analyze Clipboard size of a requestor

• We can examine the clipboard size of requestors from the admin studio using the below option. Clipboard size can be seen only when examining the requestors of a particular node.

View Clipboard of a requestor

• We can view the clipboard data of a requestor using the admin studio. The requestor can be own or remote.

• Analyze clipboard option gives you an detailed view of the memory consumption of each requestor in node.

Trace a requestor session

• We can trace a requestor session when we know the operator ID or the Requestor ID of the session that we want to trace.
• There can be a scenario where we have multiple requestors for the same Operator. Few examples are, mash-up with a common model operator, the same operator using a different browser to login, etc. So it’s always good to start a trace with requestor ID.
• We can use the below approach to get the requestor id of a session in the easiest way.

We hope you are now clear on how a requestor session gets created using a requestor type and basic debugging of requestors in Pega using the admin studio.

Stay tuned for our next post on Job Scheduler😊