Declare Pages

Declare Pages
A declare pages rule defines the contents of a clipboard page.

There are two types:

1.Read-only provides a read-only page available to only one Thread, to a
Requestor, or to multiple requestors (on one Node) in your application.

2.provides the initial contents of a page that, thereafter, can be accessed in

normal read-write mode.

Points to remember
1. Name of Declare Pages should start with Declare_
( From Pega 7 these pages were changed to Data Pages and Name should Start
With D_ )
2. These rules are present under Technical Category
3.we have three kind of Declare Pages
a. Thread Page
b. Node Page
c. Requestor Page
4. Thread Page: the scope thread page is with in the thread who created the page
Node Page: The Scope of Node page is within the operators who are associated with the
current Node.
Requestor Page: The scope of Requestor page is within the Operator who created the
Declare Page
Eg: To Store the WSDL URL's, Email ID's we can use These Declare Pages.

Agents in PRPC

Note: These Pages are not created at Login Time, rather these pages will get created when
these pages got accessed.
2 . the activity defined in declare page should be of type LoadDeclarative Page.
3.We Can remove the page by clicking on Flush Page in advanced tab.
4. We can also get the values to Declare pages from Dynamic system

settings.

5. The Activity type which we are calling from declare page should be LoaddeclarativePage.
6. We can refresh the page conditionally by defining the time interval.

Agents in PRPC
The Concept contd

V 5.4

Agents are created and stored in the Rule-Agent-Queue class.

This information is copied to Data-Agent-Queue to enable the SysAdmins to
edit some Agent settings if necessary.
For each Rule-Agent-Queue [per RuleSet], there will be one Data-Agent-Queue
instance created automatically by the System aka Agent Schedule instance;
SysAdmins can override the settings configured in the Rule-Agent-Queue in the
Data instance.
Each Agent Queue instance can hold more than one Agent Activity that gets
processed when the Agent is run.
If a new Agent Activity has to be added to the existing Queue, save the RuleAgent-Queue in a higher RuleSet Version. The existing Data-Agent-Queue
instance will be updated to cater to the change. The SysAdmins can further edit
the Agent settings as needed.
As a good practice, configure one Rule-Agent-Queue for all the Agent Activities
belonging to one RuleSet. This helps in managing / creating an Access Group for
these Agent Rules.

Agents in PRPC
Pega Internal Agents
PRPC has 3 internal agents defined:
PRPC includes three standard agent queue rules, that cannot modified. However, one
can affect the operation of these agents thorough the related data instances.

Pega-IntSvcs :

Supports communications with the Correspondence Output Server, enabling outgoing

correspondence to be printed, faxed, or converted from Word to PDF format.
Pega-ProCom :
Processes incoming e-mail, sends outgoing correspondence, and evaluates Service
Level Rules associated with Assignments. It escalates the assignments as
appropriate.
Pega-RULES :
Performs general system housecleaning and periodic system pulse processing required
for the engine.

Creation process of Agents

The process of creating Agents is as below:
Determine the process to be accomplished by the Agent Activity
Create the Agent Activity in the appropriate RuleSet.
Create the Rule-Agent-Queue instance in the appropriate RuleSet with the
already created Agent Activities specified in the Queue.
Create an Agent Access Group separately for the Agent & independent with the
other personal Access Groups in the Application.
Note:
Since Agents have system-wide functionality, they must be run on a
system-wide RuleSets, with system-wide Access Groups. It is not
possible
to run the Rule-Agent-Queue instance or Data-Agent-Queue instance from a
personal Rulesets or with personal Access Groups.

Agent Queue Rules

Agent Queue Rules are instances of Rule-Agent-Queue class.
An agent queue rule defines background processing by agents, including the trigger or
wake-up interval or schedule and the activities to execute.

Provide the relevant information in the Rule form like Class & Activity Names, Pattern
[Periodic or Recurring], Interval for which the agent sleeps before checking the queue
and the Enabled check-box to enable each agent. Also, the Agent wide settings, the
Enabled check-box to make the agent run whenever the system is running and Interval
in seconds.

Agent Scheduling & Management

