Breaking apart a large CALE object

[Pete Wirfs]

We have kept all of our CALE events in a single object, but I'm considering breaking it apart so that updating it won't take so long.  When we click "save" it requires several minutes to generate its table, and automated tasks that should be triggered in that timeframe will fail to launch with unable-to-access-cale errors.

So I'm fishing for recommendations of how to break our large CALE apart into smaller ones?  Should I try putting all weekly events into one CALE, all monthly events into another CALE, for example?  How do you do it?

------------------------------
Pete Wirfs
SAIF Corporation
Salem Oregon USA
------------------------------

[Frank Muffke]

Hi Pete,

in our environment every Department or business unit has its own CALE object(s) and is responsible for it. 

If i had this task I would not split it up on technical parameters but on business logic parameters, the most common in one cale businessday, holidays, 1st of quarter, last of quarter, EOM, etc.
All others split up in different CALEs sort by similar periods, days, groups etc...

cheers, Wolfgang

------------------------------
Support Info:
if you are using one of the latest version of UC4 / AWA / One Automation please get in contact with Support to open a ticket.
Otherwise update/upgrade your system and check if the problem still exists.
------------------------------

[Jared Kessans]

My concern would be that potentially having keywords in each calendar with dependencies in the other calendar(s).  Definitely something to watch out for as it would still then require some/all calendars being recalculated.

Currently we update the calendar in our admin environment and then deploy to all other clients on a Sunday during the least busy timeframe.  We still get hit with the issue on occasion but usually one of those jobs that run many times a day.  

They really should have an automatic retry whenever the calendar isn't available.

[Pete Wirfs]

I have also observed that it is the jobs that run many times a day that are at the most risk.  And of course it would be great if the product were more resilient than it is when the calendar is being updated.

I'm coming to the conclusion however that splitting our calendar would not offer 100% protection, and therefore might offer a false sense of security to our staff.  It might be just as well that they continue to have to schedule calendar updates for a quiet time on the weekend.

I might do some experiments though with moving just the most static kinds of events into their own calendar, such as MON/TUE/WED and JAN/FEB/MAR.  It feels like unnecessary overhead to have to re-generate these sorts of events every time we want to update our calendar.

------------------------------
Pete Wirfs
SAIF Corporation
Salem Oregon USA
------------------------------

[Jared Kessans]

I have added an idea for automatic retries of an object failing to restart if the calendar isn't available that could use lots of votes.