This content has been archived.

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

            Agents in unlocked RuleSets

            Agents in locked RuleSets

            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.

Top of Page

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:

zzz

Top of Page

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.

zzz

Top of Page

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. 

zzz

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.

Top of Page

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.

Top of Page

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:

zzz

Top of Page

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.

 

zzz

Top of Page

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.

Top of Page

Suggest Edit

100% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.