Agent Schedule Rules are instances of Data-Agent-Queue class.
Agent Schedule data instances support operations of the agents, on the nodes of one
Process Commander system. You can update the data instances at any time to meet local
needs.

The System automatically creates this instance for each Agent Queue Rule. You can
modify the data later as necessary. You may not be able to modify the 3 standard Agent
Queue Rules as the RuleSets are locked. But the corresponding Data instances can be
modified to override the info.

Agent Scheduling & Management

The Pattern defined on the Agent Queue can be overridden in the Agent
Schedule.
Select Periodic and specify the time interval for which the Agent sleeps before
starting or restarting the Activity. The minimum interval is 5 seconds and the
default is 30 seconds.
When an Agent runs beyond the specified interval time, then after the task has
completed, it will wait for the specified interval and begin the task again. The
system will not start another duplicate task.
Select Recurring and click on the Advanced button to see a popup like below:
Provide a default start date & time [use the calendar for promoting] for setting
this activitys first run.
There are a number of
pattern types available:
Daily
Weekly
Monthly
Yearly

Agent Scheduling & Management

We can use the System Management Application [SMA] for Managing/
Monitoring the Agents through the Agent Management option defined for each
node.

Agent Management console enables us to perform the following actions on

each Agent or on all Agents in the Queue:
Start
Stop

Restart
isAlive

Query
Delay

Starts an Agent Activity

Stops an Agent Activity that is currently running; sets the Enabled
column to false and prints an exception in the Exception Info column.
Stops an Agent Activity and then restarts it.
shows whether the specified Agent Activity is enabled.
Displays the information on the selected Agent Activity.
Delays the next start of this activity for the Tracer startup. If a
developer wants to trace the execution of an Agent Activity, it can go
by too fast to enable the Tracer. This button will casue the Agent
Activity status to be set to waiting; once the Tracer is enabled, the
Start button may be pressed for that Activity to start its execution.

Agent Access Group

The standard PRPC Agents are setup to run automatically without the need of
any Access Group.
As all the processes in PRPC runs as requestors on the server, the Agents use
the BATCH requestor instance of Data-Admin-Requestor class.
BATCH instance has access to the below RuleSets in PRPC:
Pega-ProCom
Pega-WB
Pega-IntSvcs
Pega-RULES

All the user-created Agents must have an Access Group defined containing the
appropriate RuleSets with an appropriate name, viz., Agent_MyRuleSet.
The Agent Queue rule should be defined with this Access Group for the Agent
to run without any Rule Resolution issues.
When theres a change in the Agent Access Group, the server needs no restart,
instead these changes will be incorporated after the Master Agent
newqueuewakeup period.

Agents in AIGeXtra Application

AIGeXtra Application has around 12 different Agents besides the standard
PRPC Agents. Of which, 3 are non-renewals Agents and 9 are Renewals Agents
configured for Renewals countries.
The list of all the agent queues defined in Production as below:
#

