What are the requestor types in Pega?

Introduction

In this post we will see the requestor types in Pega. Imagine you are logging into any application. As soon as you log in, the data for that session will be stored in either memory or database. So whatever activity you do in an application, is basically like playing with data.

It can store, remove and update data.

Now let us move to Pega. As soon as you access (login) Pega, a session object is created in memory. Each session has its associated temporary memory area in that server called Clipboard.

  • Clipboard is a collection of threads.
  • Thread is a collection of Pages.
  • Pages contain data in name value pairs.

Pega also determines which applications the user can access and build the ruleset list based on the applications. We will discuss about this in detail.

What is Requestor?

  • From the name, we can say that it can be any people or object which requests for a service.
  • Now imagine Pega platform and think who can be the requestor for the Pega Platform. It can be the developers, users, other applications etc.,.
  • There are four requestor types in Pega.
  1. Browser (H)
  2. Batch (B)
  3. Application (A)
  4. Portal (P)

Designer studio -> System -> General -> Systems, Nodes & Requestors

You can see all requestor types repeating twice for both systems – pega & prpc.

If you see, my current system name is ‘pega’ and the other 4 requestors under ‘prpc’ are reserved for special situations.

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

  • As soon as Pega platform is installed, 4 requestor types of system name gets created.
  • In addition, 4 requestor types of system prpc is created.

No need to manually create Requestor type.

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.

How Pega determines the application the Browser requestor belongs?

1. If Operator ID is available for the requestor.

Operator ID -> Access Group -> Application

2. If Operator ID is not available (at login page / Agent).

Requestor Type -> Access Group -> Application

Here we are not able to determine the Operator ID or access group from the login page.

So Pega uses the Browser requestor type to determine the Access group and application and locates the authentication rules.

  • Every browser requestor starts with ‘H’ and must belong to a Pega application.

2) What is Batch Requestor Type?

  • Typically internal background process (Agents) comes under Batch requestors.

How Pega determines the application the Agent requestor belongs?

Let’s start with basics. There are two types of Agent.

  1. Standard
  2. Advanced

Note: To know about standard and advanced agent please check in my below post.

http://myknowpega.com/2017/05/13/agent-agent-schedule/

In the Agent Rule, we configure the Access group in security tab.

For Standard agent:

Standard agent completely ignores this field. It uses the access group of the Operator, which queues an entry to the Standard agent.

For Advanced agent:

a) Pega use 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 browser requestor type to determine the application and locate the agent activity rule.

  • Every batch requestor starts with ‘B’.

3) What is Application Requestor Type?

  • Typically for Listeners and external application service, requests come under application requestor type.

How Pega determines the application the Application requestor belongs?

Let’s discuss about Listeners and services that external application uses.

Both the Listeners and Services are included under Service Package.

Pega use the access group specified in the Service package to determine the application and locate the service rule.

  • Every App requestor starts with ‘A’.

4) What is Portal  Requestor Type?

  • For HTTP access as a portlet in conjunction with Service Portlet rules.
  • Pega use the access group specified in the Portlet Service package to determine the application.
  • Every Portal requestor starts with ‘P’.

 

How to debug various requestors types in Pega?

There are three ways to trace/ debug Requestors.

1. SMA (System Management Application)

We can perform various functions like trace, Clipboard analysis, performance analysis from the landing page.

Designer Studio -> System -> Operations -> SMA -> Requestor Management

Browser Requestors

Batch Requestors

Here use, SMA -> Agent Management, to determine the requestor ID for each agent rule.

App Requestors

The highlighted in red colour, indicates the service package the file listener belongs.

2. Remote Tracer

Using tracer -> Remote tracer, we can trace various browser sessions.

3. Clipboard

Clipboard -> System Pages -> pxRequestor

You will find all the details regarding the requestor.

Hope you are clear with the available four requestor types in Pega 🙂

31 thoughts on “What are the requestor types in Pega?

  1. Great read. One question- How are reqestor instances created..is it some kind of pool similar to number of connection pools in jdbc terms? Are requestor instances reused for service calls or are they created fresh every time.

    1. Yes service requestors use connection pooling. You can check out the Service package data instance, pooling tab. You will specify the limit for idle requestors, active requestors.

      Are you clear bro.😊

  2. How do we know when an external application sends a request, it is an application requestor – where does the invocation process starts – any configuration needed?

    1. Hi Ashok,
      I think you are bit confused. See first of all we need some requestor to run any rules in Pega.

      Requestor -> Access group -> Application -> Application rules.

      When external application requests a service from pega, we need to run some service activities to process the request right.
      Service activities will be configured in Integration services ( REST, SOAP etc),
      Integration services are included in service packages.
      We configure Access groups, requestor Pools in service package.

      See We Log in pega and process any work.
      Similarly, Services need a requestor to process the request. Pega named it as application requestor.

      The only configuration you can do in Pega rule form is in service package requestor pooling.
      Some administration configurations are there and those are beyond the scope of this post 🙂

    2. When a external application sends a request to pega, External App uses an URL to connect – But how does the system knows that it is a app requestor to begin with? – I am trying to get understanding on the core functionality on how this app requestor is created in first place.. 🙂

  3. Can we trace the live service calls ? How to trace it out one particular request when plenty of requests comes at same time.?

    Is there any pattern to identify the each service requestors?

    Just curious to know !! .Despite of system providing other debug mechanisms like logs the payloads XML/JSON and test it out each payload.

    1. Yes, Brahmesh. You can trace it in 2 ways with a restriction.

      If you have designer studio access, then you can trace open the service rule and wait for the service requestors to call the service rule.
      In SMA, you can go to requestor management and trace the particular requestor with required service package name. I tried it once. But the restriction is; you cannot identify which service requestor is processing which request 😉

  4. If two or more external application requests request a same service from our application (pega),
    1)could our application process the requests one by one because only one app requestor (as the requestor of type prpc useful in special situations) available to process the requests from external applications.
    or
    2)Only app requestor process all the requests simulataneously?

    Please correct me if I am wrong.

    1. Hi Sai,

      I think you are confused a bit. Just think the name ‘APP requestors’ is to identify a group of requestors involved in service processing.

      Requestor pooling configuration in service package data instance determines the no.of active requestors to process the requests.

      In your scenario, when multiple application requests simulatenously, we can use pooling tab in service package data instance to specify more than one active requestors. So that all requests can be processed parallel.

      Please go through the Service package post.
      http://myknowpega.com/2017/06/02/service-package-configuration-tutorial/

  5. Hi Prem,

    First of all thank you so much for sharing your knowledge.i have one doubt .
    when you hit the pege url browser request will be created, but how do it get know about which operator id or access group is called and where we can see it in operator id or access group

    1. Hi syamson,

      When you just hit the pega URL, you will be shown the landing page. So here only a new requestor is created. Only after you provide the Operator ID and password and click submit, Pega OOTB rules in Code-Security class run and determine the access group 🙂

  6. what does it mean in term Standard Agent- “It uses the access group of operator, which queue an entry to standard agent” ?? which user’s accessgroup will pick and how?

    1. Hi Bharat,

      It means standard agent makes use of the access group of the requestor who queues a record.

      For example, from user portal you run an activity and queue an entry to standard agent, then standard agent runs in your access group context.

      Go to App explorer -> select System-Queue-DefaultEntry -> Click on the class name to get the instances.
      Open an instance and see the XML content.
      You will see a property –pxAuthDetails holds the access group name and ruleset stack 🙂

    1. Hi Subbareddy,

      If you need to kill the requestor you logged in, you can use LogOff activity in Code-Security class.
      You can also try Requestor-Stop method in the activity rule.

      If you want to kill other requestors, you can use SMA and stop the requestors. ( I am not sure we have some API to control withing Pega!).
      Other comments are welcome

    1. Hi chhatrapal, actually portal requestors are used in Service-Portlet rules. I never used one 😉 . I am not aware of the exact usage

  7. Hi Prem,

    Got to know few new things by this post. you have mention there are 4 requestors under PRPC which are reserved for some special situation ..

    can you know in what situation these requestors are used.’

    Thanks
    Rupesh M

  8. Hi Prem ,
    Really its a great ful help for us for sharing the step by step scenarios of each and every topic . can u please share u r knowledge on single sign on (SSO) and localization concepts also . really it will be great help for us in this

    1. Hi Sameer,
      Thank you so much for your appreciation. 🙂
      Yeah, I’ll post about those topics soon. Since many people have asked for those topics, I’m working on that. I will post about them soon. Stay tuned. 🙂

  9. Thanks for sharing the detailed knowledge about Requestor. It was worth reading the post. Really thankful for such knowledge sharing 🙂

    1. You are most welcome, Nupur. 🙂
      Thank you so much for your heartfelt appreciation. Feeling really happy. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *