Agent and Agent Schedule in Pega

Introduction

In this post we will see in details about Agent and Agent Schedule in Pega.

Most of the applications rely on processes that operate at the background without human intervention.

Imagine there is a requirement to send a status report to the reporting manager every day by 8 p.m.

You can code it like ‘providing a button and by clicking on that, we send an email containing the status report’. But if you do like this people will laugh at you.

Here comes the Internal background process to provide solution for this requirement.

In Pega platform, ‘Agent’ rule serves as an Internal background process.

To know about requestor type involved in batch processing, please visit my post below.

http://myknowpega.com/2017/05/13/requestor-types/

Agent and Agent schedule in pega, both belongs to background processing

What is an Agent rule?

  • An agent is an internal background process operating in the server on a periodic basis.
  • Each agent rule can contain individual agent activities for different processes.
  • Agents come under SysAdmin category and each ruleset can contain only one Agent rule.

How to configure an Agent rule?

Agent rule don’t belong to any class.

In the Agent rule form, we have three main tabs.

  1. Schedule
  2. Security
  3. Nodes

Schedule tab:

a) Scheduled agents

In the scheduled agents, you can add ‘n’ number of activities.

Agent Name – Provides the name of the agent (Appropriate description).

Pattern          – Periodic/Recurring/Startup.

  • Periodic scenario: Imagine you need to update a work item every one hour. In the interval field, you specify the seconds as 3600.
  • Recurring scenario: You need to send mail daily at 1 pm. Use Interval field advanced option, to set the time daily to 1 pm.
  • Startup: Only when the server starts ( not used often).

Mode           – Standard / Advanced (We will have deep explanation below).

Category    – Not a required field. Use it for recording purpose.

Enable        – True/False. We can enable or disable the agent.

Class           – Class of the Agent activity rule.

Activity Name – Agent activity name.

Params – Activity parameters.

Max Records – Shows how many records the agent should process before going to sleep. Usually applicable  for standard agents.

Auto Queue Management – True/False.

What is Auto Queue Management (AQM)?

This is applicable only for standard agents.

Imagine a scenario where you need to update a work item in the background based on SLA.

The agent activity tries to acquire the lock for the work item, but is already locked by other agent. Now basically the agent activity cannot update the work item (fails). In this scenario, if

  • AQM is checked, then the agent re-queue the item for later processing.
  • If not checked, then the agent gets only one chance to process it and do not persist the queue item.

Agent wide settings

Enable this agent – True / False. Enable the Overall agent rule.

Interval – Default interval seconds. Used when if we don’t provide the Interval for Individual agent activity configurations.

Note: these configurations can be updated in agent & agent schedule

Security tab:

Access Group – Applicable only for Advanced agents. Used to identify the agent activity rule.

Access group -> Application -> Builds ruleset list -> Agent activity rule.

Bypass Authentication –  True / False – Agent activities may be configured to use authentication (Activity security tab). You can bypass those authentication by selecting true.

Nodes Tab:

We know Pega system can run on different nodes using different servers.

This tab lists the nodes, where the agent schedules are created. We will discuss about Agent schedule later in this post.

How a standard agent works?

Requirement: Route the Leave request case to manager queue for approval.

  • If the manager didn’t approve the next day, the send an Email to him.
  • Even after 3 days if he didn’t approve, then Auto-approve the request.

This requirement can be achieved using SLA on the assignment shape of manager queue.

As part of development, we just configure an SLA and don’t mind how the background SLA works.

I am going to take you to a trip and  explain in detail how the background SLA process works.

SLA process:

To know the basic of SLA, please visit my exclusive post on Service level agreement.

http://myknowpega.com/2017/05/17/service-level-agreement/

Front end:

  • When the Leave request case reaches the assignment shape Assign-.AddAssign gets called.

  • This activity queues an entry with Event as “goal” to agent “Pega-ProCom:ServiceLevelEvents”.
  • Expand 2nd & 3rd step to get the details.
  • Now the Goal event (1 day) is queued to standard agent.

Back end:

  • Agent – Pega-ProCom

  • System-Queue-ServiceLevel.EstablishContext is responsible for Open & lock the assignment and Switching the access group. (AQM functionality)
  • Process Event – SLA agent activity.

a) When the manager didn’t approve the next day

The agent activity runs and starts processing the queued Goal event. Use activity ExecuteSLA to set the Urgencies and execute the escalation activities. It Re-queues the entry again for Deadline event.

b) When the Manager didn’t approve for the third day