Agent Queue
(# Agents)

Agent type

Purpose

AIU_EUR (11)

Front Desk Agent

Runs Application specific Agents for different

requirements like loading the Cache data, checking
for Quote Auto Expiry period, Automatic Bulk
Updates, etc.

AIUFOIS (3)

Front Desk Agent

BIS Connector Agent

AIUREPORT (2)

Front Desk Agent

Generate various MIS Reports

AIU_BE (9)

Renewals

Renewals Agent for Belgium

AIU_DE (12)

Renewals

Renewals Agent for Germany

AIU_DK (8)

Renewals

Renewals Agent for Denmark

AIU_FR (12)

Renewals

Renewals Agent for France

AIU_IT (12)

Renewals

Renewals Agent for Italy

AIU_LU (8)

Renewals

Renewals Agent for Luxembourg

10

AIU_NL (11)

Renewals

Renewals Agent for Netherlands

11

AIU_NO (8)

Renewals

Renewals Agent for Norway

12

AIU_SE (8)

Renewals

Renewals Agent for Sweden

Agents in AIGeXtra Application

Details of each Agent in the Agent Queue:
AIU_EUR

AIU-Core-eXtra-. ReminderEmail

Purpose: Sends the email for the workobjects with Is_reminder_required set to
true and reminder date is equal to current date and finally updates
Is_reminder_required to false after sending the mail in the extra_work table

AIU-Interface-RULESExt-. LoadRefData

[Daily - Weekdays]

Purpose: This activity will run once in a day to fetch the list of all submissions
which have a status New in Pega and the Quote Effective Date has past the
CurrentDate. The status of each submission from this list will be cross-verified to
that in estart and updated appropriately in Pega. The Lost or Void action will be
taken basis the estart status of the submission.

AIU-eXtra-Work-NB. DeleteSubmissions

[Daily - Weekdays]

Purpose: Loads the cache page with cache data like entire list of data in the page
list pxProcess.AIUDataCache()

AIU-Core-eXtra-. Cm_QuoteAutoExpiry

[Daily - Weekdays]

[Daily - Weekdays]

Purpose: This Activity deletes all the Assignments / Work Objects for which the
estart submission number is not generated.

Agents in AIGeXtra Application

AIU-Interface-RULESExt-. CheckCacheData

Purpose: This Activity checks if the Cache Data has been loaded in
AIUDataCache Page List, if not reloads it by running the LoadCacheData Activity.
Also runs the LoadRefData Activity.

AIU-Core-eXtra-. Cm_GetShellAccountList

[Daily - Weekdays]

Purpose: Used for Automatic Bulk Updates of some data in the Database.

Assign-. ProcessServiceLevelEvents [CheckSLA Agent]

[All Weekdays]

Purpose: This Activity generates Special reports for Belgium & Luxembourg
countries.

AIU-Core-eXtra-WorkMgmt. AutomaticBulkUpdate

[Weekly - Friday]

Purpose: Generates Weekly Renewal Reports for all the Renewal countries.

AIU-Report-Reconciliation-. GenerateReportsBELUX

[Weekly - Friday]

Purpose: Generates Weekly Reports for all the countries across products.

AIU-Report-Weekly. Rn_GenerateWeeklyReports

[Weekly - Sunday]

Purpose: This activity runs every night to check if the shell accounts have been
resolved. If yes, it sets the resolved D&B number in the work objects and makes a
getaccount call to estart for that resolved D&B number to get the client details.
These new details are then update in the workobjects.

AIU-Report-Weekly. GenerateWeeklyReports

[15552000 sec]

[Daily]

Purpose: This is an Agent for Checking SLAs from WorkList, WorkBasket,

External & Service class under Assign- class.

Agents in AIGeXtra Application

AIUFOIS

AIU-Interface-Fois-BISConnector. UpdateStatusNotBooked

Purpose: This Agent polls the BIS java application to fetch the latest booking
status from GOALD for the Booking Pending casefiles in AIGeXtra & updates the
Booking Tracker table with the booking details like BISStatus [Booked Awaiting
Docs / Booked / Booking Failed], Booked Date, WIP No. for each Booking ID.

AIU-Interface-Fois-BISConnector. BISALPSSynch

[3600 sec]

Purpose: This Agent picks up all those policies with Booking Type as Review with
WIP or Manual (Shell WIP) and are Booked in ALPs.

AIU-Interface-Fois-BISConnector. ResubmitRequest

[1800 sec]

[1800 sec]

Purpose: This agent picks up policies which are having status as Not Yet
Processed or Booking ID as 1, which means that BIS has not started processing
from the Queue.

Agents in AIGeXtra Application

AIUREPORT

AIU-Report-Operational. PerformDataExtract

Purpose: This Agent is created to provide information for generating Operational

Reports by EDSAT Data Ware Housing System by reading the data from PRPC
Database and inserting records into EDSAT staging table. Data flow can be view in
the picture below.

AIU-Report-Weekly. GenerateWBReports

[Weekly - Friday]

[Daily - Weekdays]

Purpose: This Agent generates daily report for all the countries for various
statuses of casefiles processed. This has been introduced recently as a
replacement of ExportToExcel functionality in WBM.

Agents in AIGeXtra Application

Renewal Agents
For Performance reasons, all Renewal Agents are configured to run between 10 PM & 6 AM
daily to ensure the bulk processing doesnt tell on the server during the regular business
hours. Below is an example of Renewal Agent configured for Belgium Renewals phase-1.
AIU_BE

AIU-Core-eXtra-. Rn_SetLeadProduct_BE

Purpose: This Agent is used for identifying and setting the Lead Product for
Certificate Level renewal policies.

AIU-Core-eXtra-. Rn_SetPolicyLeadProduct_BE

[300 sec]

Purpose: This is a Streaming Agent is used for identifying and Risk Stream/Policy
Track for Policy Level renewal policies.

AIU-Core-eXtra-. Rn_ReStreamPolicies_BE

[300 sec]

Purpose: This is a Streaming Agent is used for identifying and Risk Stream/Policy
Track for Certificate Level renewal policies.

AIU-Core-eXtra-. Rn_StreamPolicies_BE

[300 sec]

Purpose: This Agent is used for identifying and setting the Lead Product for Policy
Level renewal policies.

AIU-Core-eXtra-. Rn_StreamCerts_BE

[300 sec]

[300 sec]

Purpose: This is a Re-Streaming Agent is used for identifying and Risk

Stream/Policy Track for Certificate Level renewal policies.

Agents in AIGeXtra Application

AIU-Core-eXtra-. Rn_ReStreamCerts_BE

Purpose: This is a Re-Streaming Agent is used for identifying and Risk

Stream/Policy Track for Policy Level renewal policies.

AIU-Core-eXtra-. Rn_ReStreamNIP_BE

[900]

Purpose: This Agent runs to check if the policies are ready to be booked in
GOALD that are active in AIGeXtra and process them for booking in AIGeXtra.

AIU-Core-eXtra-. Rn_AutoRenewalsAgent_BE

[Daily - Weekdays]

Purpose: This Activity runs on all the certificates and policies to reset the risk
stream for all unassigned or not in progress Policies.

AIU-Core-eXtra-. Rn_CheckIfBooked_BE

[300 sec]

[Daily - Weekdays]

Purpose: AutoRenewals Agent is configured specifically for Belgium. This Agent

processes all the casefiles with Auto-Bookable status in AIGeXtra to Auto Booking
Pending status.

Other Renewal Agents are configured with subtle differences as requested by Business.
Renewal Phase I countries

Scandinavia [Sweden, Norway & Denmark] & BelLux [Belgium & Luxembourg].

Renewal Phase II countries

Germany, France, Italy, Netherlands.

Agents in AIGeXtra Application

Agents in the Making:
There is much of Development Activity currently going on in AIU Europe across
many vendors. As such theres every possibility that Agents are being configured
in Dev and will be moved to Production sooner. One such Agent in the making is
from MTA Project to check for Booking.
AIU_eXtra

AIU-Core-eXtra-. MTABookingSyncActivity

[900 sec]

Purpose: This Agent processes all the casefiles pending for Booking in AIGeXtra
that are already booked in ALPS for Booking in AIGeXtra.

Agents in PRPC
The Concept

V 5.4

Agents can be thought of as TWO types:

Task-Driven
Schedule-Driven

Task-Driven Agents can be classified as Agents, where the processing that the
agent has to accomplish is based on the work objects processing in the system.
Example: A user opens a WO to record a customer call. This WO creates a task
for an agent to lookup for that customers info in an external system, and later
retrieves that info from a queue and processes further.
Schedule-Driven Agents, unlike Task-Driven Agents, do not require a queue of
tasks for their processing. Instead, they run at a specified interval and do
system-wide processing.
Example: An agent scheduled to run every night at 10 PM to create a report of
the number of calls received/processed that day.

Agents in PRPC
The Concept contd

Back

The Task-Driven agents process work items [tasks] by first storing them in a
task queue.
Secondly, these tasks will be retrieved for processing from the queue.
Separate Threads will be created for processing these tasks in a multi node
environment to ensure no two agents process the same task at any point of
time.
Once the task is successfully retrieved for processing, the Agent switches the
context to that of the work item by changing the RuleSet list of the Agent to that
of the work item.
For updating the work item, the Agent has to acquire the lock on the work
object to ensure no concurrent updates are done.
Lastly, if the processing is completed successfully, the Agent will commit the
changes to the Database. Else, the rollback of the changes and the error
handling process will be initiated.

Q&A

Thank You