Designing background processing

As you develop your implementation, rely on rules in Pega Platform. Also consider viable alternative approaches. Compare the pros and cons of each alternative in order to build the best solution.

First, determine the date that the equinox occurs in each time zone. Although the equinox occurs at the same moment in time 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 will require this information in order to send the email on the morning of the correct date.

Second, calculate the time in GMT to send an email to each customer in order 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. Pega’s DateTime library 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 named ZonedDateTime which imports java.time.* and java.time.format.*, available in Java 8. The function is available to download via the related content link.

The function is shown in the following image.

The BackgroundProcEx case type populates a PageList of FSG-Examples-Data-TimeZoneInfo instances seeded with different times. Four Rule-Declare-Expression(s) then fire against this PageList, the page context for the R-D-Es being .TimeZoneList().

Below is an illustration of the calculated times. Note: 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 would send it on September 22, 2017 10:00 GMT. Four hours later, i.e., the same difference between two time zones, the Happy Equinox Day email would be sent to customers in Sydney, Australia.

Sydney and Honolulu are four time zones apart, hence midnight in Sydney occurs four hours later than 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.

Two Job Schedulers were defined in the solution, i.e., VernalEquinoxGreetings and AutumnalEquinoxGreetings. These two Job Schedulers are configured to execute yearly on May 19, 2020 and Sept 21, 2020 respectively.

The LaunchTimeZoneQueueProcessors activity called by each Job Scheduler is told the equinox type, i.e., VERNAL or AUTUMNAL, and for simplicity the DateTimeString when the equinox occurs. Ideally there would be a database table where the DateTimeString could 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 was not configured as delayed, that field would not be shown.

The SendTimeZoneGreetings Queue Processor’s activity of the same name obtains and iterates each SamplePerson in D_SamplePersonList[TimeZone:Param.TimeZone].pxResults. Rather than actually sending an email, which would error out, the activity uses the Log-Message method in a step to output the timezone and WorkPartyUri values to PegaRULES.log

In addition to the proposed solution, the following alternative approaches can be used to address the requirements:

• Create an 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.
• Create only as many advanced agents that, when multiplied by the number of nodes, equals or exceeds the number of known customer time zones. Allow the master agent to generate agent schedules. Remove the unneeded agent schedule and modify the remaining agent schedules, setting the start time equal to when emails are sent for a given time zone. Each agent schedules queries for customers within the indicated time zone, sending each an email.

1. Make certain that SamplePerson data is defined.
   
2. Log out the log back in as Admin@FSGEnt
3. Switch to the Background Proc Exercises Access Group
4. Copy/paste the value for pxRequestor.pyLastSignon to a text editor then add some number of minutes, for example 10:
   20201113T021633.688 GMT << current login time
   20201113T022633.688 GMT << 10 minutes added
5. Locate the TestEquinoxGreetings Job Scheduler and check it out. Remember it is set to run every 10 minutes.
   
6. Click the Parameters link
   
7. Copy/paste the near-future date
   
8. Check in the Job Scheduler rule
9. In Admin Studio, filter on “Test” to locate the TestEquinoxGreetings Job Scheduler
10. Click “Override” if necessary to Enable the Job Scheduler
11. Click Override to disable the TestEquinoxGreetings Job Scheduler
    
12. Click Trace:
    
13. Eventually the Tracer will display information
14. Click on a row where D_SamplePersonTimeZoneList is the step page
15. Notice that the two time zones are identified:
    
16. Note how Queue-For-Processing was invoked twice:
    
17. Here is an example of CaseInfo page when Queue-for-Processing was called:
    
18. In Admin Studio click on Queue Processors then filter on “TimeZone”:
    
19. If more than two Queue Processor instances are created, remove them all and start over by enabling the Job Scheduler and tracing
20. Disable the Job Scheduler as soon as a Trace is displayed:
    
21. LaunchTimeZoneQueueProcessors converts the provided Param.DateTimeString to local time zone, Param.TimeZone
22. The computation of GMTTime shows the time conversion is reversible. It has nothing else to do with the solution
23. The logic then computes midnight in the local time zone by setting the hours, minutes, second to 000000.000
24. Lastly the logic converts local midnight back to the GMT time zone:
    
25. Param.TimeZone = .TimeZoneInfo.TimeZone<br />
      LOOP: SamplePersonList[TimeZone:Param.TimeZone].pxResults:
    
26. Check the output to PegaRULES.log. Here is an example:
    
    
    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