Question
Virtusa Corporation
US
Last activity: 17 Feb 2017 2:30 EST
Agent Exception
When there is an agent exception, the corresponding data agent schedule instance is automatically getting unchecked and the same value will get updated in PR_INDEX_DATA_AGENTS. Can you any one advice , if this update process is handled through PEGA layer , Since when I am writing declare rules on these classes, the rule is getting triggered only when directly update the data agent schedule instance through pega front end. During the agent exception when it gets updated, the declare rules are not getting triggered. Can you advice the process which is happening behind the scene when agents stopped with exception.
***Updated by Moderator: Marissa to update categories***
Areteans Technology Solutions
AU
Virtusa Corporation
US
Thanks for the reply ratan. But the issue is the declared rule is not getting triggered during the agent exception irrespective of fire in save or committed save or even other options available in Declare Trigger rule.
Areteans Technology Solutions
AU
Virtusa Corporation
US
Class: DATA-AGENT-QUEUE.
We have more agents running in multi node production environment. Whenever ther is an exception if agent gets disabled send notification to the team based certain condition from decision rules. Unfortunately we couldn’t not able handle this directly at the agent activity. Also we don’t use AES. So thinking to place the declare rules to trigger condition and send email when there is an exception.
Areteans Technology Solutions
AU
Hi UthayaKumar,
I appreciate your thought process. Having a trigger would definitely solve the issue. But did you also check the downside of this design? With respect to the Declare Trigger rule, the rule will fire for every save / Commited save of an instance of that class. This means that for every change of every available Agent schedule instance.
Assume you have 5 Agent schedule instance for each ruleset and you have 4 Ruleset in total and 4 nodes since you have mentioned Multi-Node environment.
This means that you will at any given point have 80 instances out of which say 30 are enabled. Each of these instances will undergo a commited save for every wake up and sleep.This means the trigger rule will get fired so many times thereby affecting the performance the agent schedule. Keep in mind that the agent schedule commits are supposed to be quick.
I would suggest you to maintain a HealthMonitorAgent who's primary job is to monitor the Health of other agents. Though this kinds sucks at the design level, this will not have any effect on the performance of all the agent schedule instances which are supposed to process business data / logics.
The HealthMonitor agent can have a shorter sleep time and provide a report on the status of the agents across the application through mail comm. You can also make use of the agentUtils() method in the publicAPI to make the reporting process.
Hi UthayaKumar,
I appreciate your thought process. Having a trigger would definitely solve the issue. But did you also check the downside of this design? With respect to the Declare Trigger rule, the rule will fire for every save / Commited save of an instance of that class. This means that for every change of every available Agent schedule instance.
Assume you have 5 Agent schedule instance for each ruleset and you have 4 Ruleset in total and 4 nodes since you have mentioned Multi-Node environment.
This means that you will at any given point have 80 instances out of which say 30 are enabled. Each of these instances will undergo a commited save for every wake up and sleep.This means the trigger rule will get fired so many times thereby affecting the performance the agent schedule. Keep in mind that the agent schedule commits are supposed to be quick.
I would suggest you to maintain a HealthMonitorAgent who's primary job is to monitor the Health of other agents. Though this kinds sucks at the design level, this will not have any effect on the performance of all the agent schedule instances which are supposed to process business data / logics.
The HealthMonitor agent can have a shorter sleep time and provide a report on the status of the agents across the application through mail comm. You can also make use of the agentUtils() method in the publicAPI to make the reporting process.
You can improvise from this level to allowing various Dev teams to subscribe to get reports on the health status of the agents of their choice.
Con:
1) If the HealthMonitorAgent gets into a RunEx, then you will fail to get the StatusReport.
Let us know if this helps
Regards,
Ratan Balaji.
Virtusa Corporation
US
Yup Ratan. Writing new agent is not suggested due to various reasons for us. Now the issue why the declare rule is not triggered. Meaning the agent exception process is not done through PEGA layer. So the declare rule is not getting executed?
Areteans Technology Solutions
AU
Hi,
If you are using a standard agent, you can make use of the System-Queue-DefaultEntry class instances and write a declare trigger on that class. This trigger will get fired every time there is a save on an instance of this class. In the when that is used in the trigger you can check a favorable condition based on which you can send out an email notification.
The other option would be to have an AES installed on the server which allows you to monitor and get notifications on various agents processes.
Hope this helps.
Virtusa Corporation
US
Yup Ratan. Writing new agent is not suggested due to various reasons for us. Now the issue why the declare rule is not triggered. Meaning the agent exception process is not done through PEGA layer. So the declare rule is not getting executed?