Skip to main content

Designing background processing


5 Tasks

1 hr 30 mins

Visible to: All users
Advanced Pega Platform 8.5 English
This content is now archived and is no longer updated. Progress is not calculated. Pega Cloud instances are disabled, and badges are no longer awarded. Click here to continue your progress in the latest version.


Front Stage plans to become an international company with offices in multiple countries. The company wants to send a Happy Equinox Day email to each customer shortly after midnight customer local time. When an equinox occurs, daytime and nighttime are of the same duration all over the world. Equinoxes occur twice yearly according to the following schedule.


Front Stage wants the emails to be processed as efficiently as possible to minimize the impact on regular business hours processing.

The following table provides the credentials you need to complete the exercise.

Role User name Password
Admin admin@Booking rules

When you begin, identify the following main challenges and document your approach.

  • Calculate the time for sending the email.
  • Send the email according to the time calculation.

Although not part of this exercise, you can build out a complete solution by addressing these additional challenges:

  • Map a customer address to the appropriate time zone.
  • Devleop a way to retrieve and store the equinox dates.
  • Orcheste the relationships between the configured rules.

Detailed Tasks

1 Identify design options

As you develop your implementation, rely on rules in Pega Platform™. The following approaches can be used to address the requirements:

  • Option 1 : Create a single-node job scheduler with spun-off queue processors for each customer time zone.
  • Option 2:Create a job scheduler for each known customer time zone. Configure each job scheduler to run at the appropriate time for the given time zone. The job scheduler queries for customers within the indicated time zone, sending each an email.
  • Option 3: Create advanced agents that equal or exceeds the number of known customer time zones when multiplied by the number of nodes. Allow the master agent to generate agent schedules. Remove the unneeded agent schedule. Modify the remaining agent schedules by setting the start time to the time that emails go out for a given time zone. Each agent schedules queries for customers within the indicated time zone, sending each an email.

2 Evaluate design options

Design Pros Cons
Create a single-node job scheduler
  • Low maintenance
  • Same-day customer querying
  • Distributed processing
  • Avoids redundant emails
  • Immune to node disablement
  • Additional complexity having to spin off queue processors per time zone
Create job scheduler per time zone
  • Distributed processing
  • Avoids redundant emails 
  • High maintenance
  • Affected by node disablement
  • Customer time zones must be known well in advance
Create advanced agents per time zone
  • Distributed processing
  • Avoids redundant emails 
  • Less performance 
  • High maintenance
  • Affected by node disablement and agent schedules
  • Customer time zones must be known well in advance

3 Recommend the best design option

The single-node job scheduler with spun-off queue processors per customer time zone is the recommended approach due to better performance.

4 Review solution details

1. Calculate the time for sending the email

First, determine the date that the equinox occurs in each time zone. Although the equinox takes place simultaneously worldwide, the actual date may differ depending upon each time zone's geographical location. For example, if the equinox occurs on September 22 at 20:02 GMT, the equinox occurs on September 22 for those located in time zones in and west of GMT +1. For locations east of GMT +1, the equinox occurs on September 23. You need this information to send the email on the morning of the correct date.

Next, calculate the time in GMT to send an email to each customer to deliver an email to that customer shortly after 12:00 am (customer local time) on the day of the equinox. Use GMT offset math to solve the problem. The DateTime library for Pega Platform™ does not contain any function that returns GMT offset within a particular time zone at a particular GMT-expressed DateTime. The function named ToZoneId simplifies the calculation. The function is created in a library ZonedDateTime which imports java.time.* and java.time.format.* . 

The function is shown in the following image.


The BackgroundProcEx case type populates a page list of FSG-Examples-Data-TimeZoneInfo instances seeded with different times. Four rule-declare-expressions then fire against the PageList. The page context for the rule-declare-expressions is .TimeZoneList().

.TimeZoneList() R-D-E Expression
.LocalTime @ZonedDateTime.ToZoneId(Top.DateTimeString,.TimeZone)
.GMTTime @ZonedDateTime.ToZoneId(.LocalTime,"GMT")
.MidnightLocal @String.substring(.LocalTime,0,8)+"T000000.000 "+.TimeZone
.MidnightGMT @ZonedDateTime.ToZoneId(.MidnightLocal,"GMT")
Note: The .GMTTime property and associated rule-declare-expression are not required as part of a solution. They are used for verification. The value must always match Top.DateTimeString

The following image is an illustration of the calculated times. IDL stands for International Date Line.


To send a Happy Equinox email to customers in Honolulu, Hawaii, USA, so that the email arrives shortly after midnight (local time) the morning of September 22, 2021, Front Stage sends the email on September 22, 2021, 10:00 GMT. Four hours later, the same difference between two time zones, the Happy Equinox Day email is sent to customers in Sydney, Australia.

Sydney and Honolulu are four time zones apart. As a result, midnight in Sydney occurs four hours later than midnight in Honolulu. The difference is that, after local midnight occurs in Sydney, the calendar date becomes one day greater than the calendar date in Honolulu.

2. Send the email according to the time calculation

Two job schedulers are defined in the solution: VernalEquinoxGreetings and AutumnalEquinoxGreetings. These two job schedulers have been configured to execute yearly on March 19, 2020, and Sept 21, 2020, respectively.

The LaunchTimeZoneQueueProcessors activity called by each job scheduler is told the equinox type, VERNAL or AUTUMNAL, and for simplicity the DateTimeString when the equinox occurs. Ideally, there is a database table from which the DateTimeString can be queried based on the current year and equinox type.

The activity loops through distinct time zones identified by the D_SamplePersonTimeZoneList list data page. For each time zone, the activity creates and populates an FSG-Examples-Work-BackgroundProcEx page named CaseInfo. That page is then used as the step page when invoking the Queue-For-Processing method. The Queue-For-Processing method sees that the configured, dedicated queue processor was configured as delayed. This causes the Queue-For-Process method to display the Date time for processing field. If the queue processor is not configured as delayed, the Date time for processing field is not displayed.

Note: An alternative approach that entails unnecessary risk is having the LaunchTimeZoneQueueProcessor's activity spin-off a new BackgroundProcEx case for each time zone. Each spun-off BackgroundProcEx case avoids a disastrous runaway infinite loop by detecting that a page named CaseInfo exists on the Clipboard. Seeing the CaseInfo page on the Clipboard, the spun-off case changes to the Run in background alternate stage. Within the Run in background stage, the DateTimeString and the TimeZoneInfo properties are copied from the top-level CaseInfo page into the BackgroundProcEx case before the Run in background flow shape. TheRun in background shape tells the delayed SendTimeZoneGreetings queue processor to run at .TimeZoneInfo.MidnightGMT.

The SendTimeZoneGreetings queue processor activity of the same name obtains and iterates each SamplePerson in D_SamplePersonList[TimeZone:Param.TimeZone].pxResults.

Rather than actually sending an email, which errors out, the activity uses the Log-Message method in a step to output the timezone and WorkPartyUri values to the PegaRULES.log.


5 Confirm your work

To complete the assignment, accomplish the following tasks.

  1. Verify that SamplePerson data is defined.
    Sample person data
  2. Log out, and then log back in as Admin@Booking.
  3. Switch to the Background Proc Exercises Access Group.
  4. Copy and paste the value for pxRequestor.pyLastSignon to a text editor then add some number of minutes, for example, 10.
    202103113T021633.688 GMT << current login time
    202103113T022633.688 GMT << 10 minutes added
  5. Locate the TestEquinoxGreetings Job Scheduler and check it out.

    Remember that the job scheduler is set to run every 10 minutes.

    Test Equinox Job Scheduler
  6. Click Parameters.
    Job Scheduler parameter
  7. Copy the near-future date.
  8. In the Parameter value field, paste the near-future date.
  9. Check in the job scheduler rule.
  10. In Admin Studio, filter on Test to locate the TestEquinoxGreetings Job Scheduler.
  11. Optional: Click Override to enable the job scheduler and click Override to disable the TestEquinoxGreetings Job Scheduler.
  12. Click Trace.
    trace job Scheduler
  13. Click a row where D_SamplePersonTimeZoneList is the step page.
    Notice that the two time zones are identified:
    tracer page timezone

    Note how Queue-For-Processing is invoked twice:

    tracer step queue for processing

    The following image is an example of the CaseInfo page when Queue-for-Processing is called:

    caseinfo page tracer
  14. In Admin Studio, click Queue Processors. Filter on TimeZone.
    Admin Studio QueueP
  15. If more than two Queue Processor instances are created, remove them all and start over by enabling the job scheduler and tracing.
  16. Disable the job scheduler as soon as a trace is displayed.
    Admin Job Scheduler

LaunchTimeZoneQueueProcessors converts the provided Param.DateTimeString to local time zone, Param.TimeZone

The computation of GMTTime shows the time conversion is reversible and is not part of the solution.

The logic then computes midnight in the local time zone by setting the hours, minutes, and seconds to 000000.000.

The logic converts local midnight back to the GMT time zone.

Timezone Activity

Param.TimeZone = .TimeZoneInfo.TimeZone<br />
LOOP: SamplePersonList[TimeZone:Param.TimeZone].pxResults:

Check the output to PegaRULES.log. The following text is an example log:

2019-11-13 10:27:33,102 [,19,2,3,4,5,6,7,8,9]] [ STANDARD] [ ] [ ] (s_Work_BackgroundProcEx.Action) INFO - SendTimeZoneGreetings: TimeZone=Pacific/Honolulu, [email protected]<br />
<br />
2019-11-13 10:27:33,102 [,19,2,3,4,5,6,7,8,9]] [ STANDARD] [ ] [ ] (s_Work_BackgroundProcEx.Action) INFO - SendTimeZoneGreetings: TimeZone=Pacific/Honolulu

Available in the following mission:

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice