Siebel Field Service Guide > Scheduling Using Siebel Scheduler >
About Loading and Reloading Data for Service Regions
Because the service region information is cached, it must be loaded into the caches from the Siebel 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 automatically copied to the caches each time the server is restarted, and manually copied by clicking the Load buttons. Repeating component jobs can also automatically load service region data by using the Appointment Booking Service business service. For more information, see Creating Workflows to Reload Data for Service Regions to the Appointment Booking System Cache and Troubleshooting the Appointment Booking System and Optimizer.
Every night, information must 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 all activities from July 8th to July 15th. 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.
On July 2nd, the old July 1st data is no longer necessary; it is in the past and discarded. At the same time, the Optimizer horizon is still 7 days out, so the Optimizer must load the July 9th data into the Optimizer cache. However, before the data can be loaded into the Optimizer cache, the data must be unloaded from the ABS cache. If the data is in both caches at the same time, the data can change 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 loaded, it is not available for requests. The request is returned with a return code.
When the data from a service region is first loaded, the Optimizer assumes that the data coming from the Siebel database was previously optimized. So while generating an initial solution, the Optimizer tries to retain the assignee and the sequence of activities for each field service engineer. It also retains the time stamp of this load in the cache.
Reloading Service Regions to the Appointment Booking System
When a service region is reloaded, the ABS performs the following steps:
- Queries for employees currently in the service region.
- Gets the schedule for both the service region and each employee.
- Queries for any exceptions for employees.
- 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 indicates the company does not operate on Sundays, activities are not scheduled for that day. The advantage of setting a liberal service region (24 hours) is that you can set exceptions, such as employees working on Sundays.
- Reads in any constraints.
- Queries for any activities in the next 15 days. The horizon is usually set from the start time of the day (00:00:00 A.M.).
The ABS does not load historical activities unless you define a weekly or monthly constraint for the service region. If you define only weekly constraints, the ABS loads another week of data; if you define monthly constraints, the ABS loads another month of data. However, when you define no weekly or monthly constraints, the ABS loads only activities in 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 insert the activities in the schedule in the following order:
- Activities with the Locked Schedule and Lock Assignment check boxes selected
- Activities with the Locked Schedule check box selected
- Activities with the Locked Assignment check box selected
- Activities with the Locked Schedule and Lock Assignment check boxes not selected
If 2 activities that are both locked for schedule and assignment overlap, only the first attempted activity is scheduled. The second is set as unscheduled.
When loading, the ABS generally attempts to insert the activities exactly as they are stored in the Siebel database. If nothing changes (same employees, same schedules, no manual changes), the activities in the cache are exactly the same. However, if changes occur, the ABS attempts to reschedule activities. After the initial load completes, the ABS uses the following rules to reschedule any remaining appointments:
- The Earliest Start and Latest Start fields are considered.
- The Locked Schedule and Locked Assignment check boxes are considered.
If the ABS can find an open spot for an activity, the Owner field, Planned Start field, and Planned End field are updated in the cache and written to the Siebel database. If the ABS cannot insert an activity, the status of the activity is set to Unscheduled but the Owner field, Planned Start field, and Planned End field remain unchanged so that a service manager can see the original committed time for the customer. The new status is written to the Siebel 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 changes during the load, the ABS does not modify the activity in the Siebel database. If the ABS fails, the version in the Siebel database is consistent with the version in the cache. Any manual changes you make in the Siebel database are exceptions to this rule.
Reloading Migrated Data for Activities
If you want to migrate activity data to a new application, use Siebel Enterprise Integration Manager (EIM). For more information, see Siebel Enterprise Integration Manager Administration Guide.
The following fields 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 for its original owner, planned start, and planned end, no change is made to the activity data and the employee is scheduled for the activity. If the activity cannot be scheduled in this way, the activity is rescheduled by using its Earliest Start and Latest Start fields. The Planned Start field, Planned End field, Owner field (if such a change is required), and Status field are updated for the activity.
To make sure that the migrated activities can be loaded into ABS and scheduled for the original owner, planned start, and planned end, the following conditions must apply:
- The Planned End field less the Planned Start field must equal the Duration field.
- The Work Time field plus the Travel Time field must equal the Duration field.
Travel time is the average travel time for the service region, not the activity.
- No doublebooking of the original activities occurs.
If doublebooking occurs, an overbooked activity is rescheduled, unless both the Lock Assignment and Lock Schedule check boxes are selected for the activity.
- Original activities do not violate any of the constraints for the service region.
- Original activities can fit into the service region schedule and employee working hours.