Access groups for agents
Some agents may need additional access privileges in order to accomplish their processing; this means that you must set up Access Groups for those agents.
The three agents that are shipped do not require any additional access, if they are used without any changes. However, if you change the Pega- Agent activities or resave these agents into other RuleSets, you must configure one or more Access Groups for these agents.
Important: Access groups are only needed for Legacy or Advanced mode agents, or agents defined prior to Version 5.4.
Quick Links:
Adding Access Group information – prior to V5.4
Access groups on the BATCH requestor record
Adding Access Group information – Version 5.4 and later
Legacy/Advanced mode agents in unlocked RuleSets
Legacy/Advanced mode agents in locked RuleSets
Access groups on the BATCH requestor record
Suggested Approach
When users log in, the login process uses their access group to set up a RuleSet list in each user’s profile, to be used for that user’s rule resolution. Agents do not “log in” as users do. However, when an agent runs, each agent activity is run in its own requestor, and thus requires a list of RuleSets to be defined so a RuleSet List is available to use for rule resolution (done as a part of processing the agent activities).
Agents require access to all RuleSets in the application that have rules which are invoked by the agent activities. This required access may include not only the agent activities themselves, but any activities or other rules (Whens, models, etc.) called by the agent activities. These RuleSets must be included in the agent’s Access Group, so that the agent may correctly complete its processing.
Therefore, depending upon the task it needs to perform, an agent’s Access Group must give it access to:
- any rules it needs to run the agent activity (including other activities, Whens, models, etc.)
- whatever roles and privileges are needed to do its business processing (send email, update a work item)
- whatever roles and privileges are needed to update the queue entry in the agent queue
Adding Access Group Information - prior to V5.4
In versions prior to V5.4, you must create an access group for any agent which needs access outside the RuleSet in which it was defined.
Agents in unlocked RuleSets
Agents which are defined in an application RuleSet may have access to all the activities, etc. that they require. If you create an agent which accesses some functionality not in the agent’s RuleSet or prerequisites of the agent’s RuleSet, you must define an access group which includes both RuleSets (the agent’s RuleSet, and the RuleSet where the additional functionality is), and include that access group on the agent rule form.
Enter that access group name in the agent rule, in the Access Group field on the Schedule tab:
Agents in locked RuleSets
For the Agents rules in locked RuleSets (such as those shipped), it is not possible to add an Access Group in the Agents form. For these agents, the access group information must be added to the Agent Schedule (Data-Agent-Queue) form associated with each agents rule, in the Access Group field on the Schedule tab.
Access Groups on the BATCH Requestor Record
When you change an agent activity and have to add Access Group information for agents in locked RuleSets, you could add it to the appropriate Agent Schedule record for each node of the system (as explained above). That can be hard to track, though, if there are many nodes, or if nodes are continually being added or removed.
To prevent contention and wasting resources, you will disable most agents on all but one node of a multi-node system (see Running Agents in a Multi-Node System). Thus, for most agents, you wouldn’t have to worry about nodes being added or removed. However, some agents, such as the Pega-ProCom agent, are be designed to run in a multi-node environment. For those agents, you may want to add access group information at the Requestor level.
All processes are run as “requestors” on the server, whether they are user sessions or Agents. The Data-Admin-Requestor class holds four instances:
- APP
- BATCH
- BROWSER
- PORTAL
Agents use the BATCH requestor type, which contains access to the standard Pega-ProCom RuleSet.
If you only want one Agents access group, create the access group with all the RuleSets required for all agents. Then, instead of having to enter this access group into all the Agents rules, enter it into the requestor BATCH record. This access group will then be used for all agents in the system.
Adding Access Group Information - Version 5.4 and later
In Version 5.4, for Standard-mode agents, each queue entry will be processed in the authorization context of the user whose processing (work object, assignment, etc.) generated that entry. Therefore, no additional access groups are needed.
Legacy/Advanced mode agents in unlocked RuleSets
As with releases prior to Version 5.4, agents which are defined in an application RuleSet may have access to all the activities, etc. that they require. If you create an agent which accesses some functionality in a RuleSet not in the prerequisites of the agent’s RuleSet, you must define an access group which includes both RuleSets, and include it on the agent ruleform.
Enter that access group name in the agent rule, in the Access Group field on the Security tab:
Legacy/Advanced mode agents in locked RuleSets
All but one of the agents shipped with Process Commander Version 5.4 are Legacy-mode agents. Therefore, if any changes are required to these agents, you must add access group information.
As with Process Commander releases prior to Version 5.4, it is not possible to add an Access Group in the Agents form, as the Process Commander RuleSets are locked. The access group information must be added to the Agent Schedule (Data-Agent-Queue) form associated with each agents rule, in the Access Group field on the Security tab.
Access Groups on the BATCH Requestor Record
In Version 5.4, the SLA and BulkProcessing agents (in Pega-ProCom) are both designed to preserve the user’s work object context (just like Standard-mode agents). Therefore, the access group on the BATCH requestor is no longer required – unless you have created agents in your application which are designed to run on multi-node systems. In that case, you may wish to set up an access group for that agent on the BATCH requestor.
Remember that if youset up an access group on the BATCH requestor, it affects all agents.