Siebel Field Service Guide > Setting Up and Using Scheduling >

About Loading and Reloading Service Region Data

Because the service region information is cached, it must be loaded into the caches from the database when the service is started periodically to synchronize updates. Initial loading and reloading of data are automatic processes. The data for a service region is copied automatically to the caches each time the server is restarted, and manually by clicking the Load buttons. Repeat component jobs can also load service region data automatically, using the Appointment Booking System business service. See Reloading the Appointment Booking System Cache Using Workflows and About Troubleshooting the Appointment Booking System and Optimizer for more information.

Every night, information needs to move from the ABS (future) cache into the Optimizer (present) cache. For example, if today is July 1st, then the Optimizer horizon holds all activities from July 1st to July 7th. The ABS horizon is defined as 14 days, so the ABS cache holds from July 8th to July 15th. Note that both horizons are measured from the beginning of the Glued period. The end of the Optimizer horizon is set to the same calendar day (at midnight) as the start of the ABS horizon.

After it becomes July 2nd, the old July 1st data is no longer necessary; it is in the past and is discarded. At the same time, the Optimizer horizon is still looking seven days out, so it needs to load the July 9th data into the Optimizer cache. However, before the data can be loaded into the Optimizer cache, it must be unloaded from the ABS cache. If it is in both caches at the same time, it could be changed in both engines simultaneously. Therefore, the activities and data for July 9th are released from the ABS cache, and then loaded into the Optimizer cache.

When a service region is being loaded, it is not available for requests. The request is returned with a return code.

At the first load of data from a service region, the Optimizer assumes that the data coming from the database was previously optimized. So while generating an initial solution, it tries to keep the assignee as well as the sequence of activities for each field service engineer. It also keeps the time stamp of this load in the cache.

What Happens When a Service Region is Reloaded to the Appointment Booking System?

When a service region is reloaded, the ABS does the following:

1. Queries for employees currently in the service region
2. Pulls the schedule for both the service region and each employee
3. Queries for any exceptions for employees
4. Constructs a master schedule

   First, the ABS applies the service region schedule for all employees. It then applies a schedule for each employee.

   NOTE:  The service region schedule overrules both employee schedules and employee exceptions. For example, if the service region schedule does not indicate that the company operates on Sundays, activities are never scheduled for this day. This is an advantage of setting a liberal service region (24 hours): you can set exceptions like employees being able to work on Sundays.

5. Reads in any constraints
6. Queries for any activities in the next 15 days—the horizon is usually set at the start time of the day (00:00:00 A.M.).

   The ABS does not load historical activities unless a weekly or monthly constraint is defined for the service region. If only weekly constraints are defined, the ABS loads one more week of data; if monthly constraints are defined, it loads one more month of data. However, when no weekly or monthly constraints are defined, the ABS only loads activities within the ABS horizon.

   The query appears as follows:

   Planned Start > ABS Load Range End and Planned End < ABS Load Rang Start

   The ABS attempts to place the activities in the schedule in the following order:

   • Activities with the Locked Schedule and Lock Assignment flags set to TRUE
   • Activities with the Locked Schedule flag set to TRUE
   • Activities with the Locked Assignment flag set to TRUE
   • Activities with the Locked Schedule and Lock Assignment flags set to FALSE

     If two activities that are both locked for schedule and assignment overlap, only the first activity attempted is scheduled. The second is set as unscheduled.

     On loading, the ABS generally attempts to insert the activities exactly as they were stored in the database. If nothing has changed (same employees, same schedules, no manual changes). the activities in the cache are exactly the same. However, if changes have occurred, the ABS will attempt to reschedule activities to counteract this. After the initial load completes, the ABS follows the rules below to reschedule any remaining appointments:

   • Earliest Start/Latest Start must be respected.
   • Locked Schedule/Locked Assignment flags must be respected.

     If the ABS can find an open spot for an activity, the Owner, Planned Start, and Planned End are updated within the cache and written to the database. If an activity cannot be inserted, its status is set to unscheduled but the Owner, Planned Start, and Planned End remain unchanged. This allows a service manager to see the original time committed to the customer. The new status is written to the database and recorded in the log if the logging level is set to level 3 or above. The activity is not kept in the ABS cache.

     Unless an activity is changed during the load, it is not modified within the database by the ABS. This means that if the ABS goes down, the version in the database should be consistent with the version in the cache. The exceptions to this are any manual changes made on the database side.

About Reloading Migrated Activity Data

If migrating activity data to a new system, you should use Siebel Enterprise Integration Manager (EIM). See Siebel Enterprise Integration Manager Administration Guide for more information.

The fields listed in Table 39 are critical for migrating the activity data.

When you load the ABS after migration, activities are scheduled according to the employee and service region schedule. If an activity can be scheduled to its original owner, at the original Planned Start and Planned End, no change is made to the activity data and the employee is scheduled for the particular activity. If the activity cannot be scheduled in this way, the activity is rescheduled, based on its Earliest Start and Latest Start constraints. The new Planned Start and Planned End, Owner (if such a change is required) and Status are updated on the activity.

To make sure that the migrated activities can be loaded into ABS and scheduled to their original Planned Start, Planned End, and Owner, the following conditions must be met:

• Planned End - Planned Start = Duration
• Work Time + Travel Time = Duration

  Here travel time is the average travel time defined on Service Region, no on Activity.

• No doublebooking of the original activities occurs

  If there is doublebooking, one of the overbooked activities is rescheduled—unless both the Lock Assignment and Lock Schedule flags are set to TRUE for the activity.

• Original activities do not violate any of the constraints for the service region
• Original activities can be fit into the service region schedule and employee schedule (Working Hours)