Requestor & Requestor Types in Pega

Requestor & Requestor Types in Pega

Summary:

This article discusses about the outline architecture of how Pega handles requestor creation in different circumstances.

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 (DataAdminSystem).

  • Each Pega environment will have two default systems that get created during the initial installation (pega, prpc).
System instances of our personal edition
  • 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.
In personal edition, the default active system is Pega

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? 🧐

Usage of BROWSER requestor type during initial login

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.

We have two system prpc and pega. But the currently active system is Pega and the highlighted requestor types will be used by the 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.

  • portlet is a Webbased 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.

Enabling a Harness rule to be portlet application compliant
Enabling a Section rule to be portlet application compliant. This option is available only when the Auto-Generated HTML box is selected.

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.

When we have this application structure, it’s not possible to create Job scheduler in both Claims and Customer Service applications since the ASYNCPROCESSOR requestor type can only point to one access group.

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.
Definition tab in Application rule
  • 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.
Landing Page->System->General->System,Nodes & Requestors -> System Runtime context

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.
Press F12 or inspect element in a Web Page and search for pxClientSession. Value shown for pxClientSession has our requestor ID.
With the Requestor id, we can filter the session and trace it easily.

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😊

OSP TEAM
Written by
OSP Editorial Team

Recent Jobs from our community

loading
View more Jobs on OSP Forum
Join the discussion

Feel free to post your questions here about this topic if any. We will definitely get back to you ASAP !!!
If you have any off-topic questions, Let's discuss at OSP Forum

22 comments
  • Hi Team,
    Can you please confirm if below understanding is correct.
    Agent Wakes up -> Creates BATCH Requester With Initial Context -> Uses the Access Group present in the Agent Schedule(Data Instance) as Context
    Job Scheduler Wakes Up -> Creates a ASYNCPROCESSOR Requestor with Inital Context -> Uses the Access Group configured in the Job Scheduler rule as Context

    We have Agent Schedule Data Instance with the access group details for Advanced Agents. But for Job scheduler we don’t have any data instances to look for Access Group, so we should directly check the Job Scheduler rule.
    So we are asked to configure ASYNCPROCESSOR requester type with access group that can find the Job Scheduler rule.

  • I’m using Pega version 8.0 so we don’t have System Run Time Context.

    System Run Time Context is considered as a Requester Type or under which category it will be displayed in records explorer

    • System Runtime Context is neither a requestor type nor a rule. It’s a configuration. It can be seen in v8.4 from Landing Page->System->General->System,Nodes & Requestors -> System Runtime context

  • Hi Team,

    The default Pega:Agents access group that is configured in BATCH Requestor doesn’t have access to Agent Schedule(Data-Admin-Agent) data instances. How is the BATCH Requestor with this Initial Context going to look into Agent Schedules without access.

    • If you closely examine, none of your agent schedule instances will be associated with a ruleset. Hence it becomes accessible by the BATCH requestor with default access group too.

      It is recommended not to create or update the agent schedule instance just to ensure that this normal process is not disturbed.

      • In that case, there is no need of any access group for BATCH Requestor right. BATCH Requestor alone without any accessgroup can handle finding the agent schedules right.

        Associated Rulesets are used only used to assit Application Packinging and migration right. There is no other significance for Associated Rulesets.

        Please correct me if i’m wrong

        Thanks in Advance

        • Your point is valid, but Pega has a reason to have the BATCH requestor type configuration.

          We can have an Advanced agent in an agent rule and can save the agent rule without mentioning any access group in the security tab. In such cases, the access group mentioned in the BATCH requestor type will be used for the actual agent processing.

          • Thank you for your quick reply
            Got it…is it the same for APP Reqeustors as well.
            If no access group in service package..it will pick the access group in APP requestor . Thats the main reason for having access group in APP requestors as well

          • Hi Team,

            As per my understanding, Access group we specify in the Batch Requestor type is used to rule resolve / identify which agent rule has to be picked at run time.

            where as standard agent activities execute under the context of Operator who queues the entries & Advanced agent activities execute under the context of access group specified under Security tab.

            In Latest version, AsyncProcessor / System Runtime Context are used to identify the Job scheduler or Queue processor at runtime. Access Group we specify inside each job scheduler is used to execute the corresponding agent activities.

            Correct me If I’m Wrong..

            Thanks

  • How do I know if a case was created using batch requestor?
    Is there a way we can find that out?
    I have a scenario :
    An assignment is completed using SLA rule.
    While SLA is performing the task I want to give it few permissions based on batch requestor which a normal operator wont get.
    How can I implement this feature?