Job Scheduler

In Pega Platform, an Agent is a background process that can be scheduled to run at almost any time. Starting with Pega Platform version 8.1, however, the Job Scheduler and the Queue Processor replace Agents and improve background processing. More to the point, the Job Scheduler replaces Advanced Agents for recurring or scheduled tasks

As illustrated in the screenshot above, the main settings of a Job Scheduler instance are:

·       Enable job scheduler: you can use this toggle to disable or suspend the Job Scheduler instance as needed.

·       Associated with node types: As illustrated in the screenshot, the default setting is to run the Job Scheduler instance on nodes of type BackgroundProcessing. Alternatively, we can select all nodes regardless of their type, a different node type, or multiple node types. Refer to the section Node Classification below for more information on the different node types.

·       Runs on: By default, the Job Scheduler instance runs on all nodes in a cluster of the type

BackgroundProcessing. Alternatively, you can select to run the job on only one node in a cluster.

·       Schedule: As the name implies, this setting specifies when the Job Scheduler instance will run. By default, the Job Scheduler instance runs upon startup of the selected nodes. Alternatively, you can select to run the Job Scheduler instance multiple times a day, daily, weekly, monthly, or yearly. Refer to the section Schedule Options below for more information.

·       Context: As the name implies, this setting specifies the context when the Job Scheduler instance runs. You can select to use an access group as an example, which sets the security context when running the Job Scheduler instance.

·       Class: This setting specifies the class that contains the activity the Job Scheduler instance runs. Also, the Job Scheduler instance will be associated with this class

·       Activity: This setting specifies the Activity the Job Scheduler instance job runs.

Node Classification

Introduced in Pega Platform version 7.2.2, node classification is the process of separating nodes in a cluster, segregating them by purpose, and predefining their behavior. By configuring a Pega Platform node with a type, you dedicate this node to perform particular actions. For example, you can have a set of nodes dedicated to user requests, while other perform background processing to avoid performance issues for users.

In the context of the Job Scheduler, the node types include:

·       ADM: This type is specific to Pega Decision Strategy Manager (DSM) and it specifies that the node is assigned to the Adaptive Decision Manager (ADM) service.

·       BackgroundProcessing: This type specifies that the node is assigned to run background processes such as agents, listeners, job schedulers, and queue processors.

·       Batch: This type is specific to Pega Decision Strategy Manager (DSM) and specifies that the node is assigned to run DSM background processes.

·       BIX: This type specifies that the node is assigned to the Business Intelligence Exchange (BIX) service.

·       Custom1, Custom2, Custom3, Custom4, Custom5: This type specifies that the node is used for other purposes or to support further classification or separation of nodes in a cluster.

·       DDS: This type is specific to Pega Decision Strategy Manager (DSM) and it specifies that the node is assigned to the Decision Data Store (DDS) service.

·       RealTime: This type is specific to Pega Decision Strategy Manager (DSM) and it specifies that the node is assigned to run realtime processes such as processing user requests in the context of DSM.

·       RTDG: This type is specific to Pega Decision Strategy Manager (DSM) and it specifies that the node is assigned to the Real Time Data Grid (RTDG) service.

·       Search: This type specifies that the node is assigned to the Search service.

·       Stream: This type specifies that the node runs the Streaming service, which is required by Pega Decision Strategy Manager (DSM) and Pega Platform Queue Processors.

·       Universal: This type specifies that the node is assigned all node types (i.e., ADM, BackgroundProcessing, Batch, BIX, etc.).

·       WebUser: This type specifies that the node is dedicated to the user requests.

Note that it is possible to configure a node with multiple node types. For example, you could classify a node with both the types BackgroundProcessing and BIX to run not only agents, listeners, job schedulers, and queue processors, but also BIX jobs.

Schedule Options

As stated above, the Schedule options are Startup, Multiple times a day, Daily, Weekly, Monthly, and Yearly. Following are additional details about these options.

Startup

When selected, the Job Scheduler instance runs upon every startup of the selected node or nodes.

Multiple times a day

When selected, you have the option to run the Job Scheduler instance After every N minute(s) or After every N hour(s), where N is an integer that specifies the delay before starting the next run.

After every N minute(s)

When selected, the Job Scheduler instance runs as follows:

·       Immediately after creation,

·       Upon startup of the selected node or nodes, and

·       N minute(s) following the completion of the previous run.

After every N hour(s)

Similarly, when selected, the Job Scheduler instance runs as follows:

·       Immediately after creation,

·       Upon startup of the selected node or nodes, and

·       N hour(s) following the completion of the previous run.

Daily

When selected, you have the option to run the Job Scheduler instance Every N day(s) or Every weekday, where N is an integer that specifies the frequency in days. You must also specify the start time of the run, including the timezone.

Every N day(s)

When selected, the Job Scheduler instance runs as follows:

·       After creation: it will run at the specified start time if it is created before. Otherwise, it will run at the specified start time in N day(s).

·       Upon startup of the selected node or nodes: it will run at the specified start time if the node is started before. Otherwise, it will run at the specified start time in N day(s).

·       Every N day(s) after that and at the specified start time.

Every weekday

When selected, the Job Scheduler instance runs as follows:

·       After creation: it will run at the specified start time if 1) it is created before, and 2) it is created on a weekday. Otherwise, it will run at the specified start time on the next weekday.

·       Upon startup of the selected node or nodes: it will run at the specified start time if 1) the node is started before, and 2) it is started on a weekday. Otherwise, it will run at the specified start time on the next weekday.

·       Every weekday after that and at the specified start time.

Weekly

When selected, you have the options to run the Job Scheduler instance Every N week(s), where N is an integer that specifies the frequency in weeks. You must also specify 1) the days of the week to run the Job Scheduler instance and 2) the start time of the run, including the timezone.

More specifically, the Job Scheduler instance runs as follows:

·       After creation: it will run at the specified start time if 1) it is created before, and 2) it is created on one of the specified days. Otherwise, it will run at the specified start time on the next specified days, or in N week(s) on the specified days.

·       Upon startup of the selected node or nodes: it will run at the specified start time if 1) the node is started before, and 2) it is started on one of the specified days. Otherwise, it will run at the specified start time on the next specified days, or in N week(s) on the specified days.

·       Every N week(s) after that and 1) on the specified day(s) and 2) at the specified start time.

Monthly

When selected, you have the following options:

·       Day X of every N month(s), where X is the day of the month, and N is an integer that specifies the frequency in months (e.g., Day 1 of every 1 month, Day 15 of every 3 months).

·       The <qualifier> <day> of every N month(s), where:

·       <qualifier> is first, second, third, fourth, or last,

·       <day> is Day, weekday, weekend day, Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday, and

·       N is an integer that specifies the frequency in months.

You must also specify the start time of the run, including the timezone.

Day X of every N month(s)

When selected, the Job Scheduler instance runs as follows:

·       After creation: it will run at the specified start time if it is created 1) before the specified start time and

2) on or before the specified day of the month. Otherwise, it will run at the specified start time on the specified day of the month in N month(s).

·       Upon startup of the selected node or nodes: it will run at the specified start time if the node is started

1)  before the specified start time and 2) on or before the specified day of the month. Otherwise, it will run at the specified start time in N month(s).

·       Every N month(s) after that and 1) at the specified start time and 2) on the specified day of the month.

The <qualifier> <day> of every N month(s)

Similarly, when selected, the Job Scheduler instance runs as follows:

·       After creation: it will run at the specified start time if it is created 1) before the specified start time and

2)  on or before the specified day of the month (e.g., The first Monday of every 1 month, The last weekend day of every 3 months). Otherwise, it will run at the specified start time on the specified day of the month in N month(s).

·       Upon startup of the selected node or nodes: it will run at the specified start time if the node is started

1)  before the specified start time and 2) on or before the specified day of the month. Otherwise, it will run at the specified start time in N month(s).

·       Every N month(s) after that and 1) at the specified start time and 2) on the specified day of the month.

Yearly

When selected, you have the following options:

·       Every <month> <day>, which enables you to specify a specific month and day of the month (e.g., January 1, June 30).

·       The <qualifier> <day> of every <month>, where:

·       <qualifier> is first, second, third, fourth, or last,

·       <day> is Day, weekday, weekend day, Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday, and

·       <month> is January, February, March, etc.

You must also specify the start time of the run, including the timezone.

Every <month> <day>

When selected, the Job Scheduler instance runs as follows:

·       After creation: it will run at the specified start time if it is created 1) before the specified start time and

1)  on or before the specified date. Otherwise, it will run at the specified start time on the specified date.

·       Upon startup of the selected node or nodes: it will run at the specified start time if the node is started

1)  before the specified start time and 2) on or before the specified date. Otherwise, it will run at the specified start time on the specified date.

·       On the specified date after that and at the specified start time.

The <qualifier> <day> of every <month>

Similarly, when selected, the Job Scheduler instance runs as follows:

·       After creation: it will run at the specified start time if it is created 1) before the specified start time and

