Question
Last activity: 11 Dec 2015 11:24 EST
FATAL - com.pega.pegarules.pub.PRRuntimeException
Hi
We are getting following exception in our production logs. It's occurring while creating the work object via agent .
sinessCalendar.CalendarUtility) FATAL - com.pega.pegarules.pub.PRRuntimeException: Multiple timezones not supported for one calendar.
I've gone through the https://community.pega.com/support/support-articles/unable-create-work-object-agent-calendar-exception PDN article ,which is addressed the same issue as suggested to add the calendar at work object level by using pyCalendar property.
But in our case, unable to narrow down on root cause of the issue based on following factors.
1) Is WO being committed to data base, despite of this exception occurs in logs?
2) I had verified couple of existing objects ,which were created by agent, and I could see that the pyCalendar value is getting populated on work page.
Do we have any scenario in which pyCalendar value could be missed on work page?
3) In our App, we do have couple of other agents ,which creates the different work object,but we didn't see similar exception with them.
Please share your thoughts if you have work around to this.
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Accepted Solution
This issue is resolved by HFIX-21695 .
Pegasystems Inc.
US
what is your PRPC version?
Pega 7.1.6
Pegasystems Inc.
US
If you run showsourceversion activity and then pass in com.pega.pegarules.priv.businessCalendar.CalendarUtility, can you report the outcome? (module version string)? There are several hotfixes around the class, I would like to see where you at.
Kevin, Here is the outcome $Id: CalendarUtility.java 97539 2014-07-11 14:59:15Z KennethOlson $
Pegasystems Inc.
This error usually happens when you have two data-admin-calendar instances of the same name but referencing different time zones. Check designer studio --> organization --> calendar
This will give you a list of calendars in the system and the time zones referenced. Hopefully you will see the conflict.
Hope this helps
David , I see the conflict with Default calendar instances as present in two rulesets (Pega-Process Commander , App Ruleset),and referring to two different time zones.
My concern over here is ,if our finding are true then the exception should occur for all work objects,instead of specific type of object.
I could see one more exception along with reported one.
2015-11-25 19:47:49,564 [fault (self-tuning)'] [ STANDARD] [ APP:01.01.01] (sinessCalendar.CalendarUtility) FATAL - com.pega.pegarules.pub.PRRuntimeException: Multiple timezones not supported for one calendar
2015-11-25 19:47:49,565 [fault (self-tuning)'] [ STANDARD] [ APP:01.01.01] (ed.pega_rules_businesscalendar) FATAL - The business calendar object could not be found
2015-11-25 19:47:49,577 [fault (self-tuning)'] [ STANDARD] [ APP:01.01.01] (sinessCalendar.CalendarUtility) FATAL - com.pega.pegarules.pub.PRRuntimeException: Multiple timezones not supported for one calendar
2015-11-25 19:47:49,577 [fault (self-tuning)'] [ STANDARD] [ APP:01.01.01] (ed.pega_rules_businesscalendar) FATAL - The business calendar object could not be found
2015-11-25 19:47:49,655 [fault (self-tuning)'] [ STANDARD] [ APP:01.01.01] (sinessCalendar.CalendarUtility) FATAL - java.lang.ArrayIndexOutOfBoundsException: 2517
2015-11-25 19:47:49,655 [fault (self-tuning)'] [ STANDARD] [ APP:01.01.01] (ed.pega_rules_businesscalendar) FATAL - The business calendar object could not be found.
Pegasystems Inc.
I think time zone come from operator ids/access groups. I believe you said this error only occurred on the agent, which has its own operator. Check there. Plus you should update that duplicate calender default record to reflect the time zone of the other one. This should make the multiple times zone error go away.
Regarding the business calendar error, I think there's a function in the system looking for a business calendar, find the function and see if it's calling a calendar instance that exists, or not.
I hope this helps.
Thanks,
Dave
Sent from my mobile phone. Please laugh at or excuse all errorneous auto-correction mistakes.
Thanks David, we got the root cause ,it looks like a bug in pega rules .
During creation of work object via agent, The calendar which is added at work object level by using pyCalendar is considered as business calendar ,and the same calendar is being used for goal/deadline time calculations,But the calendar name isn't passing properly(passing blank) to the new SLA structure when SLA instance is configured with pyEscalations and business days.
As if the calendar value is blank then @AddTime utility function takes the "Default" calendar instance which has been configured with two different time zones in our system.Hence causing below exception.
Multiple timezones not supported for one calendar
The business calendar object could not be found.
Work-DefineSLATimes.
Capturing pyCalendar value.
Thanks David, we got the root cause ,it looks like a bug in pega rules .
During creation of work object via agent, The calendar which is added at work object level by using pyCalendar is considered as business calendar ,and the same calendar is being used for goal/deadline time calculations,But the calendar name isn't passing properly(passing blank) to the new SLA structure when SLA instance is configured with pyEscalations and business days.
As if the calendar value is blank then @AddTime utility function takes the "Default" calendar instance which has been configured with two different time zones in our system.Hence causing below exception.
Multiple timezones not supported for one calendar
The business calendar object could not be found.
Work-DefineSLATimes.
Capturing pyCalendar value.
Captured Calendar value hasn't been passed to new SLA structure
-
Raja-Kullaiah Dudekula
Pegasystems Inc.
US
Hi
Thanks for the detailed info. Is this tracked by an SR? We should have one created if not already.
We haven't raised an SR yet. If it is raised from my side ,i'll post SR# here.
Accepted Solution
This issue is resolved by HFIX-21695 .
Pegasystems Inc.
US
Hey brahmeswara rao
Did you open up an SR to obtain that HFIX?
Pegasystems Inc.
US
Kudos to Phani Sahukaru for linking to this discussion (and the presumed answer, HFix-21695) in his response to the comment thread on SA-7550.
https://collaborate.pega.com/comment/117291
Nice work, closing the loops here and there.