The nightly vehicle process accomplishes three things: 1) transfer local vehicle changes to ISI Central, 2) remove shadow records from mkf1sh and mkf1ash for vehicles whose changes were successfully processed, and 3) download vehicle changes since last download from ISI Central. The nightly vehicle process happens once at start of day, once at end of day, and once every hour between 6 pm and 6 am if the store is closed.
Nightly vehicle changes are uploaded to ISI Central in vehicle incremental loads. These loads use shadow file records to compile vehicle adds, edits, and deletes since the last incremental load was sent. The incremental process creates seven files. Three files record system information, and four files record vehicle changes. While generating, these files are located in the /opt/isi/web-central/lubesoft-sharing/data/working directory. When generated, the files are packaged into a zip file and placed in the lubesoft-sharing/data/pending directory, then uploaded to ISI Central. Vehicles without a unique_id are added to the vehicle_adds.json file. Vehicles that were edited are added to the vehicle_edits.json file. Vehicles with a shadow record but no mkf1 record are added to the vehicle_deletes.json file. Finally, vehicles without a shadow record but with a modification timestamp greater than the inf02 veh_inc_date and veh_inc_time timestamp are added to the vehicle_missing.json file. This file is designed to capture vehicle changes if shadow records are deleted or corrupted for unanticipated reasons.
After an incremental load is created, lubesoft-sharing updates the shadow records used to build the load with the name of the load zip file and the time of creation. Shadow records for vehicles that were not edited are removed. Once the load file is transferred to ISI Central the mkf1sh.transferred field is updated.
The second portion of the nightly vehicle process is to check ISI Central for the processing status of uploaded changes and to remove shadow records for vehicles whose changes processed successfully. The store collects the load names from the mkf1sh records and requests the status of those loads from ISI Central. If ISI Central shows a load processed successfully the shadow records for that load are removed. Shadow records for loads that failed or have yet to be processed will remain. These shadow records are retained so it is possible to regenerate the load files in case of an unexpected issue.
The final portion of the nightly process is to download all vehicle changes processed since the last successful download attempt. This process will not occur if the store is open or if there are unprocessed shadow records. In this process, lubesoft-sharing requests all vehicle changes since the inf02.veh_down_date and veh_down_time timestamp. The inf02 timestamp is the last successful download as recorded by the ISI Central server time, not the store location time. If the inf02 fields are blank the last download time defaults to midnight of the previous day.
When ISI Central receives the request to collect vehicle changes, it compares the requested timestamp with a saved last request timestamp. If the request timestamp is older than the saved value the process fails and returns an error. This check is performed to prevent changes from being downloaded after a taperestore occurs. If the request timestamp is equal to or newer than the saved last request timestamp then ISI Central gathers data for vehicles within the store’s local vehicle sharing group that have changed since the request timestamp. These changes are downloaded to the store along with a timestamp generated just before the vehicle data was collected. The lubesoft-sharing service processes the vehicle changes, starting with deleted vehicles. New vehicles receive their unique_id values from ISI Central at this time. If the download processed all vehicles successfully then the inf02 veh_down_date, veh_down_time fields are updated with the timestamp from ISI Central.