The agent activity runs and starts processing the queued Deadline event. Use ExecuteSLA to set the Urgencies and execute the escalation activities. Here no passed deadline, so no more queue entries are added again. Leave is auto approved after deadline.

Go through the activities ProcessEvent & EstablishContext in System-Queue-ServiceLevel class.

How an Advanced agent works?

Advanced agent do not automatically use the Auto Queue Management (AQM).

All the transaction items need to be carried out in agent activity. We can configure the activity to re-queue if some error occurs.

Key differences between Standard agent and advanced agent:

  1. Standard agent uses the access group of the user who queues the entry, while the advanced agent uses the access group specified in Agent rule or requestor type.
  2. Standard agent supports AQM, while advanced agent do not.
  3. Standard agent wake and run only when there are queue entries with available lock, while the advanced agent runs even if there are no queue entries. This is because advance agent is responsible for agent queue processing.

Issues you may face in advanced Agent:

Imagine the same scenario discussed above. You need to configure an agent to update a work item. Now you configured the agent as Advanced agent and made it available in 3 nodes. Here, Object contention occurs, since advanced agent activity should handle the locks. If the same is configured using Standard agent, then there won’t be any locking issue.

“Prefer using standard agent over advanced agent”.

What is Agent Schedule?

  • Here you can see the relation between agent and agent schedule in pega.
  • As we discussed before Agents can run in multi nodes.
  • Imagine a scenario where you need to update agent run Interval from 300 seconds to 30 seconds in particular node. To solve this Agent schedule comes in Handy.

  • Agent schedule is a data instance and can be updated in any environment.
  • Here Pattern, Interval, Enabled, Access group etc., are editable and can be updated for a particular node.
  • You can check the node ID in the ID header field.
  • The changes reflect immediately once updated and saved.

How to create Agent schedule?

There is no need to create the agent schedule manually. There is an OOTB Master agent which monitors the Agent rules. If there is any new agent rules or if there is any update the Master agent generates, then the appropriate agent is scheduled. This is the relation between agent and agent schedule in Pega 🙂

How to debug an agent?

Use SMA.

  • In the Agent management, you can check if the agent is running or not. If there is some error and the agent has stopped, then you can see the stack trace or log files.

  • Tracing the Requestor.

We may be aware of a mantra,

Stop -> start -> Delay -> go the requestor management and trace.

Have you ever wondered, why you do this?

Explanation:

  • As per my previous post, I mentioned Agents use batch requestor type.
  • Requestors will be assigned to agent activities, only when it runs. When agent runs, it requests a batch requestor.
  • So when you stop and start the agent, a new batch requestor (B) is assigned. You will delay and trace that requestor from requestor management page.

Hope you get the basics about agent and agent schedule in Pega

