More about Requestor Type data instances
Requestors may be unauthenticated, known as guest users, or authenticated.
Requestor types and the system name
The system name (from a Data-Admin-System instance) is a key part of each requestor type instance. You can choose a system name during installation, and you can change it later. A landing page tab assists in changing the system name. Select . See System category — Setting landing page.Spawning multiple background requestors
ABATCH
requestor — for example an agent or service — can achieve a degree of parallel processing by
starting a second requestor through a Java step similar to the following PublicAPI call:
tools.getRequestor().queueBatchActivity("<Applies To class>", " <activity-name>", tools.getParameterPage());
The requestor can send parameters to the called activity on the current activity's parameter page. The second requestor session has the same access group as the current requestor session. It executes the activity and terminates.
The combined throughput of both requestors depends on available JVM memory, processor, and other demands on the system.
CAUTION:
Use care to avoid locking, contention, and deadlocks when
using this facility,
Capabilities provided by the BROWSER requestor type
Guest users — unauthenticated requestors — typically have access to rules in the RuleSets provided in the PRPC:Unauthenticated access group, as referenced in the Requestor type instance named pega.BROWSER.CAUTION:
If you update the
BROWSER requestor type to reference a different access group, or update
the PRPC:Unauthenticated access group to make additional rulesets
available to unauthenticated users, review carefully the Require authentication
to run check box on the Security tab of each activity in the RuleSets. Select
this check box for all but those specific activities that guests need to run.