System settings for the Pega-ProCom SLA Agent
Summary
Service level rules (“SLAs”) are time limits on assignments, generally goal, deadline, and late intervals. When one of these time intervals is reached without the assignment being performed (or the work object being resolved), the system escalates this object to the defined next level - for example, sends it to a manager. The ProcessServiceLevelEvents agent (in the Pega-ProCom Agents rule) detects these goals and deadlines not met and performs escalation processing.
When one of the time intervals is reached, a task is automatically sent to the internal SLA queue for the SLA agent to handle. To tune your system to peak efficiency, you must determine how the SLA agent should process assignments, and adjust how many of these tasks the SLA agent processes each agent interval by using the SLA System Settings.
Quick links:
SLA System Setting Descriptions
Changing the SLA System Settings
Suggested Approach
System Settings (instances of Rule-Admin-System-Settings) are constants stored in rule instances. There are three System Settings for SLA processing:
- SLARefreshListEachIteration
- SLAUnitsToProcess
- SLAUnitsToRetrieve
By default, the SLA agent runs every 30 seconds to process assignments. You should tune the SLA processing to be as efficient as possible by adjusting the System Settings for this agent.
First, you need to determine:
- how many assignments should be processed in one agent interval
- how many assignments should be retrieved for one interval’s processing
These values will vary depending upon:
- how many nodes the system is running on (one single node, or multiple nodes – and is “multiple” 2 nodes, or 200?)
- how many work objects with SLAs are created each day
Multi-Node Processing
If Process Commander is running in a multi-node environment, and the SLA agents are configured to process a large number of assignments, there can be contention between different agents trying to process the same assignments.
Example of contention issue:
If the SLA agent on Node A retrieves 100 assignments to process, it may successfully process the first one or two. However, at that point, the Node B SLA agent wakes up and also retrieves 100 assignments, including many of the ones which the Node A agent is trying to process. Now when Node A tries to process the next assignment, it may discover that the assignment is locked by Node B for processing. If there are a number of different nodes, each with their own SLA agent, the contention between agents for assignments can waste resources.
Therefore, for multi-node systems, it is recommended that the number of assignments retrieved be much smaller, so that contention is reduced. If the Node A agent retrieves five assignments, and processes them without contention, that is much more efficient than retrieving 100 and having other agents block the attempt to process most of them.
Single Node Processing
If Process Commander is installed on a single node, then there is one set of agents running. Since there is only one node, there will be no agent contention among nodes. You can set the number of assignments to retrieve and to process to be large, as there will be no agent collisions; the number of assignments in the queue that are not selected for processing will simply be picked up in the next interval.
SLA System Setting Descriptions
Below is a summary table of the three SLA System Settings:
System Setting | Description | Default Value |
|---|---|---|
SLARefreshListEachIteration | If this setting is true, then each time an SLA agent successfully processes an assignment, it refreshes the retrieved item list (retrieves a new list of assignments). | false |
SLAUnitsToProcess | This setting controls the number of assigments the SLA agent processes during its interval. | 20 |
SLAUnitsToRetrieve | This setting specifies the number of assignments the SLA agent retrieves for processing. NOTE: There are three types of SLA events for assignments:
| 100 |
The setting SLARefreshEachInteration can be used to prevent additional inter-agent contention. If this setting is true, then each time an SLA agent successfully processes an assignment, it refreshes the retrieved item list. So for example, if the SLAUnitsToRetrieve is set to 3, and the SLAUnitsToProcess is set to 10, the system will retrieve 3 assignments and try to process one of them. The quantity of 3 to retrieve is chosen to give a good chance that at least one of the assignments won’t be locked by another agent or a user, and will be able to be processed. If only one assignment is retrieved, there could be some problem with it that prevents it from being processed, and the retrieval process would have to be done again, wasting resources.
After the agent has successfully processed one of the three assignments, it “refreshes” its list by going back to the full queue of assignments to retrieve another three. It is possible that if the very first assignment was processed, and no other agents have processed any assignments in the meantime, that the 2nd and 3rd assignments picked up in the first retrieve will be picked up again; however, it is much more likely that other agents from the other nodes in the system have run, so it will actually pick up completely new assignments. It processes one of these new three assignments successfully, and then refreshes again, following this procedure until it has successfully processed 10 assignments. At this point, it stops, and waits for the next agent interval.
The refreshing procedure means that the agent has more up-to-date information on the assignments to process. For example, the Node A agent may pick up assignments 1, 2, and 3. It successfully processes #1, and then refreshes. In the meantime, the Node B agent has also picked up assignments 1, 2, and 3. It can’t process #1 (as it is locked for processing by Node A), so it processes #2, and then refreshes. When Node A refreshes, it now picks up #3, #4, and #5, because Node B processed #2. This means that Node A doesn’t waste time trying to process #2, which was locked and then completed by Node B.
Changing the SLA System Settings
Before you begin
Before you change any of the System Settings, you need to determine the appropriate values for your particular application.
For a large enterprise system, the SLAUnitsToProcess and SLAUnitsToRetrieve should be set according to:
- the speed of the system
- the throughput of the system
- the number of nodes in the system
- the estimated number of assignments in the system at any one time, for each event type (goal/deadline/late)
Set the SLARefreshEachInteration as follows:
- true - for multi-node systems
- false - for single-node systems
Example: Determining SLAUnitsToProcess
There are 5 nodes in the system. You estimate that at any time, there may be 300 assignments which could potentially reach an SLA limit. These 300 will be broken down by type as follows:
- Goal – 50% (150)
- Deadline – 30% (90)
- Late – 20% (60)
The SLAUnitsToProcess might be set at 30 (the largest number of event types is 150, divided by the 5 nodes). To handle peak times, perhaps this setting value may be increased to 45.
Example: Determining SLAUnitsToRetrieve
As stated above, the number of assignments to request at one time (SLAUnitsToRetrieve) is dependent upon whether the agents are running in a multi-node system. More specifically, this value depends upon the setting for SLARefreshEachIteration. If this Refresh setting is false, then the assumption is you have a single-node system. In this situation, you can set SLAUnitsToRetrieve to be a very high number, as contention is not an issue; it is recommended that this value be set to approximately double the value of SLAUnitsToProcess (or a little less). You want to set the retrieval value to be somewhat higher than the process number, in case some of the entries can’t be processed (due to other locks on the work objects).
If the Refresh setting is true, then the assumption is you have a multi-node system. In that case, you should keep this number as low as possible, because the more results a query returns, the slower it performs. However, you want to be sure that enough assignments are retrieved so at least one can be processed by the SLA agent. It is recommended that you set this value to be equal to the number of nodes in the system, plus some small additional number (in case of locking). If there are 5 nodes, then having the agent on one node retrieve 7 or 8 assignments means that at least one assignment will be available to process (even if all the other nodes are currently processing assignments).
Version 5.3 and prior
In versions prior to Version 5.4, the SLA settings have a different structure than other settings, as they are present both as System Settings rules (which are locked), and as Dynamic System Settings (Data-Admin-System-Settings - which you may tune). Determine how the SLA agent should process assignments, and then adjust the Dynamic System Settings accordingly, as described above.
When present, the SLA Dynamic System Settings override the System Settings values. If the Dynamic System Settings are not present, the system reads the SLA System Settings instances, and then creates SLA Dynamic System Settings with those default values.
We recommend that you use the Dynamic System Settings to test changes during development, and then make your permanent changes in the System Settings rules when your application is ready for production.
To change the SLA System Settings rules:
1. Delete the three existing Dynamic System Settings for SLA.
2. Review your SLA agent usage, the speed and throughput of your system, and the number of work objects (with an SLA value to process) that are created in a day. Determine the value to set for SLAUnitsToProcess and SLAUnitsToRetrieve.
3. From Rules by Type, expand the SysAdmin link. Click on System Settings.
4. Open the SLAUnitsToProcess rule. Click Save As, and save this rule to your application RuleSet.
IMPORTANT: Make sure that your SLA agent has access to the application RuleSet where you save the System Settings. (Probably this will be the RuleSet where your work objects are defined, so the agent should already have access to this RuleSet, but verify this. See Access Groups for Agents for details.)
5. For each level, change the Value field to the value you determined in Step 2, and save your changes.
6. Repeat steps 4 and 5 for the SLAUnitsToRetrieve setting.
7. If you have a multi-node system, repeat steps 3 and 4 for the SLARefreshListEachIteration. For each level, change the value from false to true, and save your changes.
To change the SLA Dynamic System Settings:
1. Review your SLA agent usage, the speed and throughput of your system, and the number of work objects (with an SLA value to process) which are created in a day. Determine what value to set for SLAUnitsToProcess and SLAUnitsToRetrieve.
2. From Rules by Type, expand the SysAdmin link. Click on Dynamic System Settings.
3. Open the SLAUnitsToProcess instance.
4. Change the Value field to the value you determined in Step 1, and save your changes.
5. Repeat steps 3 and 4 for the SLAUnitsToRetrieve setting.
6. If you have a multi-node system, repeat steps 3 and 4 for the SLARefreshListEachIteration. Change the value from false to true, and save your changes.
Version 5.4
In Version 5.4, the SLA System Settings are configured through System Setting rules; the Dynamic System Settings are no longer used.
As with other rules, the System Settings rules shipped in the standard ProCom RuleSets are locked and cannot be changed. However, because they are rules, Rule Resolution will apply; if you need to change a value for the System Settings, you can save the System Setting rule to a higher-level RuleSet in the application and change its value. When the application is run, the rule in the higher-level RuleSet overrides the one in the locked Pega-ProCom RuleSet (as always).
To change the SLA System Settings, use the following procedure:
1. Review your SLA agent usage, the speed and throughput of your system, and the number of work objects (with an SLA value to process) which are created in a day. Determine what value to set for SLAUnitsToProcess and SLAUnitsToRetrieve.
2. From Rules by Type, expand the SysAdmin link. Click on System Settings.
3. Open the SLAUnitsToProcess rule. Click Save As, and save this rule to your application RuleSet.
IMPORTANT: Make sure that your SLA agent has access to the application RuleSet where you save the System Settings. (Probably this will be the RuleSet where your work objects are defined, so the agent should already have access to this RuleSet, but verify this. See Access Groups for Agents for details.)
4. For each level, change the Value field to the value you determined in Step 1, and save your changes.
5. Repeat steps 3 and 4 for the SLAUnitsToRetrieve setting.
6. If you have a multi-node system, repeat steps 3 and 4 for the SLARefreshListEachIteration. For each level, change the value from false to true, and save your changes.