32 thoughts on “Agent and Agent Schedule in Pega

  1. Great read. One question- In multi node environment as the agent schedule instances are automatically how would agent activity run, would it run multiple times? What considerations have to be taken to avoid such contingencies.

    1. Hi Dhanu,
      Good question.😊. Imagining you know the basics of multinode.
      In production we may have multinodes.

      Standard agent – we have AQM functionality right. It handles all the resource allocation. Say agents are available in 2 nodes. When agent in node A picks the queue item, it changes the status and starts processing. The agent in node B will never process the request. Don’t worry.. Pega handles it very well 😊.

      Legacy, advanced, standard with no AQM – we need to handle the browsing logic to pick the items.

      But.. but.. normally we use a single dedicated node for all the batch processing in Production environment. That is the recommended approach. So cool.

      You can restrict to particular node either through agent schedule or some command line scripts.
      Hope you are clear now😊

  2. HI Prem,

    Typically Agents are traced by SMA with stop –> start–> Delay approch. But case is here the configured agent will be run within 2 or 3 sec. How can you trace agent in this case

    1. 2 sec Agent. Omg 😀 . Bro you can increase the time frequency in the agent schedule. then Stop -> Start -> Delay

    1. Hi Saleem,
      Tracer is available in 2 places. Designer studio and SMA.

      If SMA is down we have a single option. We don’t know the requestor ID the agent use to process.

      In dev environment, you can manually run and test the agent activity.

  3. Hi Prem,

    This is my first post in your bog after going through the Agents topic,its really great stuff you put .

    Can you explain me how we an configure SMA in personal edition
    (how to get Node Id details).

    Can u provide me real time example for split join ,sin off smart shapes with a example .

    Please keeping sharing more post on pega topics.

    1. Hi Krishna,
      Thanks for the positive feedback.
      you can use Designer studio – > System -> General to find the node details. Please check in PDN to get those setup details.
      Exactly I am preparing my next post on Split Join, Split for Each, spin off scenarios 🙂

  4. Hi Prem,

    I read an article in PDN >>> https://pdn.pega.com/access-groups-agents#bckttp. (Please see Access groups on the Batch requestor record. Unable to paste the content here)
    My query is If we add “Access grop A” on Batch requestor record, and we added “Access group B” on our Agent rule.

    Which access group will be picked at run time to form the application stack.

    Thank You.

    1. Hi Sai,
      For advanced agents, when the access group is not specified in the agent rule then the access group specified in the batch requestor comes effective 🙂

      The order of priority for access group is agent rule followed by batch requestors.

  5. Hi Prem,
    I have few questions on agents
    1. How Can we re queue an agent activity if it has errors?
    2. If server was down how can we know that we missed the agent execution and what can be done later to process the last run again?
    3. Agent Interval wake up time is 30 (correct me if im wrong) , what is the minimum interval time we can give ?

    1. 1. For standard agent, re-queuing occurs automatically when AQM is selected. Rarely, you can also use queue-for-agent to re-queue the entry, but its nor required since AQM can handles it.
      2. in production, this scenario is very rare. say you configured an agent to run 11 PM and the server was down that time. here the agent run will be missed. We can use some log message in the agent activity to identify if agent failed to run. I am not sure about the solution to run again. may be we can update the agent schedule !! :(. Can someone share their views
      3. The minimum default interval will be 5 seconds

  6. Hi Premier,
    1. If server is down during agent invocation time how we will know the details about the agent last run failure? How to requeue the last failure run?
    2. What is the min interval time we can give for agent run? it is 5sec (correct me if I’m wrong) can we give less than that?

    1. 1. In production, this scenario is very rare. say you configured an agent to run 11 PM and the server was down that time. here the agent run will be missed. We can use some log message in the agent activity to identify if agent failed to run. I am not sure about the solution to run again. may be we can update the agent schedule !! :(. Can someone share their views
      3. The default interval will be 5 seconds. there is no restriction. You can give less than 5 seconds 🙂

    2. Hi Siva ,
      1.Usually in production environment there will be atleast two servers with a minimum of 2clones each . So if there is any server issues like hung threads ,high garbage. Utilization and if any clone stops loading alerts will be triggered and necessary action like recycle of was server clone will be performed and mean while whole work load is shared remaining clones .
      2. Also there are scenarios in which some agents are scheduled to run only in one clone of server and off in other clones. If due to issues clone / server is down then agents won’t run and it will be directly impact to business ,business comes with a ticket ,also the scheduled work of agent won’t be done and in logs we can get timestamp of interval when the agent was started and last run time as well . So there will be a backup like agent run in atleast 2 clones.

    1. One agent in multiple nodes.
      We know that nodes share the common database and rule instances. So when you create a new agent rule, agent will be available in all nodes by default. You can make use of agent schedule to conditionally run the agent on selected nodes

      Single node multiple agents.
      You can configure agent rule per ruleset. Each agent can contain multiple agent activities. You can configure any activity as you wish 🙂

  7. Hi prem,
    Could you please explain how AQM can be leveraged to Advanced agents, as pega provides the AQM option for Advanced agents as well…

    1. Hi Kumar,
      Though AQM option is visible in the advanced agents, it is of no use. AQM functionality is applicable only for standard agents

  8. Hi Prem,

    There was some uncategorized category right?

    where it is now we are not able to see it.

    can you post it once again under some category.

    Thanks
    Rupesh M

  9. Hi Prem,

    Good post.!! Please keep up the good work.
    We also see AQM check box in Advanced agent type as well in agent rule. On checking the check box, will it behave same as Standard AQM check box.?

  10. Hi prem ,
    I am getting very useful information in u r blog . Can u please post the topic on Single Sign on concept and some information on data table . if the SMA was down where we can trace this SSO etc information some more detailed .

    It really help ful for me

    1. Hi Sameer,

      Glad to hear that you are finding my blog useful. I’ve taken note of that topic, Sameer. I’ll post about it soon. 🙂
      Stay tuned. 🙂

  11. Hi Prem,

    What could be the possible reason that my agent activity is working explicitly when run manually, while from the agent it is not?

    1. Hi sanal, can you provide more details.
      1. Is it a standard or advanced agent.
      2. Did you check SMA, if its running or not.
      3. Check if require authentication us checked it not in agent rule and agent activity rule.

Leave a Reply

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