Support Article
Standard Agent is not working
SA-10048
Summary
In a Agent rule a sample activity is configured which inserts data into database. When the selected agent mode is ADVANCED , it gets triggered and inserts the record in DB, however when agent mode is set as STANDARD, it does not work.
Steps to Reproduce
1. Create a Agents rule set.
2. Create an agent in the above ruleset which has one activity and insert one record into DB.
3. Select the agent as ADVANCED, it triggers and calls activity and inserts the record into DB.
4. Now change the agent as STANDARD. You can observe that it does not work.
Resolution
The explanation for this behaviour is as follows:
Agent can be of two nature, task driven or schedule driven.
Task Driven:- pick their work from a queue. The queue entries are generally created during the work item processing.
Schedule-driven agents, however, do not use queue entries but rather directly run an activity to perform their tasks.
Process Commander provides Two types of agent or agent modes: Standard or Advanced.
In Advanced mode, the agent activity is responsible for both transactional and business processing. The agent activity in Advanced mode still use the agent queue functionality; it just must do so explicitly. So, when an advanced agent “wakes up,” it runs its activity directly, and that activity may either call the agent queue and performs all the locking and other database operations, or just does processing without a queue.
The Standard mode is the default mode setting for agents created in PRPC. In this mode, the transactional processing is handled by PRPC itself and leverages the agent queue functionality.
Understand the processing of a Standard agent
For each agent which is marked Enabled in an Agent Schedule, the Agent Manager checks its Queue Mode. For Standard agents, Agent Manager wakes up the Agent Thread, and creates a brand new requestor which it associates to the agent Thread. It then checks the agent’s queue for entries. If there are no entries in the queue for this agent, the agent goes back to sleep for the specified interval without running the agent activity and then checks back.
If one or more entries are found in the queue though, the system retrieves, locks and opens the first queue entry.
The Authorization context information is extracted and used to switch the requestor security context. This is when the Standard agent gets the access group of the user which processing generated the queue entry.
The System calls the out-of-the-box “EstablishContext” activity to lock and load the related object referenced in the queue entry. We can override this activity in our application RuleSet to add any custom functionality needed before the agent activity executes.
Now that the system has found and locked the object on which the agent will work, the agent activity is called with the object as the primary page object.
The system runs the agent activity for each item in the queue until it reaches its “max Records” count.
For each entry, if the agent processing succeeds, then the Agent Manager commits all deferred operations to the database.
If the agent processing however throws an exception on any operations, then the Agent Manager does a rollback of all entries associated with that entry.
Depending on the AQM setting, the entry is kept on the queue or removed from the queue.
When the agent is done processing the entries, it goes to sleep for its interval period. When the interval has passed, the agent Thread wakes up and begins processing from Steps again.
Hence if you use Standard Agents you should always have queue item for processing or else agent will wake up and again go to sleep since no item for it to process.
More about Agents please refer to PDN : https://pdn.pega.com/system-operations/agents-0
Published June 12, 2015 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.