1)  on or before the specified day and month (e.g., The first Monday of every January, The last weekend day of June). Otherwise, it will run at the specified start time on the specified day and month.

·       Upon startup of the selected node or nodes: it will run at the specified start time if the node is started

1) before the specified start time and 2) on or before the specified day and month. Otherwise, it will run at the specified start time on the specified day and month.

·       On the specified day and month after that and at the specified start time.

Overview on Agent Rule

• • In Pega Agent is an Internal Background Process operating on the server.
  • Agent runs activities on a specific interval of time 
  • Each Ruleset contain only one agent rule 
  • Agents are autonomous and asynchronous: the activities they call run individually on their own schedules, and one activity does not have to finish before another one runs.
  • Agent rules are instances of the Rule-Agent-Queue class. They are part of the SysAdmin category.

Create and Work With Agent Rule

Schedule Tab

Agent Name   

       Agent name is unique within the list of agents in this agents rule. 

Pattern

Periodic — The agent runs the activity and then "sleeps" for the number of seconds entered in the Interval column.

Recurring — The agent runs the activity based on a specified calendar schedule (for example, every Monday at 5:00 P.M.).

Startup — The agent runs the activity once at startup based on a specified parameter.

Interval

If the pattern is Periodic then we can define the time interval (In sec) for the agent to Run .

If the pattern is Recurring then we have an option to run the agent in a recurring manner .

Daily /Weekly /Monthly /Weekly .

Mode

Generally we have 2 Mode.

Standard Mode and Advance Mode.

Legacy Mode - Specifies that this is an agent that was created in a version prior to PRPC Version 5.4 and has not yet been updated. This option is not available for agents created in PRPC Version 5.4 or later.

Standard Agent

• ·       Standard Agent always process the items from queue 
• ·       For Standard agent system will take care of locking and transaction mechanism.( System-Queue-.EstablishContext activity is responsible for open and lock queue item)
• ·       Standard Agent Supports AQM .

What is AQM  (Auto Queue Management)??

Why to check this(AQM) check box?

• ·       If  this check box is checked and queue item can't be processed  the system requeues the item and the agent can try again the next time it wakes up.
• ·       If this is not checked, then the agent gets only one chance to process it and do not persist the queue item.

Suppose we have a business scenario where we have to update a case using an agent and that case is locked by some requestor. Then accruing the lock to that case will fails . In this case AQM comes to picture .it will queue the same item again for later processing and to try the same after some time . provided pyMaxAttempts is not crossed .

What is this MaxAttempts ?

This property called pyMaxAttempts is set on queue page . This determines how many times the agent should try the failure attempts before going to broken queue .

What is the time gap to retry, or it will try immediately?

Trying immediately, after a fail attempt to accrue the lock does not sounds logical.

 So we have a property called pyMinimumAgeOfProcessing

This property determines the time interval after which the agent should do the next try .

The time is in Sec .

Advance Agent

In case of an advance agent the once the agent wakes up it will not check the queue rather it will directly run the agent activity.

Unlike standard agent the lock handle mechanism should be taken care in agent activity .

There is no AQM concept in case of Advance Agent .

Category

Just to identify the role where the agent belongs.

Enable  - Used to enable and disable an Agent 

Max record – Suppose we have 100 items in an queue , and we have specified max record as 30 , then in this case when the agent wakes up then it will process only 30 records before going to sleep .

Security Tab

In the security tab we can give the access group which is useful for an advance agent to identify agent activity rule based on rule resolution.

But it’s not mandatory field. So if it’s blank then it will take access group from Batch requestor.

In case of standard agent it will use the access group of the requestor who is queuing the item.

 Bypass activity authentication – If this check box is enabled then it will bypass all the security authentication used on activity 

Nodes

This tab is used to specify the node for the agent to run

We have to enable and disable this from an agent schedule

What is Agent Schedule ?

Agent schedule is a Data Instance which is generated by master agent for each node .

From the agent schedule we can choose whether to enable and disable an agent in particular node or to change the time interval for running .

How to Trace an Agent

We can trace the agent from SMA or from Agent Management (Available after 7.2.2).

Tracing an agent from Agent Management is very easy.

Just select the agent name and click on trace. Check the below screen shot

There is a trick to trace the agents from SMA .

1. From SMA Click on Agent Management à Agents
2. Select the agent
3. Click on Delay.
4. Click on Requestor Management
5. It will show the delayed agent ( keep refreshing if it’s not showing . generally it takes time to show )
6.  Select and Click on trace